rsocket-java VS pushpin

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

Along with the reconnect solution already mentioned, you can also decouple your Websocket and business logic layers using something like Pushpin: https://pushpin.org/. This allows you to deploy your business logic layer without disconnecting/reconnecting clients.

For realtime, I used Pushpin with Server Sent Events. (It supports WebSocket as well).

Instead of letting clients directly interface with your services over websockets, consider using Pushpin [1], which allows you to completely isolate realtime communication from your services.

As a bonus, it also provides you the ability to cycle (redeploy/restart) your services without your clients having to reconnect (that's where the name comes from). And as you can imagine - because communication with your services is entirely stateless it scales like crazy.

[1] https://pushpin.org/

Vapor[0] based on Swift. Advantage of this is that you don't have to evaluate multiple frameworks for Swift and suffer paralysis by analysis. All the Swift community is behind one framework.

The next is Actix[1] based on Rust. There are many frameworks in Rust and most of them have not reached 1.0 And which framework will survive becomes a question.

Other not so well-known is Wt[2] based on C++. This actually is created for programmers who are not web developers. The development experience is similar to desktop app development like Qt.

If that is not acceptable then Django[3], based on Python, is the one that will be good for you.

For the front-end I would recommend Flutter[4]. As much as I dislike getting tied to a single company for whom the framework is not their bread-and-butter, I don't see any other viable options to Flutter that will cover all web, mobile and desktop out of the box.

For databases, I would recommend BedrockDB[5], if you are not averse to SQLite. Or FoundationDB[6], if you want NoSQL. But if you are not concerned about horizontal scalability or okay with self-managing database availability, then PostgreSQL[7] is a very good option.

For push notifications, PushPin[8] is a good option.

[0] https://vapor.codes

[1] https://actix.rs

[2] https://webtoolkit.eu

[3] https://www.djangoproject.com

[4] https://flutter.dev

[5] https://bedrockdb.com

[6] https://www.foundationdb.org

[7] https://postgresql.org

[8] https://pushpin.org

There is also the option of running a proxy which handles the stateful nature of websockets (i.e. https://pushpin.org/), and then handle the rest in a stateless way with lambdas or similar.

This may not be what you are looking for, but why not use a combination of Postgres listen/notify and PushPin[0] to support push notifications?

[0] https://pushpin.org

Could use pushpin[1] and have several fallbacks, like SSE -> Websocket -> polling.

[1]https://pushpin.org/