2 posts tagged with "Beta"

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].

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).

It’s finally here! The day has come that you can get your hands on an early release of PostGraphile Version 5; but we do have an ask: please help us to get it ready for release.

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.