Hi all,
I recently discovered a frontend JS library called Datastar that uses "server-sent events" (SSE), which I'd never heard of before. Basically it seems to be like websockets but using a "normal" HTTP request that stays open indefinitely, and restricted to one-way push from the server to client.
This long-lived request model would seem like a bad fit for multithreading-based servers, since you'd quickly fill up the threadpool and stop accepting new requests.
There was a great thread from 2023 surveying the Nim webservers at the time. Am I right in understanding that the best options for async servers are still std/asynchttpserver and microasynchttpserver?
Or am I misunderstanding things and there's a simple solution that doesn't clog up the multithreaded servers (e.g. Guildenstern, Mummy etc)?
Regarding SSE, you don't use a single thread per connection. You can serve many connections from a thread.
Async SSE in my usual ugly code:
server: https://gist.github.com/ingoogni/d040454fbe0a339e01a808a25af3b5bc
client https://gist.github.com/ingoogni/459c79707065a8492651c0130954e5db
I think the better mental model is to think of Mummy as "async where it matters, for accept", it is not purely multi-threaded, but the API it exposes embraces threads, not async so the async stuff is kept local and does not affect your entire codebase.
This means SSE shouldn't cause problems for it.
Somebody correct me if I'm wrong.
fyi, here's an example of a server-sent events server, using chronos:
and the corresponding client:
Both use chronos via https://github.com/status-im/nim-presto/ which exposes REST services more generally.
There was a great thread from 2023
Regarding leaks, the post refers to https://github.com/status-im/nim-chronos/issues/377 which was a Nim bug, at the time. If anything, you want to stay away from std/asynchttpserver as much as possible (of which chronos is a fork that focuses, in part, on fixing leaks).
FWIW, We use (and develop) chronos extensively and observe no leaks generally - on the contrary, it's a lot less leaky than most others out there because it does not form cyclic references in its implementation meaning that the garbage collector can work more efficiently.
That said, I'm pretty sure there are metrics and benchmarks on which the multi-threaded servers perform better, if you want to go down that line of development - it's more a matter of the rest of your architecture, whether you want to deal with multithreading or not and then you choose the http server accordingly.