Fastapi: [QUESTION] Delivering real time JSON packages to clients on events

[mr-bjerre]

First check

• [x] I used the GitHub search to find a similar issue and didn't find it.
• [x] I searched the FastAPI documentation, with the integrated search.
• [x] I already searched in Google "How to X in FastAPI" and didn't find any information.

Description

I have to deliver JSON packages to clients when specific events happens. I imagine building a FastAPI application where people can subscribe and add some callback. Is this the industry-standard of doing things (and is this the right place to look)? I imagine some /subscribe POST with callback instructions and /unsubscribe.

Alternatively I could require people to set up some kind of server to receive the data of course and then HTTP POST e.g.

If this question is out of scope here then please let me know and just close the question. Thank you.

[retnikt]

Webhooks are a fairly common approach; clients can register a URL to be called automatically on some action, but this requires them to set up a server of their own. GitHub has its own webhooks which could give you an idea of the implementation. This is what the so-called "OpenAPI callbacks" in the FastAPI docs are, but the implementation there is a little unusual I would say.

Alternatively, if you want something more real-time, you could look in to using Websockets, but FastAPI isn't really the right tool for the job in this case. Starlette (the basis of FastAPI), however, has some pretty good websocket support. Discord uses websockets for event listening.

[mr-bjerre]

Thanks tiangolo!

Just out of curiosity; why isn’t fastapi the right tool for it when you support web sockets using starlette? Just wondering what the difference would be to change to starlette directly? Is it just because fastapi isn’t really necessary?

[retnikt]

FastAPI's validation and dependency injection magic basically don't apply to websockets, so there's not awfully that much use in doing it. If your app already uses websockets, it's perfectly fine to use FastAPI's ones.

PS: I'm not tiangolo

[mr-bjerre]

Ha sorry I don’t know why I thought he answered.

Thank you retnikt! 🙏

[mr-bjerre]

Diving into the websockets area confuses me though. The examples I've seen from starlette and FastAPI both involves a HTML response with some JS code, e.g. this gist. I assume that HTML with js code is not necessary though?

Basically I want an application that supports

1. Authentication and authorisation.
2. Sends a message to all subscribers (I imagine a socket from the server to each subscriber) on events (data change in firestore).

So it is a one-way message system and not both ways. But how do clients actually connect?

Obviously websockets is a new area for me (sorry for that)...

[retnikt]

Correct, the HTML and JS code there is just a simple example of a client implementation. There are libraries for all sorts of languages and platforms for accessing websockets.

[tiangolo]

Thanks for the help here @retnikt !

So, about WebSockets, I would actually suggest you don't use them unless you are sure that you need them. It's a great but new technology, there are many things in its early stages. For example, web browsers can't set headers to be sent with WebSockets. And they give you a very raw stream of data, more similar to TCP than to HTTP. That means that then you have to implement all the logic that is normally implemented in the HTTP standard in your own app. Including data format, validation, authentication, error handling, and reconnections (that alone is a lot of code to write on your own).

If your use case can be solved with a simple callback done with HTTPX from your FastAPI to the other API, that could be a much simpler way to solve it and still be quite robust.

WebSockets shine in "real-time" stuff, e.g. that one user draws a line in the screen and the other users see the same line being drawn almost exactly at the same time. Or something like a terminal (e.g. Termpair) where you need to see each character typed exactly at the moment it is typed.

But for example, for something like a chat, where you don't see the other person typing as they type, but only the message once they send it, that can be implemented with HTTP probably in a much simpler way.

[mr-bjerre]

Thanks for the feedback!

Sounds like I actually don’t need websockets. I basically won’t to be able to subscribe to my app; e.g my app publishes news every 30 minutes. As a client I want to react on that, I.e. I want to trigger some local action when the news are published. I don’t know how to implement that - not sure FastAPI is the right tool either.

I hope it makes sense - please let me know otherwise.

[dbanty]

@mr-bjerre a common pattern (and then one I've followed in a few places) is to use the web sockets for _very basic_ information only. Not sure how your schema is set up, but let's say each new piece of news has some unique ID that users can use to pull from a normal FastAPI endpoint. You could, on publish, push just that new ID to clients via websocket. Then, the client could fetch the full details (with all the glory of the OpenAPI schema) with a normal HTTP call.

I've only used SocketIO, which utilizes websockets but also allows for long polling for older clients. It has some additional features that make sending/receiving events easy.

One other thing you might consider is using GraphQL instead of REST. GraphQL has a concept of subscriptions I believe (though I've never actually used them) and is supported fairly well on Starlette.

Either way I don't think FastAPI itself will solve your real time problem

[haizaar]

If you do decide to go with WebSockets you may want to look into this project: https://crossbar.io/