wa-automate-nodejs VS rsocket-java

Love your hybrid model via gumroad! I do something similar for my own open-source project

https://github.com/open-wa/wa-automate-nodejs

There should be some sort of support group for those of us trying to monetize (sans donations) our open source projects!

if you can program in Node.js, or have an basic knowledge of javascript or are motivated to learn Node.js, then I would recommend looking at https://github.com/open-wa/wa-automate-nodejs

You can use a platform like otechie. There people are required to put in their card details before starting a conversation. This is what I do with open-wa (https://github.com/open-wa/wa-automate-nodejs#support)

Because I sell license keys to unlock features, it allows me to provide generalized support and quick bug fixes via the discord. If people need help with integration in their specific code base then that's when I ask them to go through the "consulting route" - if it's quick they use otechie. If it's more involved (1+ days) then we work out a contract arrangement.

I hardly get any clients through these means but it does put a clear value on my time which results in the community appreciating the time and effort into the project and the real time support (via discord).

TL;DR: WasmRS is an implementation of RSocket for WebAssembly giving you reactive, async streams in and out of WASM modules. GitHub | Protocol details | Rust source | Go source

You might also checkout https://rsocket.io/

My personal WebSockets vs SSE TL;DR goes something like this:

* If you're on HTTP/2, start with SSE

* If you need to send binary data, use WebSockets

* If you need fast bidi streaming, use WebSockets

* If you need backpressure and multiplexing for WebSockets, use RSocket or omnistreams[1] (one of my projects).

[0]: https://rsocket.io/

[1]: https://github.com/omnistreams/omnistreams-spec

A few years ago I was more inclined to use WebSockets. They're undeniably cool. But as implemented in browsers (thanks to the asynchronous nature of JavaScript) they offer no mechanism for backpressure, and it's pretty trivial to freeze both Chrome and Firefox sending in a loop if you have a fast upload connection.

I designed a small protocol[0] to solve this (and a few other handy features) which we use at work[1]. A more robust option to solve similar problems is RSocket[3].

More recently I've been working on a reverse proxy[2], and realized how much of a special case WebSockets is to implement. Maybe I'm just lazy and don't want to implement WS in boringproxy, but these days I advocate using plain HTTP whenever you can get away with it. Server Sent Events on HTTP/1.1 is hamstrung by the browser connection limit, but HTTP/2 solves this, and HTTP/3 solves HTTP/2's head of line blocking problems.

Also, as mentioned in the article, I try to prefer polling. This was discussed recently on HN[4].

[0]: https://github.com/omnistreams

[1]: https://iobio.io/2019/06/12/introducing-fibridge/

[2]: https://boringproxy.io/

[3]: https://rsocket.io/

[4]: https://news.ycombinator.com/item?id=27823109