I’ve managed to deploy the project to render.com and use upstash.com for redis database. There are two applications that talk to each other - client (React) and server (GraphQL and Redis parts).
Here is a small GIPHY 📺 of the application in action:
Redis PubSub in Action
Oftentimes when working on an application that needs to be easy maintainable, scalable and performant, developers will go with Publish/Subscribe messaging pattern.
The idea behind it is simple, but powerful. We have senders called publishers. Their sole role is to send or publish messages. They don’t care about who is going to receive them or if someone will receive them at all. They just shoot and forget the messages. And they do that via so-called channels. Think of them as for example TV channels. We have Sport channels, Weather Forecasting channels, Cooking channels. Every publisher could send its messages to a certain channel, and whoever is subscribed for this channel will be able to receive these messages.
Here is where the subscribers come in play*.* They can subscribe to one or more channels and start receiving the messages broadcasted in there. As we already mentioned, the messages are to be sent and forgotten, which means that if a subscriber subscribes for a certain channel, all the messages that were sent previously in that channel are not going to be available to this subscriber.
Due to the nature of this kind of architecture we can easily achieve low coupling between the different components and provides a solid foundation for building robust and easy-to-maintain applications. For example, imagine a situation where we need to replace or improve the publishing part of our system, say add more publishers, more channels or so on. Since the two parts are isolated, meaning publishers don’t care about subscribers and vice versa, we could easily do that without worrying whether we are breaking some other part of the system. We just add the new publishers and then later, when a subscriber comes to the relevant channels, it just starts using them.
The initial idea behind Redis was to serve as in-memory cache solution, as an alternative of its ancestor Memcached. But nowadays it became many-in-one solution - it provides in-memory data structure store, key-value database, message brokering and so on. This makes it perfect candidate when building an application that needs really fast caching solution as well as some of the other features mentioned before. Especially if the performance of the app is crucial for its normal usage.