Centrifugo integration for real-time messaging (WebSocket) tasks

[FZambia]

Is your feature request related to a problem? Please describe.

How about adding Centrifugo integration into the boilerplate?

Centrifugo is a self-hosted server which can handle WebSocket connections and it provides API for the backend to publish messages to real-time channels. Clients connect to Centrifugo (and authenticate), subscribe to channels (and authorize). Then, once the backend publishes message to a channel where online subscribers exist, – message will be delivered instantly to all channel subscribers. Very similar to Pusher, Ably, PubNub – but self-hosted.

Generally, Centrifugo is rather performant and comes with many features outside basic PUB/SUB functionality.

Describe the solution you'd like

I see the integration similar to the one described in https://centrifugal.dev/docs/tutorial/intro.

It will mean at least:

• extending docker-compose.yaml to include Centrifugo service
• providing a helper API for issuing JWT for Centrifugo connections and its refresh. To authenticate connections to Centrifugo. Maybe it will be possible to reuse the same JWT as the boilerplate has now.
• providing a helper API for issuing subscription JWT for Centrifugo subscriptions - to authorize subscriptions to channels.
• providing a method to publish custom data to Centrifugo channels (HTTP POST to /api/publish)
• providing an integration with PostgreSQL outbox consumer for transactional outbox style of notification delivery. This will require creating CentrifugoOutbox model to which events may be inserted transactionally and those may be automatically consumed by Centrifugo. Users can decide whether to use publish over HTTP API or using outbox.
• Adding Nginx configuration to proxy WebSocket connections to Centrifugo.

This should provide a robust layer to introduce various kinds of real-time features in any project. Just initialize Centrifugo client SDK on the frontend, connect (providing api endpoint for JWT tokens), subscribe to channel (implementing channel auth in existing handler). And whenever event should be sent – use HTTP POST to Centrifugo API or enable outbox table consumption.

Also, FastAPI-boilerplate already depends on Redis, and it's exactly what is required to scale Centrifugo to many nodes – so users may benefit of that also.

Describe alternatives you've considered

Definitely it's possible to add WebSocket endpoint without introducing Centrifugo, but Centrifugo will solve some challenges:

• Real-time subscription multiplexing over a single connection, since Centrifugo comes with custom async protocol and a set of SDKs on top of it.
• Supports HTTP-based WebSocket fallbacks, solving the headache with WebSocket unavailability in corporate environments with proxies and custom root cert (rather common).
• Scalability of the real-time backend, many nodes of Centrifugo may be run to offload proper connection management in distributed systems from FastAPI keeping the backend stateless.
• Additional feature set - like online presence, hot message cache in channels for dealing with reconnections, etc.

Addition of Centrifugo is a universal and rather performant way to go when WebSocket is required for instant updates.