Guide to GraphQL Redis Subscriptions in Node.js

In the modern development world, real-time communication is becoming increasingly important. But how can developers harness this power to build better software? Fortunately, GraphQL Subscriptions and Redis Pub/Sub are coming together to make it easier than ever to implement real-time data transfer. In this blog, we will explore how to use GraphQL-Redis-Subscriptions in a Node.js environment, as well as discuss why it is an invaluable tool for any developer.

Understanding GraphQL Subscriptions

GraphQL subscriptions allow clients to receive real-time data from the server. Similar to queries and mutations, subscriptions provide an intuitive API for defining what data should be sent to the client over a WebSocket connection.

Traditionally, developers have been forced to implement their own long polling mechanisms on the client and short polling on the server to simulate real-time data exchange through standard HTTP requests/responses. But these approaches have serious performance drawbacks. Essentially, every HTTP polling request will be establishing and tearing down a new TCP connection on the server, wasting immense amounts of bandwidth and server CPU time. In an enterprise setting with thousands or even millions of users, such a polling-based architecture would be completely unrealistic. That is why developers have turned to WebSockets. Using WebSockets makes implementing real-time applications much easier as it exposes a low-level persistent TCP connection for bidirectional communication between the server and the client. But managing WebSocket connections on the server and client involves writing a lot of boilerplate code for event routing, payloads parsing, and overall state management.

GraphQL subscriptions, however, hide this complexity and offer a very intuitive abstraction for implementing real-time features in applications. GraphQL subscriptions provide a standard way to describe exactly what data shape is expected by the client over a long-living WebSocket connection.

Once the client establishes a subscription, they will receive live data from the server every time a specific event is triggered. The data itself can be of any JSON format, but the most important part about GraphQL subscriptions is that the client always controls what gets sent through the WebSocket channel. This eliminates any unnecessary overhead on the network and ensures that mobile devices will not waste cellular data or battery on irrelevant data events. The key benefit of using GraphQL subscriptions is that they expose a very lightweight and intuitive API surface for implementing real-time features while abstracting away the complexity of managing WebSocket connections.

But how can GraphQL subscriptions be integrated with Redis Pub/Sub to build enterprise-grade real-time applications? To answer this question, we need to briefly discuss what Redis is and how it can be useful in a real-time application settings.

Before the widespread adoption of GraphQL, engineers tasked with building real-time features often had to rely on custom Socket.io implementations or native browser WebSocket APIs. While these raw technologies are certainly capable, they lack the strict typing and declarative data-fetching paradigm that makes modern frontend development so efficient. A developer would have to manually orchestrate custom event names, write complex reducers to handle incoming payloads, and meticulously manage the state of the socket connection. This manual orchestration often led to brittle codebases where undocumented socket events would trigger unpredictable UI states, creating a nightmare for QA testing and ongoing maintenance.

By bringing real-time data directly into the GraphQL layer, you completely eliminate this disjointed workflow. The frontend engineering team can simply write a GraphQL subscription query that looks practically identical to a standard data-fetching query. They get the exact same strong typing, the same auto-generated TypeScript interfaces, and the same predictable data shapes they are already used to. When the WebSocket pushes a new event down the wire, the GraphQL client (like Apollo or Relay) automatically intercepts the payload, seamlessly normalizes the data, and updates the local frontend cache without requiring any manual intervention. This creates an incredibly smooth developer experience and drastically reduces the surface area for bugs.

What is Redis and How Does it Work with GraphQL Subscriptions?

Redis is an open-source in-memory data structure store that can be used as a database, cache, and message broker. Redis, in particular, has excellent pub/sub capabilities that allow very high-performance real-time messaging between nodes in a distributed system.

Essentially, any real-time application can benefit massively from Redis pub/sub, which is why it integrates exceptionally well with GraphQL subscriptions. To see why this is the case, let’s discuss why Redis pub/sub is a superior alternative to standard in-memory pub/sub that is natively supported by Node.js.

The primary reason for this is that Redis is a self-contained server process that runs independently from your application servers. This is extremely useful when you need to build a cloud-native real-time platform because it allows you to scale your application horizontally across multiple servers. For example, if you have implemented a standard in-memory pub/sub mechanism for managing WebSocket channels, then your application would be unable to scale beyond a single server.

Once you provision another application server behind a load balancer, you will have no way of syncing WebSocket channels between two instances of your application.

Using Redis pub/sub eliminates this problem, because all application server instances can publish and subscribe to the same Redis channels.

This way, when a GraphQL subscription is triggered on one application server, it will be received by all other server instances listening to the same Redis channel.

This is extremely useful in distributed systems where there is a need for high availability beyond a single server instance. Additionally, since Redis is an in-memory data store, Redis pub/sub provides extremely low-latency messaging between application servers. This is essential for high-performance real-time applications that need to process thousands of messages per second with sub-millisecond latency between nodes.

Another important consideration when choosing a pub/sub system for your real-time application is pattern matching. In Redis, there are two ways to subscribe to pub/sub channels: SUBSCRIBE and PSUBSCRIBE.

The former registers an exact channel name, whereas the latter uses pattern matching to subscribe to multiple channels at once.

This can be leveraged to build truly decoupled real-time applications, where a single Node.js server instance can listen to all messages published to channels matching a specific pattern.

For example, a single subscriber could listen to all messages published to channels matching the pattern chatroom::messages::. This way, the server will receive all messages sent to any chatroom on the platform. This is extremely useful for large-scale applications, where the number of individual channels can become unwieldy. Using pattern matching greatly reduces the number of individual channels that need to be subscribed to on the server side.

It is also important to note that Redis pub/sub is significantly faster and more reliable than many other message brokers, including Kafka or RabbitMQ. This is primarily due to the fact that Redis is a lightweight, in-memory data structure store that does not involve any disk I/O when publishing or subscribing to channels.

Now that we have discussed the benefits of Redis pub/sub let’s move on to the core topic of this blog and explore how to use GraphQL-Redis-Subscription within a Node.js environment.

GraphQL Redis Subscription is a very powerful tool for building real-time applications. But before we jump into code let’s briefly discuss important design considerations for production-grade real-time applications.

First and foremost, since WebSocket connections are essentially stateful and can live for a long time, special care must be taken to authenticate websocket connections.

Unlike standard HTTP requests, you cannot simply add authentication headers to a WebSocket URL. Instead, you will have to implement your own authentication layer for WebSocket connections. The best practice here would be to establish a secure JWT token-based authentication system for WebSocket connections.

Another important consideration for production deployment is handling disconnections and reconnections. Since mobile users are likely to experience unstable internet connections, they will frequently lose WebSocket connection to your application server. For the end-user, such disconnections should be completely transparent. That is why it is essential to re-establish WebSocket connections automatically whenever a disconnect occurs. Furthermore, it is necessary to implement exponential back-off algorithm so that reconnect attempts do not overwhelm your application server with too many reconnection requests at once.

While WebSockets provide significant performance gains over standard HTTP polling, they are still not as performant as directly pushing raw binary data through a persistent TCP connection. One of the ways to optimize payload sizes is to use GraphQL fragments to minimize the amount of data sent over the wire.

For example, a chat UI might only need to display a username and message text. Therefore, it would make sense to define a GraphQL fragment that specifies exactly what fields are needed for a chat message, and use this fragment in a GraphQL subscription query. This way, the GraphQL engine would know precisely what data should be sent to the client, avoiding unnecessary data overhead.

Now that we have discussed general design considerations for building real-time applications with GraphQL subscriptions, let’s dive into the implementation details.

It is worth taking a moment to appreciate exactly what happens when you combine these distinct technologies into a unified stack. On its own, Node.js is already well-equipped for handling concurrent connections due to its non-blocking, event-driven architecture. A single Node.js instance can comfortably maintain thousands of idle WebSocket connections with very little memory footprint. However, the moment you need to scale your infrastructure horizontally by placing your Node.js servers behind a load balancer (such as AWS Application Load Balancer or NGINX), you immediately run into the dreaded “sticky session” problem. If a client is connected to Server A, and an event is triggered on Server B, Server B has absolutely no way of communicating with Server A to push the update down the client’s open socket.

This is precisely where the Redis PubSub integration proves its true value. By introducing Redis as a centralized message broker, you decouple the WebSocket connection state from the individual Node.js server instances. Every single Node.js server in your cluster simply maintains an open connection to the Redis cluster. When an event fires anywhere in your infrastructure, it is published to a specific Redis channel. Redis then acts as a highly efficient, in-memory megaphone, instantly broadcasting that event to every connected Node.js server simultaneously. The servers then independently check their local memory to see if they hold any active WebSocket connections that care about that specific event, and if they do, they push the payload down the pipe.

The beauty of this architecture lies in its sheer simplicity and cost-effectiveness. You don’t need to deploy heavy, complex message brokers like Kafka or RabbitMQ, which require significant DevOps overhead to maintain and tune. Redis is incredibly lightweight, ridiculously fast, and often already present in your infrastructure stack for caching purposes anyway. By leveraging its PubSub capabilities alongside GraphQL subscriptions, you can build a system capable of handling millions of concurrent users with sub-millisecond latency, all while keeping your cloud infrastructure bills surprisingly low.

Implementing GraphQL-Redis-Subscriptions in a Node.js Application

There are several steps that need to be taken before GraphQL subscriptions can be used in a Node.js application.

1: Installing Dependencies

npm install graphql-redis-subscriptions ioredis

2: Setting Up Redis Connection

import IORedis from 'ioredis'

export default class RedisConnectionFactory {
  getNewRedisClient(name: string): IORedis.Redis {
    const client = new IORedis(REDIS_URL)

    client.on('connect', () => {
     console.log({
        msg: 'Connected to Redis',
        client: name,
      })
    })
    client.on('error', (err) => {
     console.error({ msg: 'redis error', err, client: name })
    })

    return client
  }
}

export const redisConnectionFactory = new RedisConnectionFactory()

3: Create A PubSub Instance

// pubsub.ts
import { RedisPubSub } from 'graphql-redis-subscriptions'
import { redisConnectionFactory } from './redis'

export const pubsub = new RedisPubSub({
  subscriber: redisConnectionFactory.getNewRedisClient('pubsub-subscriber'),
  publisher: redisConnectionFactory.getNewRedisClient('pubsub-publisher'),
})

4: Pass The PubSub Instance To GraphQl Server

Import { ApolloServer } from 'apollo-server-express';
Import { pubsub } from './pubsub';

const server = new ApolloServer({
  typeDefs,
  resolvers,
  pubsub,
});

5: Publish A Message

export function publishMessage(
  bookingId: string,
  message: string,
  mutation?: NexusGenEnums['MutationType'],
): void {
  console.log(`publishing ${bookingId}-booking-message`)
  pubsub.publish(`${bookingId}-booking-message`, {
    bookingId: bookingId,
    message,
    mutation,
  })
}

6: Subscribe To Message

The code block below shows the actual subscription resolver code. Note that the subscribe function returns an asyncIterator. AsyncIterator is necessary to allow async/await within the subscribe function. AsyncIterator is also needed to support async operations when listening to Redis channels. In practice, this means that the subscribe function will immediately pause execution and wait until a message is published to a channel. Once a message is received, the iterator will resume execution and return the message to the client.

export const MessageSubscriptionPayload = objectType({
  name: 'MessageSubscriptionPayload',
  definition(t) {
    t.id('bookingId')
    t.field('mutation', { type: 'MutationType' })
    t.string('message')
  },
})

export const MessageSubscription = subscriptionField('onMessage', {
  type: nonNull('MessageSubscriptionPayload'),
  args: {
    bookingId: nonNull(idArg({ description: 'The booking id' })),
  },
  subscribe: (_, { bookingId }, ctx) => {
   console.log(`subscribed ${bookingId}-booking-message`)
    return ctx.pubsub.asyncIterator<number>(`${bookingId}-booking-message`)
  },
  resolve: (payload: PublishType) => payload,
})

Example

Now let’s take a look at an example subscription query. The query below will subscribe to the onMessage event. Once a message is published, the client will receive a notification with the event data.

subscription onMessage($bookingId: ID!) {
  onMessage(bookingId: $bookingId) {
    mutation
    message
  }
}

Conclusion

Using node.js development services to implement GraphQL-Redis-Subscription in your node.js application increases its real-time functionality. Using GraphQL for data management and Redis for pub/sub provides developers with the ability to create scalable applications in different industries.

The combination of these technologies allows custom software development companies to customize solutions to meet the unique needs of different industries. Whether it is financial, medical, or travel software development, implementing GraphQL-Redis-Subscription in node.js applications will improve the performance and user experience of the software.

In conclusion, as the demand grows for real-time, responsive applications, the use of GraphQL-Redis-Subscription in node.js applications via node.js development services will be a great solution for developing such products. Having said that, with the help of the information described in this article, developers will be able to implement these technologies with confidence and gain extensive knowledge about the use of GraphQL Subscriptions.

Finally, using this trio of technologies will not only increase the performance of the applications but also optimize the underlying infrastructure and reduce the complexity of DevOps operations. By replacing thousands of short HTTP polling requests with a few persistent WebSocket connections, your application will handle an order of magnitude more users per server instance. And by using Redis, you will be able to ensure horizontal scalability of your application with ease and without additional overhead. All in all, leveraging the capabilities of GraphQL Subscriptions combined with Redis Pub/Sub will enable your engineering team to build truly production-ready platforms that will delight your customers for years to come.