Building a Websocket Server in a Microservice Architecture | by KBryan | May, 2022

Designing a WebSocket server in a microservice structure for real-time communications

Picture by Taylor Vick on Unsplash

This text is written to share my exploration of real-time communication between frontend and backend utilizing WebSocket. Lately, microservice is an architectural strategy that many builders have adopted, and one of many key ideas of the microservice structure is the “Single Duty Precept.”

On this exploration, we are going to look into designing and implementing a websocket server that’s liable for establishing a WebSocket reference to the frontend (net software) and in addition performing as a middleware (or proxy) for real-time communications between the frontend and backend.

Observe: This text won’t go into element on how WebSocket or publish-subscribe messaging sample works.

There are numerous cases the place an internet software (frontend) requires real-time communication between the shopper (browser) and the server (backend). Some examples of such use circumstances are real-time feeds, real-time collaborative enhancing, real-time information visualization, real-time chats, notifications, occasion updates, and many others.

Instance of WebSocket connections between the shopper (frontend) and particular person microservices (backend)

Suppose there’s a microservice for every use case; the diagram above will then illustrate how WebSocket connections are established between the shopper (frontend) and every of the person microservices (backend).

As you may see, this isn’t an optimum design, as when the variety of microservices will increase, extra WebSocket connections might be created. Therefore, let’s look into how a WebSocket server might help to resolve this concern.

A high-level diagram of a WebSocket server in a microservice structure

Within the design above, the WebSocket server is the one microservice that establishes a WebSocket connection to the net software (frontend). For different microservices, there are two predominant methods for real-time communications to the net software (frontend):

  1. Unidirectional (backend to frontend)
    – All microservices (backend) can ship messages to the WebSocket server through API the place the message will then be forwarded to the net software (frontend) through WebSocket.
  2. Bidirectional (between frontend and backend)
    – Internet software (frontend) can ship messages to the WebSocket server through WebSocket, the place the message will then be forwarded to the microservices (backend) through Pub/Sub.
    – Microservices (backend) can ship messages to the WebSocket server through Pub/Sub the place the message will then be forwarded to the net software (frontend) through WebSocket.

We are going to construct a WebSocket server utilizing Spring Boot, Stomp, and Redis Pub/Sub based mostly on the design above. As I gained’t be going into particulars, you may refer to those superb articles by Tomasz Dąbrowski and Baeldung.com to study extra about WebSocket implementation with Spring Boot.

Step 1: Initialize the Spring Boot Challenge

Head over to https://start.spring.io/ and initialize a Spring Boot mission. Minimally, you’ll require Spring Internet, Redis, and Websocket dependencies.

Instance of Spring Boot Challenge

Step 2: Configure WebSocket and STOMP messaging

Create a configuration file, WebsocketConfig.kt, and add the configuration under. The configuration permits WebSocket capabilities for the Spring Boot software.

Observe that the stomp endpoint permits all origins for demonstration functions, however this shouldn’t be the configuration for manufacturing setup.

Configurations for enabling Spring Boot Websocket (WebSocketConfig.kt)

Step 3: Create API Endpoint for unidirectional real-time communication

The API endpoint gives a approach for microservices (backend) to ship messages to the net software (frontend). Because the messages solely require a one-way circulate (backend → WebSocket Server → frontend), utilizing APIs might be an excellent communication medium between microservices (backend → Websocket server).

API Endpoint for sending a message to WebSocket server

The code above creates a REST controller with a POST request endpoint that takes in a request physique “NewMessageRequest” the place the subject is the STOMP vacation spot that the shopper (frontend) subscribes to and message is the precise message in String format. With this, now you can ship a message through API to the WebSocket server, which can then be forwarded to the net software (frontend) through WebSocket.

Step 4: Configure Redis Pub/Sub for bidirectional real-time communication (Elective)

Observe: Relying in your use case, you may omit this step if you don’t require bidirectional real-time communication between the net software (frontend) and microservices (backend).

Communication through APIs between microservices (backend and Websocket server) won’t be optimum for real-time communications as in comparison with utilizing a publish-subscribe messaging sample. Therefore, for bidirectional communication, we are going to make use of a publish-subscribe messaging sample.

There are numerous methods to implement a publish-subscribe messaging sample however for demonstration and ease’s sake, we are going to use Redis Pub/Sub.

TK ampersand

To get began, run a Redis server regionally utilizing docker (docker run — identify redis-server -p 6379:6379 -d redis) and add the next configuration to the applying.yml file for the WebSocket server to hook up with the Redis server.

# software.yml
spring.redis:
host: localhost
port: 6379

Subsequent, create a configuration file, RedisConfig.kt, and add the configuration under. Basically, we’re configuring a ReactiveRedisTemplate that communicates with the Redis server and is configured to serialize and deserialize messages as String.

Configuration for ReactiveRedisTemplate

Following this, create a RedisService that incorporates logic for subscribing and publishing to the Redis server. Within the instance under, we subscribed to an inbound channel subject GREETING_CHANNEL_INBOUND which listens for incoming messages from different microservices (backend) and forwards all messages obtained to the STOMP vacation spot /subject/greetings.

Lastly, create a Controller that processes messages from the net software (frontend) that are despatched to the WebSocket server with the prefix /app. Within the instance under, messages despatched to /app/greet might be forwarded (printed) to an outbound channel subject GREETING_CHANNEL_OUTBOUND which can then be processed by any microservice (backend) that’s listening to that channel.

With that, we now have arrange the WebSocket server to behave as a middleware (or proxy) that communicates with the net software (frontend) through WebSocket and communicates with the microservices (backend) through Redis Pub/Sub.

Utilizing an open-source websocket client debugger tool built by jiangxy as a mock net software (frontend), we are able to take a look at the WebSocket server we constructed above.

Take a look at #1: Ship message from backend to frontend (through API)

Spin up the WebSocket server utilizing the WebSocket debugger device, and hook up with the WebSocket server ws://localhost:8080/stomp over STOMP protocol. As soon as linked, configure the WebSocket debugger device to subscribe to the subject /subject/toast.

Subsequent, ship an HTTP POST request to the WebSocket server utilizing the command under:

curl -X POST -d “‘subject’: ‘/subject/toast’, ‘message’: ‘testing API endpoint’ ” -H “Content material-Sort: software/json” localhost:8080/api/notification

The WebSocket debugger device ought to have the output proven under:

Screenshot of WebSocket debugger device’s output for sending a message from backend through API

This exhibits that the WebSocket server has efficiently obtained the message through API and forwarded the message to the net software (frontend) through WebSocket.

Take a look at #2: Ship message from backend to frontend (through Pub/Sub)

Spin up the WebSocket server utilizing the WebSocket debugger device, and hook up with the WebSocket server ws://localhost:8080/stomp over STOMP protocol. As soon as linked, configure the WebSocket debugger device to subscribe to the subject /subject/greetings (defined above).

Utilizing Redis CLI, publish a message to the channel subject GREETING_CHANNEL_INBOUND(defined above) utilizing the command PUBLISH GREETING_CHANNEL_INBOUND “"Take a look at Message from Backend PubSub"”.

Observe that the additional is required because the WebSocket server is configured to obtain String messages. The WebSocket debugger device ought to obtain the message as proven under

Screenshot of WebSocket debugger device’s output for sending a message from backend through Redis PubSub

This exhibits that the WebSocket server has efficiently obtained the message through Redis Pub/Sub and forwarded the message to the net software (frontend) through WebSocket.

Take a look at #3: Ship message from frontend to backend (through Pub/Sub)

Spin up the WebSocket server utilizing the WebSocket debugger device, and hook up with the WebSocket server ws://localhost:8080/stomp over STOMP protocol. As soon as linked, utilizing Redis CLI, subscribe to channel subject GREETING_CHANNEL_OUTBOUND (defined above) utilizing the command SUBSCRIBE GREETING_CHANNEL_OUTBOUND. Ship a message to STOMP vacation spot /app/greet utilizing the WebSocket debugger device, and it is best to observe the next:

Output of Redis CLI Subscribe Command

This exhibits that the WebSocket server has efficiently obtained the message through WebSocket and forwarded the message to the microservices (backend) through Redis Pub/Sub.

In abstract, we now have run by way of a potential design of a WebSocket server in a microservice structure. Having a WebSocket server significantly aligns with the “Single Duty Precept” of microservices, the place it manages all WebSocket connections to the net software (frontend) in addition to handles real-time communications between the net software (frontend) and different microservices (backend).

That’s it! I hope you realized one thing new from this text. Keep tuned for the following one, the place we are going to look into scaling the WebSocket server.

In case you like this text, please observe me for extra :).

Thanks for studying till the top. Pleased studying!

More Posts