graphql-over-http VS graphql-subscriptions

Another major pain is the fact that operation names and HTTP codes are often hidden in request bodies which makes it really hard to see what is going on in standard monitoring tools. It's possible to write some converter but it's beyond me why some people decided that requests which failed on the server respond with status 200. GraphQL spec doesn't define how it should behave, there's only a proposal (https://github.com/graphql/graphql-over-http)

The GraphQL over HTTP specification states the following:

However, if you are doing GraphQL subscriptions over Server Sent Events (HTTP) (which is currently not part of the GraphQL over HTTP specification), the data flow is only from server to client. So each operation must be a separate request, which should be no problem when using HTTP/2, as the browser connection limit is not hit so fast (There are also workarounds to this if you cannot ise HTTP/2).

Complementary to the note, you can learn more about GraphQL over HTTP in the specification over here: https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md

GraphQL-spec, GraphQL-over-HTTP: guarantees your GraphQL API to work with all existing GraphQL clients (Apollo, Relay, URQL, and more).

Note: While GraphQL can be done over almost any protocol, this article focuses on the most commonly used protocol GraphQL over HTTP. However, most knowledge can be transferred to other protocols such as GraphQL over WebSockets or other more exotic ones.

There is also the GraphQL over HTTP Specification repository https://github.com/graphql/graphql-over-http

graphql-sse is a reference implementation of the GraphQL over Server-Sent Events Protocol aiming to become a part of the GraphQL over HTTP standard.

With no further ado - I humbly introduce graphql-ws. A coherent, feature-full, zero-dependency, plug-n-play, lazy, simple, server and client implementation of the new, security first GraphQL over WebSocket Protocol with full support for all 3 GraphQL operations: Queries, Mutations and Subscriptions. The protocol aims to be standardised and become a part of GraphQL with the help of the foundation’s GraphQL over HTTP work group.

You could additionally also choose a specific HTTP code for that scenario (although that would contradict the official GraphQL over HTTP spec https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md).

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