Chapter 8: Defining WebSockets for Two-Way Interactive Communication in FastAPI

The HyperText Transfer Protocol (HTTP) is a simple yet powerful technique to send or receive data to and from a server. As we've seen, the principles of request and response are at the core of this protocol: when developing our application programming interface (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 if new messages have 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...

Technical requirements

You'll need a Python virtual environment, 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

This will make it available on your local computer on port 6379.

You'll find all the code examples of this chapter in the dedicated GitHub repository at https://github.com/PacktPublishing/Building-Data-Science-Applications-with-FastAPI/tree/main/chapter8.

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 to serve 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, WebSocket
from 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.3 – Multiple clients connected through 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 of having...

Summary

In this chapter, you've learned how to work with one of the latest web technologies available: WebSocket. 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 a WebSocket 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 Apache Kafka or RabbitMQ is necessary to make this use case reliable across several server processes.

You are now acquainted...