DEV Community: Gopher wizards

Simple Go Chat Application in under 100 lines of code - Part 2

Adarsh A — Sat, 11 May 2024 11:41:26 +0000

This blog is the first part of a multi part series.

Simple Go Chat Application in under 100 lines of code - Part 1
Simple Go Chat Application in under 100 lines of code - Part 2

In the first part of our series, we explored the implementation of a basic broadcast chat application in Golang, leveraging WebSockets for real-time communication. Now, in Part 2, we delve deeper into enhancing the scalability of our chat application. We'll address a critical limitation of our initial approach and introduce Redis pub-sub as a solution. Join us as we optimize our chat app for scalability and robustness. Let's dive in!

To understand the scalability issue, let's first run multiple instances of our web application.

Lets begin with creating a Dockerfile for our application.



FROM golang:latest

WORKDIR /go/src/app

COPY go.mod go.sum ./

RUN go mod download

COPY . .

RUN go build -o go_chat .

EXPOSE 8080

CMD ["./go_chat"]

The above Dockerfile first downloads the dependencies using go mod download and then compiles our main.go to a binary named go_chat, which is then run inside the container.

We will be running an nginx container that will balance the load across multiple instances. Let’s create a docker-compose.yml file with the following content.



version: "3"

services:
  app:
    build: .
    deploy:
      replicas: 3
  nginx:
    image: nginx
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app

The above docker-compose file will create three replicas of our web application and an nginx server that will be accessible through http://localhost . It also creates a volume that maps a file nginx.conf to the file /etc/nginx/nginx.conf inside the nginx container.

Let’s create the nginx.conf file now.



events {
}

http {
    upstream go_chat {
        server app:8080;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://go_chat;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Host $http_host;
            proxy_set_header Upgrade websocket;
            proxy_set_header Connection Upgrade;
        }
    }
}

This configuration makes sure that any requests reaching localhost:80 are proxied to our web instances. It also sets some headers that are required for websockets to work as expected.

Also, we need to update the url used to create the websocket connection in index.html from localhost:8080/ws to localhost:80/ws since all requests will go through the nginx server.

Time for some experimentation!! Let’s run the docker containers.



docker-compose build
docker-compose up -d

Now, let’s test our chat app by opening localhost in two browser windows side by side.

Why isn’t our app working? Let's look at the server logs generated by individual containers.

From the logs, we can see that both the browsers' websocket connections are handled by different server instances and so messages broadcasted by go_chat-app-1 instance do not reach the clients connected to go_chat-app-2 instance, as each server only broadcasts to the connections handled by them.

Now, to solve this problem, we will be using the Pub/Sub feature of redis. Other than being a database, redis can also act like a message broker and we will be leveraging that in our web application. Lets install the redis client library written in go using go get



go get github.com/redis/go-redis/v9

Let’s create a redis client in the main function and pass it to the serveWs function.



func main() {
    redisHost := os.Getenv("REDIS_HOST")
    redisPort := os.Getenv("REDIS_PORT")
    rdb := redis.NewClient(&redis.Options{
        Addr: fmt.Sprintf("%s:%s", redisHost, redisPort),
    })

    // Rest of the main function
}

Let’s rewrite the serveWs function like this



func serveWs(rdb *redis.Client) func(c *gin.Context) {
    return func(c *gin.Context) {
        upgrader := websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true }}
        conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
        if err != nil {
            log.Printf("Error in upgrading web socket. Error: %v", err)
            return
        }

        go handleClient(conn, rdb)
    }
}

Let’s see what has changed

serveWs is now a function that accepts a redis client and returns a gin handler.
The redis client is passed to the handleClient function.

Now let's modify the handleClient function



const channel = "chat"

func handleClient(c *websocket.Conn, rdb *redis.Client) {
    defer func() {
        delete(clients, c)
        log.Println("Closing Websocket")
        c.Close()
    }()
    clients[c] = struct{}{}

    for {
        var msg Message
        err := c.ReadJSON(&msg)
        if err != nil {
            log.Printf("Error in reading json message. Error : %v", err)
            return
        }

        msgBytes, err := json.Marshal(msg)
        if err != nil {
            fmt.Println("Err marshaling", err.Error())
            return
        }

        err = rdb.Publish(context.Background(), channel, string(msgBytes)).Err()
        if err != nil {
            fmt.Println("Error publishing:", err.Error())
        }
    }
}

The handleClient no longer calls broadcast to send messages to other connections. Instead every message received from a connection is published to a redis channel called chat using the rdb.Publish method.

But how will we consume these messages from redis? To do that, let’s run a go routine that is called inside the main function.



func main() {
    redisHost := os.Getenv("REDIS_HOST")
    redisPort := os.Getenv("REDIS_PORT")
    rdb := redis.NewClient(&redis.Options{
        Addr: fmt.Sprintf("%s:%s", redisHost, redisPort),
    })

    go func() {
        ctx := context.Background()
        sub := rdb.Subscribe(ctx, channel)
        for {
            message, err := sub.ReceiveMessage(ctx)
            if err != nil {
                fmt.Println("Error receiving message", err)
            }
            if message != nil {
                broadcast([]byte(message.Payload))
            }
        }
    }()

    router := gin.Default()
    // Rest of the main function
}

The go routine subscribes to the same redis channel chat and reads all messages that are published to that channel using an infinitely running for loop. The message is then broadcasted to all websocket clients using the broadcast function.

This is how the final main.go file will look like,



package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "os"

    "github.com/gin-gonic/gin"
    "github.com/gorilla/websocket"
    "github.com/redis/go-redis/v9"
)

const channel = "chat"

func main() {
    redisHost := os.Getenv("REDIS_HOST")
    redisPort := os.Getenv("REDIS_PORT")
    rdb := redis.NewClient(&redis.Options{
        Addr: fmt.Sprintf("%s:%s", redisHost, redisPort),
    })

    go func() {
        ctx := context.Background()
        sub := rdb.Subscribe(ctx, channel)
        for {
            message, err := sub.ReceiveMessage(ctx)
            if err != nil {
                fmt.Println("Error receiving message", err)
            }
            if message != nil {
                broadcast([]byte(message.Payload))
            }
        }
    }()

    router := gin.Default()
    router.StaticFile("/", "./static/index.html")
    router.GET("/ws", serveWs(rdb))
    err := router.Run()
    if err != nil {
        log.Fatalf("Unable to start server. Error %v", err)
    }
    log.Println("Server started successfully.")
}

func serveWs(rdb *redis.Client) func(c *gin.Context) {
    return func(c *gin.Context) {
        upgrader := websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true }}
        conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
        if err != nil {
            log.Printf("Error in upgrading web socket. Error: %v", err)
            return
        }

        go handleClient(conn, rdb)
    }
}

var clients = make(map[*websocket.Conn]struct{})

type Message struct {
    From    string `json:"from"`
    Message string `json:"message"`
}

func broadcast(msgBytes []byte) {
    for conn := range clients {
        conn.WriteMessage(websocket.TextMessage, msgBytes)
    }
}

func handleClient(c *websocket.Conn, rdb *redis.Client) {
    defer func() {
        delete(clients, c)
        log.Println("Closing Websocket")
        c.Close()
    }()
    clients[c] = struct{}{}

    for {
        var msg Message
        err := c.ReadJSON(&msg)
        if err != nil {
            log.Printf("Error in reading json message. Error : %v", err)
            return
        }

        msgBytes, err := json.Marshal(msg)
        if err != nil {
            fmt.Println("Err marshaling", err.Error())
            return
        }

        err = rdb.Publish(context.Background(), channel, string(msgBytes)).Err()
        if err != nil {
            fmt.Println("Error publishing:", err.Error())
        }
    }
}

Now, let’s understand how this solution works.

Each app server maintains its own set of connections as it was previously. However, when a message is sent by any client connection, it is published to the redis channel. This message is then consumed by all the app servers and they broadcast the same to the connections they maintain in the clients map. Thus, every websocket client connection will receive the message, regardless of the server to which it is connected to.

Now, let's make changes in our docker-compose file to spin up a redis container.



version: "3"

services:
  app:
    build: .
    deploy:
      replicas: 3
    environment:
      - REDIS_HOST=redis
      - REDIS_PORT=6379
    depends_on:
      - redis
  nginx:
    image: nginx
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app
  redis:
    image: redis

Let’s test our solution by once again opening two browser windows side by side and sending messages.

In conclusion, we've successfully addressed the scalability limitations of our chat application by integrating Redis pub-sub. By leveraging Docker for containerization and nginx for load balancing, we've achieved a robust and scalable architecture. With Redis acting as a message broker, our application now seamlessly distributes messages across multiple instances, ensuring real-time communication regardless of server distribution. This implementation not only enhances scalability but also lays the foundation for further optimizations and feature enhancements. Cheers to building resilient, real-time applications with Golang!

Simple Go Chat Application in under 100 lines of code - Part 1

Aswath S — Sat, 04 May 2024 08:39:35 +0000

This blog is the first part of a multi part series.

Simple Go Chat Application in under 100 lines of code - Part 1
Simple Go Chat Application in under 100 lines of code - Part 2

Yes you read it right! This blog provides a comprehensive guide on creating a straightforward broadcast chat application in under 100 lines of Golang code.

The blog is structured into two parts.

The initial segment delves into the implementation of a chat application using the Gorilla websockets package in Golang, accompanied by a basic static HTML page for the chat interface. In the subsequent section, we will explore enhancing the scalability of the application by incorporating Redis pub-sub.

Why Websockets over HTTP ?

Websockets offer bidirectional, low-latency communication, ideal for real-time applications, unlike HTTP's request-response nature.
This choice eliminates the need for polling for new messages from the user interface.

Let’s dive into how we can implement a websocket based chat application in Golang.

Let’s start by creating a directory called go_chat and initializing a new go module.



mkdir go_chat
cd go_chat
go mod init go_chat

Let’s install the dependencies using go get



go get github.com/gin-gonic/gin
go get github.com/gorilla/websocket

Let's write a simple main.go file with a main() function that initializes a Gin server.



package main

import (
    "log"
    "github.com/gin-gonic/gin"
)

func main() {
    router := gin.Default()
    err := router.Run()
    if err != nil {
        log.Fatalf("Unable to start server. Error %v", err)
    }
    log.Println("Server started successfully.")
}

Next, let’s write a gin handler to handle websocket connections



func serveWs(c *gin.Context) {

    upgrader := websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true }}
    conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
    if err != nil {
        log.Printf("Error in upgrading web socket. Error: %v", err)
        return
    }

    go handleClient(conn)
}

Let's break down the serveWs function.

Websockets start with an HTTP handshake, then upgrade to a persistent TCP connection for full-duplex communication. In order to do this, we need to upgrade the HTTP connection using websocket.Upgrader from the gorilla websockets package.
The websocket.Upgrader accepts a CheckOrigin function to handle CORS. Note: For demonstration purposes, we have implemented the CheckOrigin function to always return true. (Refrain from implementing this in a production setting unless you're willing to expose yourself to potential CSRF attacks).
The Upgrade function takes in an http.ResponseWriter and an http.Request, and returns a websocket.Conn and an error if there is one.

Now that we have the websocket connection, let’s write a goroutine handles the connection.



var clients = make(map[*websocket.Conn]struct{})

type Message struct {
    From    string `json:"from"`
    Message string `json:"message"`
}

func handleClient(c *websocket.Conn) {
    defer func() {
        delete(clients, c)
        log.Println("Closing Websocket")
        c.Close()
    }()
    clients[c] = struct{}{}

    for {
        var msg Message
        err := c.ReadJSON(&msg)
        if err != nil {
            log.Printf("Error in reading json message. Error : %v", err)
            return
        }

        // process the message
        broadcast(msg)
    }
}

Let’s see what we are doing here.

We’ve created a map clients to store the websocket connections
Inside handleClient, we make sure to store the client connection in the clients map
Then we spin up an indefinite for loop to listen for messages from the connection.
Whenever we receive a message from the connection, it’s read using the ReadJSON method that reads and marshals the data into a Message struct.

Now that we’ve read the message, we’ll see more on how we can broadcast it to all other websocket connections



func broadcast(msg Message) {
    for conn := range clients {
        conn.WriteJSON(msg)
    }
}

The above function simply takes in a message and writes it to all websocket connections using the WriteJSON method using a for loop.

Now, let’s write a simple index.html file and save it inside a static folder that will act as the chat interface.



<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Go chat 🚀</title>
</head>

<body>
    <div style="display: flex;flex-direction: column;">
        <div id="inputs">
            <form onsubmit="handleSubmit(event)" method="post">
                <input id="username" type="text" name="username" placeholder="username" required>
                <input id="message" type="text" name="message" placeholder="what's on your mind ?" required>
                <input type="submit" value="Send">
            </form>
        </div>
        <div id="messages" style="display: flex;flex-direction: column;"></div>
    </div>
</body>

<script>

    const websocket = new WebSocket("ws://localhost:8080/ws");

    function handleSubmit(e) {
        e.preventDefault();
        websocket.send(JSON.stringify({
            "from": e.target.username.value,
            "message": e.target.message.value
        }))
    }

    websocket.onmessage = function (event) {
        const message = JSON.parse(event.data)
        messages.innerHTML += `<p><b>${message.from}</b> says ${message.message}</p>`
    }
</script>

</html>

The above HTML file, when opened, creates a websocket connection with the backend and sends a message whenever the form is submitted. It also listens for incoming messages using the onmessage handler.

Let’s update the main function to serve the index.html and also wire up the websocket handler.



...

func main() {
    ...
    router.StaticFile("/", "./static/index.html")
    router.GET("/ws", serveWs)
...
}
...

The final main.go file looks something like this.




package main

import (
    "log"
    "net/http"
    "github.com/gin-gonic/gin"
    "github.com/gorilla/websocket"
)

func main() {

    router := gin.Default()
    router.StaticFile("/", "./static/index.html")
    router.GET("/ws", serveWs)
    err := router.Run()
    if err != nil {
        log.Fatalf("Unable to start server. Error %v", err)
    }
    log.Println("Server started successfully.")
}

func serveWs(c *gin.Context) {

    upgrader := websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true }}
    conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
    if err != nil {
        log.Printf("Error in upgrading web socket. Error: %v", err)
        return
    }

    go handleClient(conn)
}

var clients = make(map[*websocket.Conn]struct{})

type Message struct {
    From    string `json:"from"`
    Message string `json:"message"`
}

func broadcast(msg Message) {
    for conn := range clients {
        conn.WriteJSON(msg)
    }
}

func handleClient(c *websocket.Conn) {
    defer func() {
        delete(clients, c)
        log.Println("Closing Websocket")
        c.Close()
    }()
    clients[c] = struct{}{}

    for {
        var msg Message
        err := c.ReadJSON(&msg)
        if err != nil {
            log.Printf("Error in reading json message. Error : %v", err)
            return
        }

        broadcast(msg)
    }
}

Now let’s run the application and open localhost:8080 in a browser.



go run .

Ta-da ✨! We’ve successfully built a simple chat application with Websockets in less than 100 lines of code.

However, this solution has one big drawback i.e, it cannot be deployed in a scalable manner.

In the next part, we’ll go through in detail about this problem and how we can solve it with Redis pub sub. Stay tuned !