GraphQL Subscriptions with Redis
By 2018, GraphQL has conquered the API world. But until recently, we still relied on traditional WebSockets or polling for real-time data. GraphQL Subscriptions have finally standardized how we push data from the server to the client.
The Subscription Schema
In your schema, you define subscriptions just like queries:
type Subscription {
messageAdded(roomId: ID!): Message
}
The Backend: Apollo Server and Redis
For a single server, the default PubSub implementation in memory works fine. But in production, you're likely running multiple instances of your server. This is where Redis PubSub becomes essential.
const { RedisPubSub } = require('graphql-redis-subscriptions');
const pubsub = new RedisPubSub({
connection: {
host: REDIS_DOMAIN_NAME,
port: PORT_NUMBER
}
});
const resolvers = {
Subscription: {
messageAdded: {
subscribe: (parent, { roomId }) => {
return pubsub.asyncIterator(`MESSAGE_ADDED_${roomId}`);
},
},
},
Mutation: {
addMessage: async (parent, { roomId, text }) => {
const newMessage = await saveMessage(roomId, text);
pubsub.publish(`MESSAGE_ADDED_${roomId}`, { messageAdded: newMessage });
return newMessage;
}
}
};
The Client: Subscription Transport WS
On the client, Apollo uses the subscriptions-transport-ws library to maintain a persistent connection.
const client = new ApolloClient({
link: split(
({ query }) => {
const definition = getMainDefinition(query);
return definition.kind === 'OperationDefinition' && definition.operation === 'subscription';
},
wsLink,
httpLink
),
cache: new InMemoryCache()
});
With this setup, our frontend can react to database changes in milliseconds without ever having to refresh. It's the "holy grail" of data synchronization in 2018.
Aunimeda builds production-grade backend systems - APIs, microservices, real-time applications, and system integrations.
Contact us for backend engineering services. See also: Custom Software Development, Web Development