DEV Community: Raunak Gurud

WebSockets Unlocked: Mastering scale of websockets

Raunak Gurud — Sat, 27 Jan 2024 03:45:18 +0000

Intro
Hey there! 🌟 Ready to dive into the exciting world of real-time communication with WebSocket? 🚀 Join me in this series where we'll start from the basics, craft awesome chat/video apps, and master scaling with Redis and Kafka. Get set for a journey filled with interactive learning! 🌐💬✨ #RealTimeWeb #WebSocketAdventures

In the last blog, we discussed about what are web-sockets It also covers the difference between http and web-sockets, as well as the benefits of using web-sockets. By implementing a chat-application using Next.JS, Node.Js and express.

In this blog, we will delve into the process of scaling a web-socket server, as well as the challenges that arise during this scaling process. We will also explore various strategies to overcome these challenges.

Problem with current architecture
Now, let's consider a scenario where you have developed an impressive chat application and are witnessing an increasing number of users utilizing your chat service. As a result, you desire to scale your application in order to accommodate hundreds or even thousands of concurrent chat users.

The system's requirement are reliability and low latency for scaling But the current architecture is not scalable beyond few hundred users as it puts a lot of load on a single server which is a single point of failure

So to address the inability of the current server to handle concurrent requests. We have two choices to choose from for scaling -

Horizontal scaling involves enhancing the capacity of a computer's resources, such as RAM and CPU, in order to accommodate a larger user base.
However, it's important to note that there are certain limitations to horizontal scaling. If the application faces a sudden increase in user activity, there is a higher risk of system crashes. This occurs due to the restricted resources (CPU, RAM, Sockets) within the current architecture, which creates a bottleneck and imposes restrictions on the number of users it can support.

Vertical scaling involves adding more parallel servers to distribute the workload among them.
This look like a better option to choose as we only need to increase number of servers when the request increases The best way to handle more request is to increase the number of servers and adding load balancer in front for distribution of requests Using this we can handle increased request without any worries about single point of failure.

However, there are certain challenges that may arise when adopting this approach in terms of establishing socket connections. This is primarily due to the stateful nature of web-socket connections, which may not be feasible to maintain across different servers.

Issue about socket scale
This architecture has a major drawback. If chat users are connected to different servers, they won't be able to chat in real time. As a socket connection is stateful and only uses connected to the same server would be able to communicate in real-time

To resolve this issue, we can implement a solution where chat users are assigned to the same server. However, this approach may introduce additional complexity, such as considering user location. Although it could be effective for small-scale operations, it may place excessive strain on certain servers as the number of users increases, potentially under utilizing available servers.

There can also be issue when we would have a group chat and the users are from different regions

In the given fig as you can see there are 3 clients all three are in the same group chat but different regions. The client 1 and 2 can chat in real time as they are connected to the same server but the client3 would not receive any messages in real-time.

How to solve the issue
After careful analysis, it becomes abundantly clear that the central challenge we're currently facing revolves around the seamless sharing of data among servers. To address this matter in a decisive manner, it is highly advisable to adopt and incorporate a pub/sub architecture as the recommended solution.

The key advantage of opting for a pub/sub architecture lies in its ability to enhance scalability and flexibility. Allowing servers to operate independently, leading to improved performance and resilience.

Publisher-Subscriber architecture is a messaging pattern used in software design and communication systems. It is a way of designing distributed systems where components communicate with each other without direct dependencies. In this architecture, there are two main components: publishers, subscribers.

Publisher: The publisher is responsible for producing messages. It generates and sends messages to a specific topic or channel without any knowledge of who might be interested in those messages.

Subscriber: Subscribers express an interest in receiving messages on a specific topic or channel. They subscribe to the topics they are interested in and receive relevant messages without needing to know who the publishers are.

By implementing a pub/sub architecture, we can effectively overcome the obstacles hindering efficient data sharing. This approach of well-structured framework facilitates smooth communication and enables seamless data transmission between

Also in the event of a server or network failure, the system can automatically reroute messages or events through alternate paths, ensuring data remains accessible and uninterrupted.

By using this we can solve our problem of communication between servers

In this architectural setup, every server would function as a publisher and subscriber concurrently. This means that each server would have the capability to send and receive messages on designated topics or channels.

Upon receiving a message from the client, a server would promptly publish it on a specific topic [message]. Subsequently, all other server which would be subscribed to the same topic would then obtain the message from the Redis server instantaneously with redis.

The Redis server plays a crucial role in this architecture, as it utilizes in-memory data storage, enabling efficient I/O operations. This characteristic grants the system exceptionally fast response times, approaching real-time performance.

Leveraging this architectural design, it becomes possible to scale our application extensively and handle thousands of users concurrently.

Database issue
We would additionally require the capability to store messages in a database, taking into consideration the continuous influx of data from chat applications. The application generate a significant volume of messages concurrently, with an approximate rate of 100 messages per second from several hundred users.

But, the process of writing data into the database is time-consuming, as the database is primarily optimized for effective query and indexing operations rather than high throughput.

Consequently, this situation can potentially lead to a problem due to high volume of data incoming the DB can fail. If the database experiences a failure, all the data generated will be lost until a new database is established. It is important to note that this particular circumstance represents a single point of failure.

After careful analysis, it becomes abundantly clear that we need a system which can contain all the messages and only write to database when the DB is up and on a safe speed. It should have high-throughput to consume messages at high speed without any issues. It is highly advisable to adopt and incorporate a message-broker such as kafka as recommended solution.

Apache Kafka is an open-source distributed event streaming platform that is designed for high-throughput, fault-tolerant, and scalable data streaming. It is widely used in scenario like real-time analytics. Its flexibility and scalability make it a popular choice for building event-driven architectures and streaming data applications.

Kafka can be used as a messaging backbone to handle the communication between different components by providing -

High Throughput: Kafka's architecture is designed for high throughput. It allows for the parallel processing of messages across multiple partitions and broker nodes, ensuring efficient handling of large message volumes.

Database Writes: Consumers can be designed to read messages from the Kafka topic and write them to the database. Batch processing or other optimization techniques can be applied to ensure a safe and efficient speed of database writes.

Asynchronous Communication: Kafka enables asynchronous communication between the chat application servers and the database, decoupling the two components and allowing for improved system responsiveness.

Fault Tolerance: Kafka's replication mechanisms provide fault tolerance, ensuring that messages are not lost in the event of server failures.

Real-time Processing: Kafka allows for real-time processing of messages, enabling near-instantaneous delivery of chat messages.

When user request increases all the servers are sending messages at very thigh speed to kafka topic [messages]. Kafka is specifically designed to handle high-throughput scenarios making it well-suited for situations where a significant volume of data needs to be processed in real-time.

By utilizing Kafka, we can efficiently consume all the messages and ensure that they are only written to the database when it is up and running. This effectively eliminates any potential points of failure in the system.

Now in the current architecture, you have leverage its strengths in handling high-throughput, reliable messaging, and scalability to create a robust and efficient system for writing chat messages to the database.

🚀 If you had a blast exploring WebSockets scaling chat app, you're in for a treat! 🌟 This is just the beginning of your journey into real-time communication. Stay tuned for the next blog where we'll explore the implementation of this architecture using Redis and kafka.

Don't forget to share this blog with your tech-savvy pals! Together, we're coding our way to greatness. 🚀💻

Follow Raunak Gurud ✨for more such web development realted content

Mastering Docker Multistage Builds

Raunak Gurud — Fri, 19 Jan 2024 17:22:20 +0000

This blog post explores the process of dockerization a TypeScript Express app while taking into consideration best practices. It showcases the usage of multistage Docker files to optimize the Dockerization process.

This is not on basic of docker it will deep dive into optimize way to write Dockerfile to improve performance security speed

let's start by building a simple express app using typescript



    mkdir ts-docker
    cd ts-docker

    # Initialize project
    npm init

    # Add dependencies 
    yarn add express

    # Add dev dependencies
    yarn add -D typescript @types/express @types/node

    # Preinstalled tsc globally
    tsc --init 

    # Change tsconfig.json 
    "rootDir": "./src",    
    "outDir": "./dist",                     

    # start the server
    npm run build
    npm run start

src/index.ts

The provided TypeScript code sets up a basic Express.js server. It creates an Express app, defines a health check endpoint (/health), and starts the server on a specified port.



    npm run build

Build scripts simply compile the TypeScript code into JavaScript and output it into the "dist" folder. You will now observe a "/dist" folder created.



npm run start

The server is currently running on PORT 8090 in your local system. You can check the health of the system by using the following route: http://localhost:8090/health

If you see this message, it indicates that everything is functioning properly ✨✨.

Now, let's move to the next phase and dockerize it. Kindly close the server by using the command Ctrl + C.

Dockerization app

create a filename Dockerfile please ensure that you use the exact filename provided



# Base image
FROM node:18

# Setup workdir
WORKDIR /usr/app

COPY package*.json .

# Install Dependencies
RUN npm install

# Copy Application Code
COPY . .

# Build Application
RUN npm run build

# Run Command
EXPOSE 8090
CMD node dist/index.js

1.Base Image:* Specifies that this image is based on the official Node.js 18 image, which includes Node.js and npm.



    FROM node:18

2.Working Directory: Sets the working directory inside the container to /usr/app.



    WORKDIR /usr/app

3.Copy Package Files: Copies the package.json and package-lock.json files into the working directory.



    COPY package*.json .

4.Install Dependencies: Runs the npm install command to install the dependencies specified in the package.json file.



    RUN npm install

5.Copy Application Code: Copies the rest of the application code into the working directory.



    COPY . .

6.Build Application: Executes the npm run build command to build the application. This assumes there is a build script specified in the package.json file.



    RUN npm run build

7.Expose Port: Informs Docker that the application inside the container will use port 8090.



    EXPOSE 8090

8.Run Command: Specifies the default command to run when the container starts. It runs the Node.js application from the dist directory (assuming the build output is there).



    CMD node dist/index.js

To ignore files in your Docker build, you can add them to the .dockerignore file.



touch .dockerignore

Here are the files and folders that should be ignored after the build process:

/dist
/node_modules

Make sure you have Docker installed and running on your system.

Now let's build the image

What is a Image ??
Images are typically built from a set of instructions provided in a special file called a Dockerfile. This file defines the base image, sets up the working directory, copies files into the image, installs dependencies, and specifies the commands to be run.

To build an image, use the following command



    docker build -t [tag-name] .

In this command, the , -t, flag is used to provide a tag name for the image.

Go to console and type



    docker build -t ts-docker/single .

Building an image can be time-consuming if you do not have the base image already installed. Be patient 🧘‍♂️

To execute the build image within a container, utilize the subsequent Docker command



    docker run -it -p [external port]:[internal port] --name [container name] [image ID or tag name]

( -it) : This option enables an interactive mode for the container and allocates a pseudo-TTY. It allows you to interact with the container's command-line interface.
(-p) : [external port]:[internal port] : This option maps an external port to an internal port of the container. Replace , [external port], with the desired port on your host machine and , [internal port], with the corresponding port inside the container.,
(--name) [container name] : This option assigns a specific name to the container. Replace , [container name], with your desired name.
[image ID or tag name] : This is the ID or tag name of the Docker image you want to use for creating the container.

To run the build image of your application in a container, use the following Docker command:



    docker run -it -p 8090:8090 --name single ts/single

This Docker command runs a container named "single" from the "ts/single" image. It allocates a terminal (-it), maps port 8090 on the host to port 8090 in the container (-p 8090:8090), allowing interaction with the containerized TypeScript application.

If you can see this message, congratulations!

You have successfully created a Docker image with a TypeScript Express app. To verify its functionality, please visit the "/health" route of the server.

The issues with the normal container.

The current issue lies in the excessive size of the Image. Despite avoiding the utilization of numerous packages, the Docker image size reaches a staggering 1.14GB. This contradicts the fundamental objective of containerizing the application into a compact file, as it essentially transforms into a virtual machine (VM).

Let's explore the steps to resolve these issues.

1. Using && instead of 2 RUN Commands

When building Docker containers, aim for smaller images. Shared layers and smaller sizes lead to faster transfer and deployment. But how do you manage size when each RUN statement creates a new layer and intermediate artifacts are needed? Many Dockerfile use unconventional techniques to address this issue.



    FROM ubuntu

    RUN apt-get update && apt-get install vim

Why the &&? Why not running two RUN statements like this?



    FROM ubuntu

    RUN apt-get update
    RUN apt-get install vim

Docker layers store the difference between image versions. Like git commits, they are useful for sharing with other repositories or images. When you request an image, you only download the layers you don't already have, making sharing more efficient. However, layers use space and increase the size of the final image. Combining multiple RUN statements on a single line was a common practice.

We have already implemented this point, so there is no need to worry. Now, let us explore other areas for improvement.

2. Multistage docker builds

When creating Docker images for applications, developers often need additional tools and dependencies during the build process that are not required for the final runtime image. Including these unnecessary elements in the final image can result in larger image sizes, which may impact performance and security.

Traditional Docker app.

What is docker multistage?

Docker multistage builds are a feature that allows you to use multiple FROM statements in a single Dockerfile. This enables you to build and compile your application in one stage and then copy only the necessary artifacts into a smaller and more efficient image for runtime in the final stage. The primary goal is to create smaller Docker images by eliminating unnecessary build dependencies and files.

Using multistage build

This Dockerfile utilizes multistage builds to separate the build and runtime environments effectively. In the first stage, the application is compiled and built, while the second stage focuses on creating a smaller and more efficient image specifically for running the application. By adopting this approach, the final image size is reduced, unnecessary build artifacts are excluded from the runtime environment, and both security and efficiency are enhanced.

Below is a simplified example of a Dockerfile that demonstrates the use of multistage builds for your application

Now we understand that Typescript is essential during the development process only. We can utilize Typescript to build the JavaScript file during the builder stage and then use the generated JavaScript file in the next phase, known as the runner stage.

Stage 1: Build Stage



    # Use Node.js 18 as the base image for the builder stage
    FROM node:18 as builder

    WORKDIR /build

    COPY package*.json .
    RUN npm install

    COPY . .

    RUN npm run build

The first stage involves setting up the build environment, also known as the builder. This builder can be utilized in subsequent stages for further development.
To generate the corresponding JS code in the builder phase, I copied the package.json, package-lock.json, and src files.
We have executed ,npm run build, which will generate a ,/dist, folder containing all the required JS files.

Stage 2: Runtime Stage



    # Use Node.js 18 as the base image for the runtime stage
    FROM node:18 as runner

    # Set the working directory within the container to /app
    WORKDIR /app

    # Copy package.json from the build stage to the working directory
    COPY --from=builder build/package*.json .
    COPY --from=builder build/dist dist/
    COPY --from=builder build/.env .

    # Install only production dependencies
    RUN npm install --only=prod

    # Define the command to run the application
    CMD [ "npm", "start" ]

The second stage (runner) also uses Node.js version 18 as the base image but is intended for the runtime environment.
It sets the working directory within the container to /app.
package.json and package-lock.json is copied from the build stage to the working directory to ensure the correct production dependencies are available.
The dist, and .env files are copied from the builder stage to the working directory /app.
The RUN command(--only=prod) is used to install only the production dependencies, effectively reducing the size of the image.

Now let's create the image again using this multistage statergy in your application

Please update your Dockerfile with the code provided below.with code given below

Build The image with new [tag-name]. Here you can give any name as your wish we are gonna use t*s-docker/multistage*

Go to console and type:



    docker build -t ts-docker/multistage .

Output:

Use the updated image to run the container.



    docker run -it -p 8090:8090 --name multistage ts-docker/multistage

If you see this, you have successfully created a Docker image using a multistage build. You can check by going to the /health route of the server.

Now, let's take a look at the size of the image

In this case we have only removed the src/ directory and the devDependency packages containing all the code realated to typescript

The size is reduces but we still have the same problem the image is too big

(1.14 GB) --> (1.1 GM)

Using multistage builds is a highly effective approach to decreasing the final image size and eliminating unnecessary components from the runtime image. By doing so, it contributes to enhancing security and efficiency in your workflow.

What else can we do to reduce the size of image. Let see

3. Using slim version of runtime

By analyzing the code, it is evident that there is no further content that can be eliminated. However, even after removing excess content, the image size remains excessively large. Therefore, based on first principles, it can be deduced that the root issue lies in the initial size of the node base image.

The current image includes Node.js, yarn, npm, bash, and other binaries. It is based on Ubuntu, providing a fully fledged operating system. However, when running a container, only Node.js is necessary. Docker containers should only contain the essential components to run a single process, without needing an operating system. In this case, everything except Node.js could be removed.

By using smaller base images with Alpine

In other words, a Linux distribution that is smaller in size and more secure.

You shouldn't take their words for granted. Let's check if the image is smaller.

You should tweak the Dockerfile and use node:alpine

Create a image for this Dockerfile config.

Go to console and type:



    docker build -t ts-docker/alpine .

Now, let's take a look at the size of the image

Yaayy!!! 🥳🥳 as you can see the size of the image is now 147 MB from 1.1 GB

Transitioning from a larger Node.js image in the build stage to a more streamlined Alpine-based image in the runtime stage significantly trims the overall image by almost 1 GB. The Alpine base contains only the essential commands for execution, enhancing efficiency and minimizing the container's footprint, resulting in a more optimized and lightweight deployment.

What have we achieved:

Smaller Image Size: image is lightweight, resulting in significantly reduced image sizes, promoting faster downloads, and efficient resource utilization.
Enhanced Security: Alpine is designed with security in mind, offering a minimal and secure environment, reducing the attack surface, and including security-focused components like Musl libc and BusyBox.
Container Best Practices: Aligns well with containerization best practices, emphasizing simplicity, minimizing unnecessary components, and ensuring cleaner and more efficient Dockerfile with multistage approach
Faster Builds and Deployment: Smaller images lead to faster build times and quicker deployments, especially beneficial in CI/CD pipelines and scenarios requiring rapid scaling.

In conclusion, whether optimizing Docker images, implementing multistage builds, or choosing a specific Node.js image, the overarching goal is efficiency, security, and adherence to best practices.

🚀 If you had a blast exploring. Stay tuned for the next blog where we'll explore more such topics. Don't forget to share this blog with your tech-savvy pals! Together, we're coding our way to greatness. 🚀💻

Follow me @Raunak Gurud ❤️⚡

WebSockets Unlocked: Mastering the Art of Real-Time Communication

Raunak Gurud — Sun, 14 Jan 2024 11:42:04 +0000

Hey there! 🌟 Ready to dive into the exciting world of real-time communication with WebSocket? 🚀 Join me in this series where we'll start from the basics, craft awesome chat/video apps, and master scaling with Redis and Kafka. Get set for a journey filled with interactive learning! 🌐💬✨ #RealTimeWeb #WebSocketAdventures

Learning about websockets can be a bit tricky at first, but once you get the hang of it, it becomes quite easy. I would definitely recommend taking the time to learn about websockets, as they are an essential part of modern web development and can greatly enhance the real-time capabilities of your applications. Plus, mastering websockets opens up a whole new world of possibilities for interactive and dynamic web experiences. So, don't be discouraged by the initial challenges – the rewards of learning websockets are well worth the effort!

This blog serves as an introduction to websockets, explaining what they are and why you should consider building your application using websockets. It also covers the difference between http and websockets, as well as the benefits of using websockets.

You can only learn by building so in this blog we will also learn how to build a basic message application using websockets with Socket.io, Node.js, and React.

What is websocket

WebSockets are a communication protocol that provides full-duplex communication channels over a single, long-lived connection. Unlike traditional HTTP connections, which are stateless and involve the client making a request and the server responding, WebSockets allow for bidirectional communication between the client and server. This is built on top of TCP/IP, which means it is reliable and ensures that every packet is received.

HTTP is like sending letters where you ask for something, and then you wait for a reply. WebSocket is like having a phone call where you can talk back and forth instantly. Chat applications, online gaming, financial platforms, and live streaming is build using websockets.

let's look at some benefits of websocket

Full-duplex Communication can be imagine like using walkie-talkies where you and your friend can talk and listen at the same time. Full-duplex is like having a chat where both can speak without waiting, and that's how WebSockets let computers talk back and forth instantly.

Persistent Connection means once you connect your device to the internet (or a server), the link stays open as long as needed. It's like staying on a call without hanging up, making communication faster and more efficient.

Low Latency means there's minimal delay when sending and receiving information. It's like a really fast text conversation.

WebSockets use a ws:// or wss:// URI scheme, where ws stands for WebSocket and wss is WebSocket Secure (encrypted using TLS/SSL).

Playing with websockets

You might be asking where can you start using WebSocket and how can you use this well, Modern web browsers provide a WebSocket API that allows developers to work with WebSockets using JavaScript. This API includes methods for opening a WebSocket connection, sending and receiving messages, and handling events.

Open a web browser (Chrome, Edge, Safari, Brave) and type ctrl + shift + i to open the developer tools. Then, go to the console tab and write the following command.



// Create a variable called socket with a URL (echo wss)
let socket = new WebSocket("wss://ws.postman-echo.com/raw");

// Define a function to respond to the data received on the socket
socket.onmessage = function(event) {
    console.log('Message received: ' + event.data);
};

// Send a message using the socket.send() method
socket.send('Hello, server!');

wss://ws.postman-echo.com/raw (postman echo websocket server)

As you can see, we are creating a variable called "socket" which has a URL (echo wss). We are also defining a function which will respond to the data received on the socket. We are sending a message using the "socket.send()" method.

Now, move to the network tab and find the raw name response. You can see that this raw response is of type websocket.

Clicking on raw will allow you to see additional information about the request, such as the status code and headers.

Click on the message tab to view all the WebSocket messages that have been sent and received. The UpArrow denotes the message sent by us, while the DownArrow denotes the message received. Since we are using an echo server, we are getting the same response (refer to the previous image).

Go ahead and try this out on your own and experiment with it. You can also learn more about the WebSocket API on the MND documentation.

Building a simple chat application

Learning without building is not effective, which is why we are going to create a simple chat application where users can send and receive messages in real time.

src code

This is a basic app. We will build the proper UI in future blogs. Let's start coding.

Make sure you have node installed



node --version

I am using Node.js version v20.10.0. Any version above v18.17 should work.

Create the project folder containing two sub-folders named client and server.



mkdir chat-app
cd chat-app
mkdir client server

Server

Next, navigate into the server folder and create a package.json file.



cd server
npm init -y

Install Socket.io Server API,We would be using TypeScript for a better developer experience (DX) and take advantage of tsc-watch for constant reloading.



# Add socket.io
npm add socket.io

# Add dev dependencies
npm add -D tsc-watch typescript

# Preinstalled tsc globally
tsc --init 

# Change tsconfig.json 
"rootDir": "./src",    
"outDir": "./dist",                     

# start the server in dev
npm dev

set scripts in package.json



{
  "name": "server",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "dev": "tsc-watch --onSuccess \"node dist/index.js\"",
    "build": "tsc -p .",
    "start": "node dist/index.js"
  },
  "devDependencies": {
    "tsc-watch": "^6.0.4",
    "typescript": "^5.3.3"
  }
}

Lets start by creating a basic server using the built-in http module and start the server.



# index.ts

import http from "http";

async function init() {
  const httpServer = await http.createServer();

  const PORT = process.env.PORT ? process.env.PORT : 8000;

  httpServer.listen(PORT, () => {
    console.log(`http server started at ${PORT}...`);
  }); 
}

init();



npm run dev

if you see this everything is working as expected

Now we will be implementing socket logic using socket.io for building websockets. This library provides an abstraction layer on top of WebSockets, simplifying the process of creating real-time applications. For better maintainability, it is recommended to create a separate file for socket calls. To do this, navigate to the src folder, create a folder named services, and inside it, create a file named socket.ts under the services folder.

Here are the commands to create a class called SocketService which initializes a socket connection. You can obtain this connection by using the getIo() method and export this class.



# services/socket.ts
import { Server } from "socket.io";

class SocketService {

  // Create a variable _io with type Server from socket.io
  private _io: Server;

  constructor() {
    // Log a message when the SocketService is initialized
    console.log("init socket server");

    // Setup CORS policy to allow all ('*')
    this._io = new Server({
      cors: {
        origin: "*",
        allowedHeaders: ["*"],
      },
    });
  }

  // Initialize event listeners for the socket connection
  public initListeners() {
    // Get a reference to the _io instance
    const io = this._io;

    // Event listener for when a client connects to the WebSocket server
    io.on("connect", async (socket) => {
      // Log a message when a client connects, including their socket id
      console.log(`⚡ userId ${socket.id} connected`);

      // Log a message when socket user is disconnected
      socket.on("disconnect", () => {
        console.log(`🚫 userId ${socket.id} disconnected`);
      });
    });
  }

  // Getter method to access the _io instance from outside the class
  get io() {
    return this._io;
  }
}

// Export the SocketService class as the default export of this module
export default SocketService;

initListeners() method This method initializes event listeners for the WebSocket server. In this case, it sets up a listener for the "connect" event, which fires when a client connects to the server. It logs a message indicating the user id (socket id) of the connected client.

get io() method : This getter method allows external components to access the _io instance from outside the class.

Now add a event listener for message event this block will run when the server recevies a messages



// Event listener for "event:message"
socket.on("event:message", (msg) => {
  // Log the received message to the server console
  console.log("message received", msg);

  // Emit a "message" event to all clients with the received message
  io.emit("message", JSON.stringify(msg));
});

Import the SocketService to create a new socket instance and attach the socket to the server. Then, initialize all the listeners.



# index.ts

import http from "http";
// import socket service 
import SocketService from "./services/socket";

async function init() {
  const httpServer = await http.createServer();

  // initializing the socket server 
  const socketService = new SocketService();
  const PORT = process.env.PORT ? process.env.PORT : 8000;

  // attaching the server to the SocketService
  socketService.io.attach(httpServer);

  httpServer.listen(PORT, () => {
    console.log(`http server started at ${PORT}...`);
  });

  // initialize the socket listeners
  socketService.initListeners();
}

init();

start the server



npm run dev

as you can see the socket server is initialize and server is working on 8000 and a user is connected

Server work is done here🥳🥳

Client

Navigate to the client folder using your terminal and then create a new Next.js project with Tailwind CSS and TypeScript.

learn more about



cd client
npx create-next-app@latest ./

# options 
# tailwindcss typescript app/

Install socket.io-client, socket.io a library that provides an abstraction layer on top of WebSockets, simplifying the process of creating real-time applications.



npm install socket.io-client

Create a folder called context and add a file SocketProvider.tsx. This file serves as a wrapper around the app, allowing us to use the socket from anywhere within the app.



// context/SocketProvider.tsx

import React, { 
createContext, 
useCallback, 
useContext, 
useEffect, 
useState } from 'react'
import { Socket, io } from 'socket.io-client'

// Interface defining the structure of the SocketContext
interface ISocketContext {
  messages: string[]
  socket: any
  sendMessage: (msg: string) => void
}


const SocketContext = createContext<ISocketContext | null>(null)

// Custom hook for easily accessing the socket context
export const useSocket = () => {
  const state = useContext(SocketContext);
  if (!state) throw new Error(`state is undefined`);
  return state;
}

export const SocketProvider: React.FC<{ 
    children: React.ReactNode 
}> = ({ children }) => {

  // State to hold the socket instance 
  const [socket, setSocket] = useState<Socket>()
  // To hold all messages in socket connection
  const [messages, setMessages] = useState<string[]>([])

  // function to send a message from chat
  const sendMessage: ISocketContext["sendMessage"] = useCallback(
    (msg: string) => {
        console.log("sending msg...", msg)
        if (!socket) throw new Error("socket not ready")
        // emit event to send message from socket
        socket?.emit("event:message", { message: msg })
  }, [socket])


  const onMessageReceived = useCallback((msg: string) => {
    const { message } = JSON.parse(msg) as { message: string }
    // Set the msg received in the messages state
    setMessages((prev) => [...prev, message])
  }, [])

  // Effect to set up the socket connection when the component mounts
  useEffect(() => {
    // Create a new socket instance
    const _socket = io("http://localhost:8000")

    // Set up an event listener for the "message" event
    // This function if fired when the `message` is received from the backend
    _socket.on("message", onMessageReceived)

    // Set the socket instance in the state
    setSocket(_socket)

    // Cleanup function to disconnect the socket when the component unmounts 
    // for better performace
    return () => {
      setSocket(undefined)
      _socket.disconnect();
      _socket.off("message", onMessageReceived)
    }
  }, [])

  // Provide the socket context to the wrapped components
  return (
    <SocketContext.Provider value={{ socket, messages, sendMessage }}>
      {children}
    </SocketContext.Provider>
  )
}

The SocketContext defines a context named SocketContext that will hold the socket instance, messages, and a function to send messages.

The SocketProvider Component is a React functional component that wraps the entire application. It sets up the WebSocket connection, manages messages, and provides the socket context to its children.

The useEffect hook runs when the component mounts. It creates a new socket instance, sets up event listeners, and cleans up the socket and listeners when the component unmounts.

The useSocket Hook is a custom hook that uses the useContext hook to access the socket context. It throws an error if the context is not available.

Wrap the socket provider around the app to enable access to the socket from any part of the application.



// layout.tsx

import type { Metadata } from 'next'
import { Inter } from 'next/font/google'
import './globals.css'
import { SocketProvider } from '@/context/SocketProvider'

const inter = Inter({ subsets: ['latin'] })

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
}

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en"> 
      // This socketProvier will provide the state variable to all the 
      // cihldrens
      <SocketProvider>
        <body className={inter.className}>{children}</body>
      </SocketProvider>
    </html>
  )
}

Creating a Chat Application Layout and Design Using Tailwind CSS

To create the layout and design for a chat application, we will be using Tailwind CSS. In order to mark the file as a client component, we will utilize socket works as the client component only.

The handleSubmit function is called when the user submits a message. It checks if the message is not empty, clears the input field, and can potentially handle sending the message .



// page.tsx
"use client"

import { useState } from "react"
import { useSocket } from "@/context/SocketProvider"

export default function Home() {
  const [message, setMessage] = useState('')
  const { messages, sendMessage } = useSocket()

  const handleSubmit = () => {
    if (message === "") return;
    setMessage('');

    sendMessage(message)
  }


  return (
    <div className="m-10 h-[600px] flex flex-col border-2 rounded-md border-white p-2">
      <div className="h-full overflow-y-auto flex flex-col p-2 overflow-x-hidden gap-1">
        // space for displaying chat
      </div>
      <div className="flex ">
        <input
          onChange={(e) => setMessage(e.target.value)}
          type="text"
          value={message}
          placeholder="message..."
          onKeyDown={(e) => {
            if (e.key === "Enter") {
              handleSubmit()
            }
          }}
          className="bg-zinc-700 w-full px-6 py-2 rounded-md"
        />
        <button
          onClick={() => handleSubmit()}
          className="px-6 py-2 border-2 border-white rounded-md"
        >
          send
        </button>
      </div>
    </div >
  )
}

We can import the socket provider that we created earlier to send and display messages. usesocket() is a custom hook that enables us to interact with the state and function create.

Start the development server and open the browser to view the application at http://localhost:3000.



npm run dev

Open the application in two different tabs in incognito mode to ensure that it is working properly.

🥳Yaaaaaaay!!!🥳

Congratulations on building your first chat application using WebSockets!. It looks like you've provided a detailed guide on setting up a chat application using WebSockets with Socket.io, Node.js, and React. This is a comprehensive overview, covering both server and client implementations, as well as the layout and design using Tailwind CSS. Additionally, you've introduced key concepts like Full-duplex Communication, Persistent Connection, and Low Latency associated with WebSockets.

Here's a summary of the blog:

Introduction to WebSockets: Real-time communication using WebSockets for chat and video applications.

Benefits of WebSockets: Full-duplex Communication, Persistent Connection, Low Latency.

**Practical Example:**Connecting to a WebSocket server using browser developer tools.

Building a Simple Chat Application:

Setting up the server with Socket.io and Node.js.
Creating a basic layout for the chat application using React and Tailwind CSS.

This is just the beginning of your journey into real-time communication. Stay tuned for the next blog where we'll explore the limitations of WebSockets for scaling and how to overcome them.

🚀 If you had a blast exploring WebSockets and building that chat app, you're in for a treat! 🌟 This is just the beginning of your journey into real-time communication. Stay tuned for the next blog where we'll explore the limitations of WebSockets for scaling and how to overcome them. Don't forget to share this blog with your tech-savvy pals! Together, we're coding our way to greatness. 🚀💻 #TechAdventures #StayCurious"

Follow me @Raunak Gurud ❤️⚡