envelop VS apollo-server

The Guild took over the development of GraphQL Yoga from Prisma in early 2021, and with the growing community of tools in the GraphQL space, most recently Envelop, we were able to rewrite GraphQL Yoga 2.0 from scratch with easy setup, performance, and developer experience at the core.

Ideally, you already have your basic envelop setup with your http framework of choice. This guide we will be based on the graphql-helix fastify example, but the code can be easily transferred to any other example as listed on our Integrations and Examples documentation. In case you are hitting any roadblocks feel free to reach out to us via the chat box on this page! The full code of the end-result is also available in our examples graphql-helix-auth0 fastify example.

Make “hard” GraphQL capabilities easy by installing powerful plugins (Caching, Tracing with Prometheus/DataDog/NewRelic/Sentry/OpenTelemetry/ApolloTracing, Loggers, GraphQL-Jit, Persisted Operations, Security with rate-limit/depth-limit/Auth0 and many others from the Plugins Hub)

I started reimplementing the logic from GitHub over here https://github.com/dotansimha/envelop/pull/474

We just today published a new plugin for envelop (GraphQL execution flow customization layer) that allow rejecting GraphQL operations before being executed based on the selection set of the operation. It is pretty flexible and you can limit the access dynamically based on the GraphQL context. E.g. this allows loading the permission information from the database, the user record, or any other remote service. https://github.com/dotansimha/envelop/tree/main/packages/plugins/operation-field-permissions

We are already having a spec compatible implementation available that you can start using with envelop, without havign to wait for official graphql-js support to land: https://github.com/dotansimha/envelop/pull/179

Another interesting point is that executing fetches on the server can allow developers to more easily leverage caching. Next.js already handles caching out-of-the-box and I’m curious to see if the wider adoption of RSC reduces the need to combine React with solutions like Apollo Server and Apollo Client. While there are other benefits to these tools, RSC could provide similar caching behavior without the need to invest in a GraphQL solution.

There are several GraphQL server implementations, however, for this tutorial, we'll utilize Apollo GraphQL's Apollo Server, a lightweight and flexible JavaScript server that makes it easy to build GraphQL APIs.

As I mentioned, their main GraphQL server package is[1], so that's where the confusion came from. Thanks.

[1] https://github.com/apollographql/apollo-server/blob/9817bc47...

While working on this blog post, I learned that Apollo Server, the most popular GraphQL server for typescript, uses a similar method for adding error codes to GraphQL. It even lets you add custom errors. Hopefully, someday other GraphQL server projects will follow them. Until then, we’ve got a strong indication we took the right approach.

GraphQL is just a schema, there are many different implementations of a GraphQL server, AppSync being one of them. I mentioned Apollo server in this series as well.

After some head-scratching, I opened an issue on Apollo Server’s GitHub repository. There, Apollo Server contributor @​glasser shared a helpful suggestion: why not invoke our AuthPlugin from Apollo Server’s context function? Throwing from context would ensure we can control the HTTP status response without having to introduce more methods and error checks to our AuthPlugin (like unexpectedErrorProcessingRequest). With that suggestion in mind, we rewrote our AuthPlugin as follows:

Apollo as a middleware in Express.js, actually.

Apollo Server 3 Cookie Issue #5775

Lastly, instead of writing our API core ourselves, we'll be using the star of this episode --- Apollo Server (a.k.a. GraphQL server). It has detailed documentation available here.