SSE are single direction (server to client), you could use a http get/post for message from the client but then if you have multiple servers it could land of another server. Websockes allow you to have the server end processed in one place.
The big advantage of SSE when doing a simple event stream from the server is that they can be implemented in stacks that don’t support Websockes, such as many of the older Python frameworks (i.e. Django) built on top is WSGI. To use Websockes with these frameworks they either need upgrading to ASGI (or equivalent) or you have to run an additional server process for Websockes.
I do a lot of Django, SSE are super easy with it, just a StreamingResponce implementing the SSE protocol. I have then tended to use Gevent with Gunicorn to handle the long streaming responses rather than the default threaded workers.
There are few caveats around implementing a heartbeat event and ensuring they are closed properly when the client disconnects. This can be super annoying, I tent to kill the connection every couple of minutes as you don’t always know when the client has disconnected. Also buffering in reverse proxy’s need to be worked around.
To be honest though as Django gains better support for Websockes I would probably use them over SSE even for a single direction event stream, less edge cases to think about.
Just curious, is there anything wrong or missing from Django's current websockets support? Django has supported websockets via ASGI and Channels since 3.0 (about two years ago)? I'm working on a Django project that will require updating clients async.
Nothing particularly now, however if you are working on an older stack that hasn’t migrated to ASGI it’s just not particularly easy.
For long running responses like websockets and SSE you really need to use none threaded worker processes (one websocket connection would clog up a a single worker thread). Until recently the best way to do this was with Gevent with Gunicorn. The asyncio stuff that is coming to Django is a great addition, they have just merged async querysets. However it’s not the full framework yet and so although views and querysets are async, the db adapters are not yet and use a thread pool internally. I’m hoping they get to that level of the framework soon, it’s been a sessions undertaking to asyncify the Django api.
I like the idea of continuing to use the original sync api everywhere except on websocket/SSE views or views with a lot of io (many db query’s and http api calls) where it has a proper advantage.
I haven’t looked in detail recently but I would still consider whether going Gevent/Gunicorn (which is basically magic) is better than asyncio at the moment for Django. May be worth doing some benchmarking.
I kind of wish Gevent had won the battle with Asyncio.
Thanks for the in-depth response. That's really great news about async querysets getting merged! Even with adapter thread pooling, that should dramatically increase Django's throughput and hopefully make it competitive with newer frameworks like FastAPI. I've been impressed that Django has managed to transition to async views basically without any major problems (that I've heard about). Now that they're going async with the ORM, that feels even more risky and something that should probably go slowly. With all the improvements in Django combined with new-ish JavaScript libraries like HTMX/Unpoly, it really feels like new life is being injected into the framework.
The big advantage of SSE when doing a simple event stream from the server is that they can be implemented in stacks that don’t support Websockes, such as many of the older Python frameworks (i.e. Django) built on top is WSGI. To use Websockes with these frameworks they either need upgrading to ASGI (or equivalent) or you have to run an additional server process for Websockes.
I do a lot of Django, SSE are super easy with it, just a StreamingResponce implementing the SSE protocol. I have then tended to use Gevent with Gunicorn to handle the long streaming responses rather than the default threaded workers.
There are few caveats around implementing a heartbeat event and ensuring they are closed properly when the client disconnects. This can be super annoying, I tent to kill the connection every couple of minutes as you don’t always know when the client has disconnected. Also buffering in reverse proxy’s need to be worked around.
To be honest though as Django gains better support for Websockes I would probably use them over SSE even for a single direction event stream, less edge cases to think about.