Build a chat server with Cloud Run
Jaeyeon Baek
Google Cloud Champion Innovator
With Cloud Run — the fully-managed serverless container platform on Google Cloud — you can quickly and easily deploy applications using standard containers. In this article, we will explain how to build a chat server with Cloud Run using Python as the development language. We will build it with the FastAPI framework, based on this FastAPI sample source code.
[Note that this article does not provide detailed descriptions of each service. Refer to other articles for details like Cloud Run settings and the cloudbuild.yaml file format.]
Chat server architecture
The chat server consists of two Cloud Run services: frontend and backend. Code management is done on GitHub. Cloud Build deploys the code, and chat messages are passed between users with Redis pub/sub and Memorystore.
Set the “Authentication” option on the Cloud Run frontend service to “Allow all traffic” for frontend and backend. The two services communicate with a WebSocket, and backend and Memorystore can be connected using a serverless VPC access connector.
Let's take a look at each service one by one.
Frontend
index.html
The frontend service is written only in HTML. Only modify the WebSocket connection part with a URL of backend Cloud Run in the middle. This code is not perfect as it is just a sample to show the chat in action.
Dockerfile
The Dockerfile is very simple. Because it is deployed as HTML, nginx:alpine is a good fit.
cloudbuild.yaml
The last part of the frontend service is the cloudbuild.yaml file. You only need to edit the project_id and “frontend”.
Backend Service
main.py
Let's look at the server Python code first, starting with the core ChatServer class.
This is a common chat server code. Inside the ChatServer class, there is a publish_handler method and a subscribe_handler method. publish_handler serves to publish a message to the chat room (Redis) when a message comes in through the WebSocket. subscribe_handler delivers a message from the chat room (redis) to the connected WebSocket. Both are coroutine methods. Connect redis in run method and run coroutine method.
This brings us to the endpoint. When a request comes in, this code connects to the WebSocket and connects to the chat server.
Here is the rest of the code. Combined, you get the whole code.
Dockerfile
The following is the Dockerfile for the backend service. Run this application with Uvicorn.
requirements.txt
Put the packages for FastAPI and Redis into requirements.txt.
cloudbuild.yaml
The last step is the cloudbuild.yaml file. Just like the frontend service, you can edit the part composed of project_id and backend, and add the IP of the memorystore created at the back into REDIS_HOST.
Cloud Build
You can set Cloud Build to automatically build and deploy from Cloud Run when the source code is pushed to GitHub. Just select “Create trigger” and enter the required values. First, select “Push to a branch” for Event.
Next, go to the Source Repository. If this is your first time, you will need GitHub authentication. Our repository also has cloudbuild.yaml, so we also select the “Location” setting as the repository.
Serverless VPC access connector
Since both the Frontend service and the Backend service currently exist in the Internet network, you’ll need a serverless VPC access connector to connect to the memorystore in the private band. You can do this by following this example code:
Create memorystore
To create the memorystore that will pass chat messages, use this code:
chat test
To demonstrate what you should see, we put two users into a conversation in a chat room called “test”. This will work regardless of how many users you have, and users will not see the conversations in other chat rooms until they join.
Wrap-up
In this article, I built a serverless chat server using Cloud Run. By using Firestore instead of Memorystore, it is also possible to take the entire architecture serverless. Also, since the code is written on a container basis, it is easy to change to another environment such as GKE Autopilot, but Cloud Run is already a great platform for deploying microservices. Instances grow quickly and elastically according to the number of users connecting, so why would I need to choose another platform? Try it out now in the Cloud Console.