live_chat VS serverless_chat

When I first started this project, I wanted to build a live chat application, one of the fundamental pieces of software in any social product. I made an app using the popular Javascript express (server) and socket.io (websocket) libraries which worked fine in local development. When it came to deploying it online, I didn't want to just deploy it openly (without authentication) as there might be bots crawling the internet, looking for open websocket servers to spam and so on. On the other hand, I didn't want to use my domain for authentication (and registration) services for this pet project. The idea of using serverless JS workers came to me as I was thinking about how to architect the application with the least possible backend exposure. Luckily, several cloud vendors provide such services nowadays so it's only a matter of time to integrate with their interfaces.

Our worker implements a fetch listener (wrapped in an error handler) and passes on API requests further, to instantiate a ChatRoom class. The instance of this class runs as a Durable Object and creates chatrooms while handling sessions to this chatroom. Since we don't want to persist data, we don't store it anywhere and all data is lost as soon as the websockets enabling the sessions are disconnected / closed. The ChatRoom Durable Object also instantiates a RateLimiter class to ensure worker compute is not abused by heavy traffic, but is rather moderated via rate limiting.