graphql-subscriptions VS graphql-helix

graphql-yoga is built on other packages that provide functionality required for building a GraphQL server such as web server frameworks like express and apollo-server, GraphQL subscriptions with graphql-subscriptions and subscriptions-transport-ws, GraphQL engine & schema helpers including graphql.js and graphql-tools, and an interactive GraphQL IDE with graphql-playground.

The most common used (but not best maintained) library for such a PubSub engine in the GraphQL context is graphql-subscriptions. There are also adapters available for more distributed systems (where all GraphQL API replicas must be notified about the event) e.g. over Redis.

During that work, we created and merged the reference implementation into graphql-js and created two supporting libraries: graphql-subscriptions and subscriptions-transport-ws. Here is a talk with deep dive into all the details.

The Prisma / GraphQL-Yoga comes with Subscriptions, and this was the first thing I came across when my client asked for realtime updates. The implementation was quite difficult - took me a long time. Eventually, it was working locally, and in staging. However, when it came to the production environment, for some reason it just didn't work! This unfortunately ended up with a user losing an auction, which ultimately went to court etc.

There are also other solutions available: https://github.com/apollographql/graphql-subscriptions#pubsub-implementations

First, let's try to understand what PubSub is exactly. Apollo Server uses a publish-subscribe (pub/sub) model to track events that update subscriptions. The graphql-subscriptions library included in all apollo-server packages (including middleware integrations) provides a PubSub class as a basic in-memory event bus.

To add this, I can just expand the basic setup above. To do so, I do actually use a couple of small Apollo modules! Most can be picked and configured independently. For this case, graphql-subscriptions provides a little bit of pubsub logic that works within resolvers, and subscriptions-transport-ws integrates that into Express to handle the websockets themselves. Super helpful

Depends on language, I've build GraphQL servers in a few, though mostly JavaScript and Python. For Python I used to use Graphene, these days I use Strawberry.

For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).

If you want a lower level graphql server https://graphql-helix.vercel.app/ or https://benzene.vercel.app/ might be worth checking out.

While there are many GraphQL server packages available, we need one that will play nicely with Nuxt3's server engine (Nitro / h3). In the spirit of keeping things extensible and framework-agnostic, GraphQL Helix seems like a really good choice. Let's add it to our project:

Looks interesting, have you tried graphql-helix?

When using a JavaScript server, a convenient way to achieve this is with GraphQL Helix, which decouples the handling of the HTTP request from the GraphQL server. With Helix, we can have the routing logic be handled by a Node.js web framework (such as Express.js or Fastify), and then — depending on the requested path (i.e., the requested endpoint — we can provide the corresponding schema to the GraphQL server.

GraphQL Helix is a framework and runtime agnostic collection of utility functions for building your own GraphQL HTTP server. Instead of providing a complete HTTP server or middleware plugin function, GraphQL Helix only provides a handful of functions for turning an HTTP request into a GraphQL execution result. You decide how to send back the response.

import { envelop, useSchema, useLogger } from '@envelop/core'; import fastify from 'fastify'; import { processRequest, getGraphQLParameters } from 'graphql-helix'; // This creates the `getEnveloped` function for us. Behind the scense the wrapped functions are created once, here. const getEnveloped = envelop({ plugins: [useSchema(schema), useLogger()], }); const app = fastify(); app.route({ method: ['POST'], url: '/graphql', async handler(req, res) { // Here we can pass the request and make available as part of the "context". // The return value is the a GraphQL-proxy that exposes all the functions. const { parse, validate, contextFactory, execute, schema } = getEnveloped({ req, }); const request = { body: req.body, headers: req.headers, method: req.method, query: req.query, }; const { operationName, query, variables } = getGraphQLParameters(request); // Here, we pass our custom functions to Helix, and it will take care of the rest. const result = await processRequest({ operationName, query, variables, request, schema, parse, validate, execute, contextFactory, }); if (result.type === 'RESPONSE') { res.status(result.status); res.send(result.payload); } else { // You can find a complete example with Subscriptions and stream/defer here: // https://github.com/contrawork/graphql-helix/blob/master/examples/fastify/server.ts res.send({ errors: [{ message: 'Not Supported in this demo' }] }); } }, }); app.listen(3000, () => { console.log(`GraphQL server is running...`); });

Fortunately, we now have libraries like Graphql Helix, which, in my humble opinion, should replace express-graphql as the reference HTTP implementation since GraphQL Helix is also not tied to any web server framework.

If you are using Node.js there are a lot of implementations of GraphQL servers with a few being express-graphql, apollo-server, mercurius, graphql-helix and more. And if you are using other languages, you can see a great list here

Graphql Helix