Upgrading to GraphQL Yoga 2.0

[Urigo]

Hi from @TheGuildDev !

We recently released the new GraphQL Yoga 2.0 (would love your help with spreading the word)

We think it is a superior choice for Parse current GraphQL Server dependency and would love to help you refactor to use it under the hood.
It is modern, more performant, follows the spec, automatically gives Parse developers access to Envelop's PluginHub and many more benefits.

Also, we are offering help and free support to all the open source projects that use our tools.

[mtrezza]

@Moumouls What do you think?

Related issue: #7916

[Moumouls]

Hi @Urigo and @mtrezza

Thanks for opening the issue 🙂

Currently, Parse Server uses an Apollo GraphQL server (and it works pretty well).
I have a personal Open source to-do list for parse-server but I'll have a hard time deep-diving into the benefits/differences between our usage of Apollo and your suggestion with Yoga 2.0.

We are always open to suggestions, but we need to be careful with this kind of change, can you provide more details about:

We think it is a superior choice for Parse's current GraphQL Server dependency

Less memory footprint? fewer dependencies? Better performance? What are the fundamental differences? Compatibility with advanced usages from an apollo/client? Compatibility with Apollo Federation? Compatibility with "native" GraphQLSchema from "graphql" official package.

If you have some metrics about performance/footprint benefits it could be helpful 🙂

Also from my point of view (opinionated), Apollo has a huge community (Apollo Server has over 600k downloads/week) and yoga 20 000 downloads/week. 30 times more used, I know that downloads do not reflect the quality of software, but in our case, it means that it will be easier over time for new contributors to work with Apollo than Yoga I think.

[Urigo]

Thank you for your response @Moumouls !

Yes I know how hard maintaining a popular open source project can be, so first of all thank you for writing your detailed response.
At The Guild we maintain some of the most popular open source GraphQL projects so we can appreciate the hard work you are putting in.

You touched on a lot of important areas, I’ll try to write a detailed answer:

What are the fundamental differences?

The core difference are:

1. Architecture
2. Ecosystem
3. Real time and future-spec features

Architecture

One of the main advantages of GraphQL Yoga 2.0 is its architecture.
In the same way that TypeScript aims to stay aligned with ECMAScript, GraphQL Yoga 2.0 is based on several official and recognized specs:

GraphQL-spec, GraphQL-over-HTTP: guarantees your GraphQL API to work with all existing GraphQL clients (Apollo, Relay, URQL, and more).
GraphQL-Multipart-Request: enables great file upload support.
W3C Fetch API: we embrace the future of Node.js and provide the same developer experience on all platforms.

Together with the fact that it separates completely HTTP handling from GraphQL, that means first of all, that GraphQL Yoga 2.0 integrates naturally with all other platforms:

• Node servers like Express, Fastify and others
• Next.js Routes
• AWS Lambdas
• Cloudflare Workers
• Deno
• SvelteKit
• And others (including making the integration with Parse very easy)

Ecosystem

GraphQL Yoga 2.0 is built on top of Envelop Plugins.
That means you can use the whole plugin ecosystem of Envelop, including rate limiting, caching, Auth, tracing and monitoring and basically any feature GraphQL servers in production needs.

Real time and future-spec features

As someone who worked on the original GraphQL Subscriptions implementation, I can say that the current version in use hasn't received any major updates in the last couple of years.
GraphQL Yoga 2.0, has up to date, fully typed GraphQL Subscriptions implementation.
In addition to that, we added the ability to use GraphQL Live Queries, which has the potential to make Parse's own live queries more ergonomic for developers.

Also you get of course the official GraphiQL out of of the box (which is back to being maintained by many GraphQL Foundation companies).

Better performance?

GraphQL Yoga 2.0 has significantly less latency and much higher requests rate.

You can find the actual numbers on this 3rd party benchmark

Less memory footprint?

Regarding memory footprint, we don’t run official benchmarks specifically for that. However, according to our high scale clients running across all the environments I’ve mentioned above, costs of maintaining servers are lower after migrating.
If you have specific scenarios or benchmarks we can use, please let me know and we'll add that to our CI as well.

fewer dependencies?

I would check both the number of dependencies and overall bundle size when evaluating library dependencies.
Because Bundle Size matters when you are running your servers in certain environments (because of cold starts).

You can find the comparison for bundle sizes and number of dependencies below:
https://bundlephobia.com/package/apollo-server@3.6.7
https://bundlephobia.com/package/@graphql-yoga/node@2.3.0

Compatibility with advanced usages from an apollo/client?

GraphQL Yoga 2.0 supports any feature of Apollo Client, Relay, Urql, react-query and any GraphQL client out there.

Compatibility with Apollo Federation?

GraphQL Yoga 2.0 not only officially supports the Federation spec as a subgraph, but also can act as the Apollo Gateway server.
With GraphQL Yoga 2.0 you can use Apollo Federation together with all the plugins of Envelop, so you can benefit from both ecosystems:
https://www.graphql-yoga.com/docs/features/apollo-federation

Compatibility with "native" GraphQLSchema from "graphql" official package

Great question - GraphQL Yoga 2.0 supports any GraphQL Schema out of the box - GraphQL Tools+Codegen, Pothos, Nexus, gqtx, TypeGraphQL, graphql-js by itself, Apollo Federation and any other schema builder you can think of…

Also from my point of view (opinionated), Apollo has a huge community (Apollo Server has over 600k downloads/week) and yoga 20 000 downloads/week. 30 times more used, I know that downloads do not reflect the quality of software, but in our case, it means that it will be easier over time for new contributors to work with Apollo than Yoga I think

You are right, Apollo Server is a very popular library, but actually I think you checked the wrong Yoga npm library, this is the correct one - https://www.npmjs.com/package/@graphql-yoga/common --- we are not that far behind ;)

As you pointed out, more npm downloads doesn't necessarily reflect the quality of the library.
A higher number, acceptance rate and support for and from contributors are as important.
You can see examples of The Guild's open source libraries on:

• GraphQL Codegen
• GraphQL Tools
• GraphQL Mesh
• Envelop
• GraphQL Inspector
• GraphQL Config
• GraphQL ESLint
• GraphQL Modules
• GraphQL Scalars
• GraphQL Yoga

You can find more information on our team and maintainers here.

Also, as I mentioned above, we know how important open source collaborations are and how rare they are.
That's why we are happy to create the initial PR ourselves and also offer a shared Slack channel to support you and the Parse community with any questions or help you might need now and in the future.

I personally looking forward to hearing your comments and for possible collaboration because I believe we could learn a lot from you and the Parse community!

[Moumouls]

Hi, @Urigo thanks for the complete detailed answer!

I need to work on an update of graphql dependencies and I know that we do not have a specific implementation related to apollo. Based on some docs that I saw, trying a switch to yoga will be a question of a few minutes during my graphql dependencies update PR.

I have a performance question, I saw that you support a GraphQL JIT envelop plugin. Using the Yoga + GraphQL JIT plugin could improve performance compared to a solo Yoga 2.0? In what case does, the Yoga + JIT plugin will make a difference in terms of performance?

Let's give it a try 👍

I have a backend using intensively Parse Server + GraphQL in my company I'll check also performance/startup improvement with and without Yoga. I'll publish the performance improvement of our test suit here.

(Side note: I heavily use GraphQL Codegen with React hooks on client side and GraphQL request plugin on server side with my team. We have a fully typed experience from database (thanks to parse-server) to client side. A big time saver, thanks to your GraphQL Codegen package 🚀 )

[Moumouls]

@Urigo @dotansimha do you have a slack/discord where I can chat with you if I've some specific questions?

[Moumouls]

GraphQL Yoga 2.0 is not currently compatible due to: graphql-hive/envelop#1381

[Moumouls]

@Urigo feel free to add me to the slack channel, I'll need help to be able to finish the implementation.

That's why we are happy to create the initial PR ourselves and also offer a shared Slack channel to support you and the Parse community with any questions or help you might need now and in the future.

[Urigo]

@Moumouls thank you so much for considering!!

First of all, I just invited you to our private Slack.
We are also available on the official GraphQL Discord (it used to be The Guild's channel and we contributed it) but it's much easier to talk to us on Slack.
We can also do a shared Slack channel with your company, might be easier for you so you won't need to login to yet another Slack channel :)

About your issue, I think we know the answer.
On Monday @n1ru4l from The Guild will lead the work from our side to support you on Slack and help you get a good PR going.

It would be really awesome to then talk and learn from you about your full setup, we are very excited you are using the Codegen ❤️

And for your question about GraphQL JIT, the answer is yes, it will improve the performance in all the same scenarios graphql-jit would improve over graphql-js.
We use this plugin extensively with our users.

Looking forward to continue the chat on Slack!

[Moumouls]

Hi, @Urigo I received your slack invitation. Sadly we do not have the Slack paid plan with the Slack connect feature. Could send me another invitation to directly join your Slack Workspace. It's not a problem for me to join another Slack workspace.

I'll be happy to share with your team my usage of GraphQL Codegen and the global setup.

About your issue, I think we know the answer.

Perfect, this is the only issue that I saw currently, once it's fixed I think the PR will be easy to finish! 🚀

Also, I would like to know for both communities and the GraphQL community if The Guild is open to adding the Parse Platform/Parse Server link/logo to your website or somewhere. Parse Server helps developers to easily spin up a fully-featured GraphQL Server in minutes (we've just subscriptions not already implemented). I can invite you to visit the docs that show the power of the parse-server GraphQL API. https://docs.parseplatform.org/graphql/guide/#getting-started

We can also if the implementation is successful, think about a blog post on your side about the Parse Server use case (perf, migration, dependency reduction, and more)

[mtrezza]

Closing via #7967