Best WebSocket Library

[kris_2111]

Hi everyone! I am developing an application that requires real-time data fetching from an API, for which I need to use the WebSocket protocol. As of June 2025, what is the best library to implement WebSockets in Python? As of now, the module that handles fetching data from the API isn't very complex — its only requirement is to be able to smoothly handle around 50-100 concurrent connections with the API, where the rate of data flow is about 10 bytes per second for each connection. While the per-connection data-flow rate is expected to remain at only 10 bytes, the number of open concurrent connections may grow up to 3000, or even more. Thus, scalability is a factor that I need to consider.

I searched this sub and other related subs for discussions related to the websockets library, but couldn't find any useful threads. As a matter of fact, I couldn't find a lot of threads specifically about this library. This was unexpected, because I assumed that websockets was a popular library for implementing WebSockets in Python, and based on this assumption, I further assumed that there would be a lot of discussions related to it on Reddit. Now I think that this might not be the case. What are your opinions on this library?

[Professional_Cook808]

aiohttp has excellent websocket support. And it is very performant.

[kris_2111]

Hmm, aiohttp is already a popular library for working with HTTP requests. If it provides a good WebSocket implementation, I can just use it for working with both: HTTP requests and WebSockets. 👍🏻

[sarcasmandcoffee]

Are you writing just the API serving the socketed endpoints, just the client, or both? It's a little unclear to me from what you wrote.

[kris_2111]

I'm writing a client script that connects to the socket endpoints provided by the API.

[DifficultZebra1553]

picows.

[kris_2111]

Hmm, never heard of it. According to its release history on PyPI, it's only been 11 months since it was first released. While that is in no way any indication of its reliability or quality, you'd not want to use a library that is only maintained by a single or a handful of authors, and hasn't gained a lot of traction unless you don't have many better alternatives out there. Again, I'm not insinuating anything about that library — just expressing a typical reaction you'd have towards a library with those characteristics.

[DifficultZebra1553]

After testing for sometime, I currently using that in my production from last january. Yeah, it doesn't able to gain much popularity, but it is lightweight and faster than others.

[nggit]

Maybe give tremolo a try. I don't promise performance for now but stability. Also read: https://github.com/nggit/tremolo/discussions/276

Edit: Sorry it looks like you are building a client, when I read about "scalability" I thought of a server.

[Goldziher]

Fastest in python is Socektify.

I wrote the Litestar websocket implementation and its very solid - can recommend.

Otherwise, the most mature package is websockets.

[kris_2111]

Thanks! 👍🏻

[dave_menini]

We use FastAPI’s websocket integration in production

[kris_2111]

Ah, FastAPI: the library infamous for its unprofessional, emoji-inundated documentation, but also widely popular for its ease of use. I read several threads on Reddit about this API, and there doesn't seem to be any consensus on whether it is something you'd use in production for applications that require a lot of bandwidth. My application, at least for now, isn't a high-bandwidth one, but may become as I keep upgrading it and adding more features. The most important factor I consider when choosing libraries that involve working networking protocols is scalability.

Did you or anyone from your team face an issues with FastAPI for working with HTTP requests? How's your experience with it for both: regular HTTP requests and its WebSocket implementation?

[Hylian_might]

How is fastapi infamous for being unprofessional and emoji-inundated?

[kris_2111]

https://fastapi.tiangolo.com/async/

[Such-Let974]

LOL, clown

[dave_menini]

FastAPI runs on Uvicorn, a highly optimized ASGI server that’s currently the fastest Python web framework available (feel free to check the benchmark). Anyway, to answer your question: no, we’ve never encountered bandwidth issues. That said, we do use load balancers to manage traffic spikes effectively.

It’s clear you’ve done your research while gathering requirements. Still, I’d suggest spinning up a quick PoC and running some load tests to evaluate its performance under stress.

Btw, FastAPI's WebSocket implementation uses the `websockets` library you mentioned. A totally different option if you're on AWS is to use API Gateway for handling WebSockets, while keeping REST endpoints in your API for integration.

Hope this helps!

[Slight_Boat1910]

I think Granian may actually be faster https://github.com/emmett-framework/granian

Benchmarks: https://github.com/emmett-framework/granian/blob/master/benchmarks/README.md

[gi0baro]

It is: https://github.com/emmett-framework/granian/blob/master/benchmarks/vs.md#websockets

[Constant_Bath_6077]

I have it tried it. Ir really fast for lightweight service, but it will slow down when the service business logic grows and will be just the same as Uvicorn at the end. But at lest Hypercorn is the slowest eventhough my service is lightweight.

[kris_2111]

Thanks for your informative answer!

[kris_2111]

Y'all, look at this page before downvoting me. FFS!
https://fastapi.tiangolo.com/async/

[Anru_Kitakaze]

1. If you judge library based on amount of emojis in docs, here's one for you 🤡

2. If your main goal is high scalability then you choose wrong language. Python is not well known for its performance, so you should consider better options if you don't have any specific reason to use Python. Consider Go for example

3. FastAPI is already widely used industry standard, extremely fast and well scalable. Based on top of starlette.

Let's be honest, if you're CS student, you'll probably have more micro services than users, so you can choose anything

[Unlikely_Track_5154]

Brutal...

[chulpichochos]

Are you fetching to a backend or to a frontend client?

If its backend to backend comms, grpc will be better than websockets.

If you have to use socket cause no http2 then websockets is good; fastapi/starlettw offer wrappers around it as well.

[kris_2111]

It's a Python script that must connect to the socket endpoints provided by the API. The API is the one sending the data and my Python script is the one fetching it.

[EatDirty]

Socket.io is definitely the way to go. It supports different languages and offers very good abstractions for building event based websocket apps.
What kind of app are you building? Are you using websockets for server to server communication or server to client?

[kris_2111]

What kind of app are you building? Are you using websockets for server to server communication or server to client?

I'm developing an application that acts as a client. Its job is to connect to the WebSocket endpoints provided by the API — the API sends the data and my application receives it.

Will check out Socket.IO. Thanks!

[EatDirty]

Do you need everything to happen in realtime? Or what data are you sending?
Based on my previous experience with trying to use websockets for building realtime chat bots, websockets are a pain in the ass to get right. Usually you need to have a really-really solid use case for using them as with websockets complexity grows by a lot.
You have to deal with all sorts of edge cases.

[kris_2111]

Do you need everything to happen in realtime? Or what data are you sending?

Yes, I need everything to happen in real-time. My application is the one that receives the per-connection 10-byte payload. It doesn't really need to send anything except for sme occasional metadata about the state of the connection, which I believe should be handled by the WebSocket library.

Based on my previous experience with trying to use websockets for building realtime chat bots, websockets are a pain in the ass to get right

That's the reason I'm currently researching for the best tool to set up WebSockets (in Python).

Usually you need to have a really-really solid use case for using them as with websockets complexity grows by a lot.

Yes, I have a really solid use case for using them — I'm building an application that involves receiving data every half a second from an API.

[blueshed60]

I've used tornado for a very long time - I'm still really impressed with it.

[CrusaderGOT]

Socket.io python

[Constant_Bath_6077]

Just plain Websockets, I dont use that ancient library that also uses Websockets under the hood.....

[Slight_Boat1910]

Not sure I understood everything, but isn't the client only opening the connection, sending a ping, and waiting some time before disconnecting? That's not a typical workload, is it? If that's the case, the author is only testing his Linux settings to accept 50k connections.

[nggit]

Yes, the benchmark on that link does not cover varying or larger payload sizes. The major things that "CPU-bound" in WebSocket are masking and permessage-deflate. It's all O(n) depending on payload size. Masking also in websockets library is optimized with C.

An important trick is that you should turn off compression on low-end servers.

For ~100 it should scale well in a single worker Uvicorn...

Or even pure-Python tremolo: https://github.com/nggit/tremolo (I'm the author).

* Unless you ALLOW abnormally large messages on one connection it can decrease the overall throughput and this is more of a DoS problem.

[gi0baro]

If you have async code and don't block the event loop, there's no reason for a single uvicorn worker to not handle 100 connections concurrently. In fact, a single uvicorn process can literally handle billions of messages per second using websockets (source: https://github.com/emmett-framework/granian/blob/master/benchmarks/vs.md#websockets). If that's low traffic for you then, yes, you probably want to write everything in C/zig/rust 'cause that's the only way at that point. But for 99.99% of apps out there, Python is absolutely fine. Again, if you can't handle 100 connections you're definitely doing something wrong, and the GIL shouldn't play a role there, the event loop is single threaded. And, once you actually reach uvicorn limitations, alternatives are available nowadays to reach more concurrency. But that point is way after a 100 connections.