deno_std icon indicating copy to clipboard operation
deno_std copied to clipboard

proposal: bring back the `ws` module

Open lino-levan opened this issue 1 year ago • 2 comments

Is your feature request related to a problem? Please describe.

Originally brought up by @lowlighter on the discord.

is there something like a websocket standard framework ? that would provide helpers/utilities like rooms, grouped/directed messaging, autoreconnect, etc. ? a bit like socket.io was offering (seems overkill to use it as native ws are pretty capable on their own now

One of the biggest libraries in the npm ecosystem is socket.io, for good reason. socket.io bridged the gap between websockets and long polling when websockets weren't mature enough in browsers. Nowadays, websockets are available everywhere so a lot of the complicated abstractions that socket.io relied on are no longer useful.

Today, websockets are almost perfect except for a few things:

  • Client side: No autoreconnect, the logic is a little complicated but all applications share this same need
  • Server side: No rooms, no grouped messaging, no safety around when can send to clients or not

This use case is so prevalent that Bun decided to implement it natively (not that I necessarily approve):

Bun.serve({
  fetch(req, server) {}, // upgrade logic
  websocket: {
    message(ws, message) {}, // a message is received
    open(ws) {}, // a socket is opened
    close(ws, code, message) {}, // a socket is closed
    drain(ws) {}, // the socket is ready to receive more data
  },
});

Describe the solution you'd like

I'd love to see something similar to Bun or socket.io built into the std that address the above usecases, both for the client and the server.

Describe alternatives you've considered

We could just tell people to reimplement the logic themselves every time, but I've definitely gotten tired of that.

lino-levan avatar Aug 21 '24 02:08 lino-levan

Specific API proposals are also welcome.

No rooms, no grouped messaging, no safety around when can send to clients or not

Room or group concept sounds a bit application specific to me. Is there any (de facto) standard way to manage these in websocket context?

kt3k avatar Aug 21 '24 04:08 kt3k

Room or group concept sounds a bit application specific to me. Is there any (de facto) standard way to manage these in websocket context?

It's basically another name for the publisher/subscriber pattern, which imho is agnostic enough to be part of the possible API.

Inspiration could be taken from socket.io directly, from message brokers (redis, nats, etc.) or even using EventTarget interface (though I'd advise against as it'd bring many limitations)

lowlighter avatar Aug 21 '24 06:08 lowlighter