HN Explorer

Show HN: Simple pub/sub using WebSockets in Node.js (npmjs.com)

13 points by durkes ↗ HN
I built this pubsub module because I wanted a simple solution that uses only node.

Why did I want pubsub? I wanted to build a complex app but segregate it into microservices that work together through event messages. I also wanted to use this method instead of node's built-in clustering for multiple instances. I've been running it for a few weeks now with several messages per second bugfree. I plan to use this setup for future apps as it reduces complexity of the code and allows me to restart/update one part of the app without interrupting the other parts.

I would love to receive feedback and suggestions on the code and features, and hope it can be useful to you also!

6 comments

[ 3.2 ms ] story [ 26.9 ms ] thread
omniscient_oce
I'd say one of the important ones for me is what are the mechanisms for retries under network loss or lack of connectivity in general. What is the behaviour/semantics of that? Can I buffer messages that then get backfilled when a recipient reconnects or do I need to do that in my code / application layer.
durkes
It's coded to retry connecting every 500ms. Usually the connection will have to timeout first, so it takes longer for each retry. I set my retries to Infinity.

Messages that the client publishes while trying to connect are pending also every 500ms to try to resend as soon as it connects. This might be something that should be customizable to return an error or retry in a future version.

Because this design is send and forget / fire and forget (similar to redis), messages published when a client is not connected will not make it to that client. If receipt confirmations are needed, it would need to be coded into the app using pubsub.

Thanks for the reply! I will get this info added to the docs soon.

melony
Any exponential backoff in the event of unresponsive endpoint? How doea the library deal with increasing backpressure?
durkes
There isn't any exponential backoff built-in, just the 500ms timeout in between fails. You can, however, set the number of retries to something you want your app to tolerate and then if it still fails, handle the error accordingly to pager duty or your own custom logic, etc.

Example w/ retries config: https://github.com/durkes/wubsub/blob/main/examples/client.j...

Regarding the backpressure for messages that the client is trying to publish while not connected, they will each be held in a setTimeout recursively until successful trying every 500ms also. If you build in your own custom receipt logic, this could be avoided. I considered building this in but wanted to keep it simple. Open to suggestions.