Skip to main content

3 posts tagged with "releases"

View All Tags

Grafast v1 release candidate!

· 6 min read
Benjie
Benjie
Inventor of Grafast
Jem
Jem
“I wear many hats”

The Grafast v1.0 release candidate is now available. The engine has stabilized, the epic milestones are complete, and the runtime has been hardened by more than a year of production use through PostGraphile V5 and standalone adopters. All that remains is to finish the documentation, tighten the TypeScript experience, and create more examples!

PostGraphile user? You may want to read the PostGraphile RC post instead.

What does release candidate mean for Grafast?​

The runtime APIs, behaviour, and mental model have settled and the software has proven stable with some users having ran it in production for over a year; however, the documentation needs to catch up (and some TypeScript types and comments still need to be brought in line). The release candidate tag signals the stability of the software whilst leaving us the space to focus entirely on quality and documentation before stamping the final 1.0 release.

Now is the perfect moment to validate that the “plans as dataflow” approach clicks for you: do you understand the separation of “plan-time” and “execution-time”? Can you see how principled communication between the steps allows for optimization without needing to revisit plan resolvers?

If you don’t understand it, that’s likely a failing of our documentation! Help us improve our explanations by sharing your feedback (whether confusion and frustration or success and praise!) in our Discord or with GitHub issues and pull requests!

Documentation: where we need you​

The code moved faster than the words that describe it. Parts of the docs are out of date, others are missing, and a few contradict the behaviour you see in practice. We need review, issue reports, and small patches. Your first-hand notes about what is unclear are invaluable. If something doesn’t behave according to the docs, or if the docs are unclear, let us know!

Feedback via GitHub issues or the Discord server is hugely appreciated.

From sketches and a dream to a stable execution engine​

We came up with the initial seed for Grafast in 2020, having been frustrated by the limitations, caveats and inefficiencies of traditional resolver-driven GraphQL execution, along with the messiness and inefficiency of previous attempts to solve these problems (such as digging through GraphQLResolveInfo).

The building block we came up with, our north star, was the “plan resolver”: a function that looks deceptively similar to traditional resolvers, but changes the GraphQL resolution from procedural (field-by-field, layer-by-layer, with just-in-time discovery of data requirements leading to over-fetching, under-fetching, N+1 problems, and an explosion of promises) to declarative (holistic planning of the request, followed by optimal execution).

Grafast beta: last epic solved!

· 8 min read
Benjie
Benjie
Inventor of Grafast
Jem
Jem
“I wear many hats”

In the first Grafast Working Group, we outlined 4 major issues in Grafast that needed to be addressed before we could think about general release. The fourth, and final, epic has now been solved!

  • ✅ Global dependencies — solved via “unary” steps
  • ✅ Early exit — solved via “flags”
  • ✅ Eradicating eval
  • ✅ Polymorphism — this release!

In previous versions of Grafast there was the possibility of exponential plan branching due to the naive method of resolution of abstract types — a known issue raised in the first Grafast working group as one of four “epics” to be solved before v1.0. This release of [email protected] fixes this final epic through a complete overhaul of the polymorphism system. Let’s take a look!

Polymorphism epic achieved​

By moving the responsibility of polymorphic resolution from field plan resolvers into the abstract types themselves, we’ve centralized this logic, simplified field plan resolvers, and unlocked more optimization opportunities and greater execution efficiency. We no longer have the concept of “polymorphic capable” steps: any step may now be used for polymorphism. Abstract types now gain a planType method responsible for taking a “specifier” from the field plan resolver and returning a step representing the name of its concrete object type along with subplans for each possible object type.

To solve the problem of exponential branching, we merge the new specifier steps from all previous polymorphic branches into a single “combined” step before planning the next level of polymorphism.

A plan diagram showing the old way polymorphism was handled. The nodes can branch exponentially. A plan diagram showing the new way, the branches are combined back together before moving to the next layer of resolution.

On the right is the new handling of polymorphic resolution. getPetIds and getServiceAnimals both fetch an Animal ID and so they are combined together in order to fetch all of the required Animals by their IDs. Once the IDs are fetched, the nodes can branch out to the different Animal types.

Step Aside Resolvers - Grafast 0.1 Released!

· 6 min read
Benjie
Benjie
Inventor of Grafast

Grafast is finally here — a new holistic execution engine for GraphQL. It enables greater efficiency across the entire backend stack by leveraging the declarative nature of GraphQL to give your business logic a better understanding of everything it needs to do. It’s backwards compatible, so you can adopt it incrementally within your existing schema and it’s finally ready to try with the grafast module on npm; or check out the source code on GitHub!

I launched Grafast v0.1 at GraphQL Conf, above is the full video of my talk which covers what Grafast is and how it can improve application performance, reduce operational costs, all without being a significant burden on developers.

Grafast Working Group​

There’s still decisions to be made and edges to be smoothed before Grafast can become a specification that can be implemented in any language. If the potential of this technology is interesting to you, please join the Grafast working group and get involved. We all deserve our future of easy GraphQL execution efficiency!