5 ms·

I'm currently experimenting with React and WebSockets and they seem to be a perfect fit. No need to write wrappers for Fetch, network errors and reconnects can

I'm currently experimenting with React and WebSockets and they seem to be a perfect fit. No need to write wrappers for Fetch, network errors and reconnects can be handled on high-level, handlers for each message type can be mounted and unmounted on useEffect hooks, all back-end jobs can notify the user in realtime, all session-based client-side data can be updated in realtime (in single or multiple open tabs). I'm also using uWebSockets.js[0] which is great in terms of API design, stability, and performance. Their benchmarks[1] are just convincing. Highly recommend people using ExpressJS / Koa / whatever to try it. [0] https://github.com/uNetworking/uWebSockets.js/ https://github.com/uNetworking/uWebSockets.js/ [1] https://github.com/uNetworking/uWebSockets/tree/master/benchmarks https://github.com/uNetworking/uWebSockets/tree/master/bench...

azangru 6y ago
> and they seem to be a perfect fit Needs a fairly capable server though, I suppose. One that can handle lots and lots of open websocket connections.
- IggleSniggle 6y ago
  Guess it really depends on how many concurrent users you expect to have... Sounds like 30 GiB RAM for 1 million concurrent users is not unreasonable: https://stackoverflow.com/a/17453704 https://stackoverflow.com/a/17453704
- joshxyz 6y ago
  Yes that's some genuine concern. Though on B2B and B2C SaaS where you got paying users, I think each of them deserve a websocket, and it could* alleviate some headaches for developers. * Anecdotal of course, at least for us.
- e_y_ 6y ago
  Also your load balancer stack needs to support it, which is becoming less of a problem these days but there's still some stragglers. You could also end up with an imbalance where some servers have a lot of connections and others have few.
kekington 6y ago
We are using Phoenix Channels[0] for a websocket-based app and it's very easy to setup/work with. It should also scale easily. [0] https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html
- joshxyz 6y ago
  When I was researching stuff I've read a lot of good things about Phoenix, I honestly think socket.io and ws NodeJS libraries are inferior compared to that. It's just almost pure luck that the guy who wrote uWebSockets (written in C & C++) also wrote NodeJS bindings, otherwise we'll be stuck with the ones with sub-par api, docs, and performance.

azangru 6y ago

> and they seem to be a perfect fit Needs a fairly capable server though, I suppose. One that can handle lots and lots of open websocket connections.

IggleSniggle 6y ago
Guess it really depends on how many concurrent users you expect to have... Sounds like 30 GiB RAM for 1 million concurrent users is not unreasonable: https://stackoverflow.com/a/17453704 https://stackoverflow.com/a/17453704
joshxyz 6y ago
Yes that's some genuine concern. Though on B2B and B2C SaaS where you got paying users, I think each of them deserve a websocket, and it could* alleviate some headaches for developers. * Anecdotal of course, at least for us.
e_y_ 6y ago
Also your load balancer stack needs to support it, which is becoming less of a problem these days but there's still some stragglers. You could also end up with an imbalance where some servers have a lot of connections and others have few.

kekington 6y ago

We are using Phoenix Channels[0] for a websocket-based app and it's very easy to setup/work with. It should also scale easily. [0] https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html

joshxyz 6y ago
When I was researching stuff I've read a lot of good things about Phoenix, I honestly think socket.io and ws NodeJS libraries are inferior compared to that. It's just almost pure luck that the guy who wrote uWebSockets (written in C & C++) also wrote NodeJS bindings, otherwise we'll be stuck with the ones with sub-par api, docs, and performance.