3 posts tagged with "Beta"

Grafast is the cutting-edge GraphQL planning and execution engine which PostGraphile uses, allowing it to build much more efficient SQL queries than PostGraphile V4 could achieve, whilst also significantly expanding the capabilities of the system - not to mention solving some longstanding issues!

Polymorphism epic achieved​

In previous versions of Grafast there was the possibility of exponential plan branching due to the naive method of resolution of abstract types.

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. Polymorphic branches in one layer are now merged into a single “combined” step before planning the next level of polymorphism.

What does this mean for PostGraphile?​

Grafast is a cutting-edge GraphQL planning and execution engine that leverages the declarative nature of GraphQL to execute your requests with maximal efficiency no matter the data sources you're working with. PostGraphile V5 uses Grafast as the underlying execution engine, allowing it to build much more efficient SQL queries than PostGraphile V4 could achieve whilst also significantly expanding the capabilities of the system - not to mention solving some longstanding issues!

Whilst users of PostGraphile are not required to deeply understand the internals of Grafast, this focus of eradicating $step.eval*() methods from Grafast has given PostGraphile users some new benefits.

SQL generation moved to runtime​

PostGraphile's various SQL-running steps like PgSelectStep now build their queries at runtime rather than plan-time. They use the "builder" pattern, where much of the SQL query can be established at plan-time, but final tweaks can be applied at run-time (register tweaks via the $pgSelect.apply($callback) method) before the query is built.

SQL efficiency increased​

Since we have more information at run-time, our SQL queries were able to become even simpler, 10% smaller on average across our test suite! This nets us a modest performance improvement inside PostgreSQL, but the shift to runtime does cost us a little performance in the JS layer since queries now need to be built for every request, rather than once per plan. We're happy with this tradeoff; one of the core goals of PostGraphile V5 (and the motivation for Grafast in the first place) was to shift load from the PostgreSQL layer (which is non-trivial to scale) to the Node.js layer (which is easy to scale horizontally).

We need help writing automated tests, validating it works in your real-world applications, improving the documentation, keeping up with issues and community support, porting plugins, smoothing edges, and as always we need financial support so we can keep investing our time into V5 and our other projects.

It has taken us 3.5 years to get to this point and we’re pretty happy with the result, but there’s still plenty to be done before we’re ready to give it the big V5.0.0 stamp of approval!

How can I help?​

Help us to ensure that the documentation is ready. We’ve invested many weeks into writing the documentation for the various packages and projects (22 of them at last count!) which make up PostGraphile V5, but there’s still lots to do. We need people to read and follow the documentation, and to find the mistakes therein and submit issues or even patches.

Help us to ensure that the software addresses your needs. We’ve spent three years building this system, but it’s only really been tested by other people in the last 6 months. Early signs are very positive, but we want to know: does it work for you? Does it do what you need it to?

Help us to ensure that the transition from V4 is as easy as possible. We’ve spent a significant amount of time making the transition from V4 to V5 as easy as we can, building a preset that generates an almost identical schema, porting some of the V4 plugins to V5, and writing detailed migration documentation. But we need your help: did migrating from V4 work well for you? Where were the rough edges, and how can we smooth them? Are you willing to help port community V4 plugin to V5?

Help us to test V5. We have ported the V4 test suite over to V5 so we know that it works well for that, but there’s so many different combinations of options and plugins that you can do with PostGraphile that many have only been tested manually, and they really need automated tests to prevent regressions. We also need you to use V5 in your own applications and let us know how you get on — both negative and positive — to help us move towards the all-important 5.0.0 release.

Help us to improve the experience of V5. We’ve put a lot of effort into both documentation and TypeScript types, but these can always be improved. There’s boilerplate in a few places that could be addressed with improvements to APIs, or with new abstractions. Try it out, and help us to improve the developer experience!

Help us to educate people about V5. We don’t have a marketing department, we cannot afford a developer relations team or to sponsor big events. We’ll need your help to get the word out about PostGraphile V5, when the time comes; in the meantime we could really do with some help building example applications and tutorials to help people get started.