Broadcasting Actions — Integrate Your React-Redux App With Your Backend

Nowadays there is an increased demand for fast response web applications, product owners, Users want to get their feedback from the website without waiting even a second, we want to make sophisticated activities but still keep our code clean and simple.

Think about creating live stock dashboards, support chats for e-commerce websites and the list is long.

You might say that we are probably going to talk about WebSockets and you are right! nonetheless I am going to show you something slightly different.

Photo by Pat Kay on Unsplash

What are WebSockets?

The WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply. https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

With WebSockets we have the ability to build web applications that rely on near real-time responses, while we send something, we can get it at the same time we are not doing long polling activity to fetch the data from the server, in fact, there is a pipe that we can communicate between the client and the server and this pipe is always opened.

What applications can be developed with WebSockets? chats, real-time analytics websites and more.

In this article I am going to show you how we can utilise WebSockets and integrate it to the React-Redux ecosystem by “dispatching” actions directly from the backend and reduce the effort of the development when it comes to event handling.

Photo by Alex wong on Unsplash

So let’s start with the story for this article, we have a website with support chat, the communication is done via WebSockets and the technology will be based on React-Redux.

How you would design such kind of support chat? feel free to comment and share your ideas.

The source code will be shared at the end of the article

To build such kind of chat, we need the chat component that will handle the messages list, we need to define the redux for the chat that will store those messages, we will have the backend to setup the WebSocket server and api to trigger the broadcasting of the messages to the relevant sockets in the chat and last but not least, the client socket that will initiate the connection and will hold the reference to the store to dispatch the actions that being thrown to the system from the client to the backend and back to the client.

Seems complex? Not at all! In the following, I am going to show you the code so you can understand the role of every component in our solution.

High Level Diagram

WebSocket Server

The WebSocket server listens to every connection and once there is a message that needs to be delivered to everyone the server will broadcast it.

Here is the code for the server definition.

Keep in mind the diagram with all the components, can you see where is the Actions Validator? Let’s continue.

broadcastAction API

When we want to broadcast something, we will do it via API that exposed on the server, in this example our server is express based but there is no limitation to do it with different technology.

Here is the endpoint setup

Once the the app wants to deliver an action to everyone, we will call the API above with the following payload

This will be handled in the end of the pipeline in the client side.

WebSocket Client

We will define the client in a way we have the ability to dispatch actions once we are getting a message from the server.

To distinguish between the clients, we will give them random token.

This will allow us to send private message, in this way, we can integrate more 3rd party entities to notify things to users without accessing the UI, same as push notification but with a twist.

Starting the WebSocket Client

Take a look on wsAction init

Here is what we covered till now.

How it’s look like?

Defining the SAGA

“Redux Saga is a library that aims to make application side effects (i.e. asynchronous things like data fetching and impure things like accessing the browser cache) easier to manage, more efficient to execute, easy to test, and better at handling failures.” Read more here.

When we want to invoke the broadcastAction API we are doing it by dispatching an action “SEND_MESSAGE”, this will be catch by saga and will be handled by the function generator sendMessage* and will end by invoking the API request.

Did you noticed to the word “PIKACHU”? wait for it in the end.

Let’s see the following debug session to understand how its working.

You understand why I am changing the author field to “them”? feel free to answer in the comments.

The Reducer

In the code above we see the reducer that will handle the receive message action, every window have its own message list object in the store so every time the list changed the chat window will be rendered.

From the last coverage diagram to the following one, here is what we covered:

Remember PIKACHU?

The idea of broadcasting actions is that at any time we can modify the state of multiple users from external resource or between the peers, for example, if I send special word I want to handle it in different way, it can be a promotion, notification or just gif of pikachu.

Wrapping Up

This article should give you different view of what we can do with WebSockets and how to utilise them to deliver fast response websites with less effort.

The code can be found in the following repository: https://github.com/ofirattia/harmony-chat.git

Who am I?

I am Ofir Attia, a Web developer, focusing on design and architecture. Currently working at Amdocs as Software Architect.

Contributing

Special thanks to my co-worker Refael Oknin, Refael and I develop open-source libraries together for the past 2 years.

the WebSocket feature comes as part of the harmony-boilerplate that we developed.

Want to know more about Harmony? read the following article.