This comparison highlights the main differences when using Yoga instead of Apollo Server.
One of the goals of
graphql-yoga is to have as few
graphql-yoga packages as possible.
That's why Yoga's overall architecture was designed around the W3C Request/Response specification (often just referred to as "Fetch API"),
which is already adopted by deno, cloudflare workers, and browsers.
For Node.js environments and frameworks (which unfortunately do not have full W3C Request/Response support), graphql-yoga comes with a small compatibility layer for making it work.
Read more about the underlying technology here.
You only need to search for
apollo-server- on NPM to see how many variants and packages there are for apollo and how hard it is to maintain.
As mentioned in the above paragraph
Apollo Server plans to drop active support for cloudflare workers and pushes it onto the community.
GraphQL Yoga will continuously support all platforms and runtimes wihtout any changes in your code and Furthermore, Yoga has a full end to end testing suite that actually deploys to all those runtimes in order to ensure integrity and prevent unexpected issues.
Current list of supported and tested platform:
Unfortunately Apollo Server is not fully compatible with it, there is still no further follow-up from the apollo maintainers over on the Apollo Server and envelop discussion.
GraphQL Yoga builds upon envelop, which means it 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.
Futhrermore, Yoga a default plugin preset enabled for ensuring best practices for a performant (parse and validation caching) and secure GraphQL (e.g. though error masking) server by default. If you want to opt-out of some or all of these plugins that is also possible.
Yoga is fully customizable for your needs!
You can find a list of all available Envelop plugins over on the envelop plugin hub.
GraphQL Yoga is fully compatible with the GraphQL over HTTP specification (including the incremental delivery over HTTP specification).
The current version of GraphQL Subscriptions by Apollo hasn't received any major updates in the last couple of years.
GraphQL Yoga supports GraphQL Subscriptions over Server-Sent-Events (SSE) out of the box with fully typed implementation without the need of any additional libraries. It also support GraphQL Subscriptions over WS and in addition to that, we added the ability to use GraphQL Live Queries.
For serverless/edge (service worker) environments, the size of the server code can be crucial for cold-start time and performance.
Here you can see a comparison of bundle sizes:
GraphQL Yoga only has a fraction of the dependencies of Apollo Server, and in general is much smaller.
GraphQL Yogas APIs are designed for code-splitting and supported by popular bundlers.
GraphQL Yoga has significantly less latency and much higher requests rate than Apollo Server in all popular benchmarks.
While Apollo Server is shipping with their proprietary and less updated hosted IDE and removed the default open source GraphiQL, GraphQL Yoga ships with the latest and greatest from the open source, Foundation backed GraphiQL IDE and we support and contribute to the project.
GraphQL Yoga not only officially supports the Federation spec as a subgraph, but also can act as the Apollo Gateway server. With GraphQL Yoga 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
We believe GraphQL Yoga is the best Apollo Federation Server out there.
The migration from Apollo Server to Yoga Server is easy and you can find instructions here.
We are maintainers of both libraries today.
The Guild initially adopted, improved, and recommended
While working on it, we realized that it to some extent allowed building more extensible GraphQL server set-ups, but on the other hand, required boilerplate code and isn't easily adoptable by new GraphQL developers. We also tried adding support for other environments such as cloudflare workers, but adding it as an after-thought wasn't that straightforward. Eventually, after a lot of trying we figured that the approach of adding it as an after-thought is the actual limitation, and instead of the other way around (W3C Request/Response first, Node.js HTTP Response/Request as a light-weight layer on top) might be a better solution.
This put us in a difficult position.
The Guild does not own
graphql-helix and we did not want to do drastic changes to it, without verifying that it actually works.
At the same time we were already building
graphql-yoga based on helix. So we decided to actually do this experiment within graphql-yoga and remove helix as a dependency from yoga.
Today we can happily say that it worked out fine!
Today we recommend
graphql-helix, if you want a batteries-included solution for GraphQL server development.
GraphQL Yoga is easier to get started, has nicer defaults, and requires less boilerplate while giving you the same extensibility as