Major Grafast beta released: Three down, one to go!
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. With this release, 3 of these are now complete!
- ✅⤵️ Global dependencies — solved via “unary” steps
- ✅⤵️ Early exit — solved via “flags”
- ✅🎉 Eradicating eval — this release!
- 🤔🔜 Polymorphism
We’re proud to announce that the third of these, eradicating eval, is now
addressed with the launch of [email protected], and the approach has been
fully adopted and tested via incorporation into [email protected].
Input evaluation moved to runtime
Since the beginning, Grafast has had the ability to add plan resolvers not just to fields, not just to arguments, but also to input object fields (including those within lists). This made Grafast’s planning really ergonomic for things like nested filters. But it turns out it’s really problematic for certain shapes of input — planning would put constraints on the variables compatible with the plan, requiring potentially unlimited numbers of operation plans needing to be built for the same GraphQL document. Worse: for large input trees involving lists, the number of steps generated could be overwhelming, resulting in the deduplication phase taking excessive time.
One particular user example that could cause 4 minutes of planning time from
just a 100kB input made it clear that we had overreached with using plan
resolvers too deep into inputs; so we’ve scaled it back so that you can only
add plan resolvers to fields and arguments, you can no longer attach
applyPlan or inputPlan to input object fields. This was something that we
used a lot in PostGraphile and its various plugins, but very few people
(no-one?) used externally so it was ripe for removal.
That problematic query that took 4 minutes to plan before? It now takes 1.1ms to plan, yielding a 200,000x speedup!