Defining WebSockets for Two-Way Interactive Communication in FastAPI

HTTP is a simple yet powerful technique for sending data to and receiving data from a server. As we’ve seen, the principles of request and response are at the core of this protocol: when developing our API, our goal is to process the incoming request and build a response for the client. Thus, in order to get data from the server, the client always has to initiate a request first. In some contexts, however, this may not be very convenient. Imagine a typical chat application: when a user receives a new message, we would like them to be notified immediately by the server. Working only with HTTP, we would have to make requests every second to check whether new messages had arrived, which would be a massive waste of resources. This is why a new protocol has emerged: WebSocket. The goal of this protocol is to open a communication channel between a client and a server so that they can exchange data in real time, in...

Technical requirements

For this chapter, you’ll require a Python virtual environment, just as we set up in Chapter 1, Python Development Environment Setup.

For the Handling multiple WebSocket connections and broadcasting messages section, you’ll need a running Redis server on your local computer. The easiest way is to run it as a Docker container. If you’ve never used Docker before, we recommend you read the Getting started tutorial in the official documentation at https://docs.docker.com/get-started/. Once done, you’ll be able to run a Redis server with this simple command:

$ docker run -d --name fastapi-redis -p 6379:6379 redis

You’ll find all the code examples for this chapter in the dedicated GitHub repository at https://github.com/PacktPublishing/Building-Data-Science-Applications-with-FastAPI-Second-Edition/tree/main/chapter08.

Understanding the principles of two-way communication with WebSockets

You have probably noticed that the name WebSockets is a direct reference to the traditional concept of sockets in Unix systems. While technically unrelated, they achieve the same goal: to open a communication channel between two applications. As we said in the introduction, HTTP works only on a request-response principle, which makes the implementation of applications that need real-time communication between the client and the server difficult and inefficient.

WebSockets try to solve that by opening a full-duplex communication channel, meaning that messages can be sent in both directions and possibly at the same time. Once the channel is opened, the server can send messages to the client without having to wait for a request from the client.

Even if HTTP and WebSocket are different protocols, WebSockets have been designed to work with HTTP. Indeed, when opening a WebSocket, the connection is first initiated...

Creating a WebSocket with FastAPI

Thanks to Starlette, FastAPI has built-in support for WebSockets. As we’ll see, defining a WebSocket endpoint is quick and easy, and we’ll be able to get started in minutes. However, things will get more complex as we try to add more features to our endpoint logic. Let’s start simple, with a WebSocket that waits for messages and simply echoes them back.

In the following example, you’ll see the implementation of such a simple case:

app.py

from fastapi import FastAPI, WebSocketfrom starlette.websockets import WebSocketDisconnect
app = FastAPI()
@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    try:
        while True:
            data = await websocket.receive_text()
       &...

Handling multiple WebSocket connections and broadcasting messages

As we said in the introduction to this chapter, a typical use case for WebSockets is to implement real-time communication across multiple clients, such as a chat application. In this configuration, several clients have an open WebSocket tunnel with the server. Thus, the role of the server is to manage all the client connections and broadcast messages to all of them: when a user sends a message, the server has to send it to all other clients in their WebSockets. We show you a schema of this principle here:

Figure 8.4 – Multiple clients connected through a WebSocket to a server

A first approach could be simply to keep a list of all WebSocket connections and iterate through them to broadcast messages. This would work but would quickly become problematic in a production environment. Indeed, most of the time, server processes run multiple workers when deployed. This means that instead...

Summary

In this chapter, you learned how to work with one of the latest web technologies available: WebSockets. You are now able to open a two-way communication channel between a client and a server, allowing you to implement applications with real-time constraints. As you’ve seen, FastAPI makes it very easy to add such endpoints. Still, the way of thinking inside WebSockets logic is quite different from traditional HTTP endpoints: managing an infinite loop and handling several tasks at a time are completely new challenges. Fortunately, the asynchronous nature of the framework makes our life easier in this matter and helps us write concurrent code that is easily understandable.

Finally, we also had a quick overview of the challenges to solve when handling multiple clients that share messages between them. You saw that message broker software such as Redis is necessary to make this use case reliable across several server processes.

You are now acquainted with all the features...