I think it has to do with the building, perhaps there is a Faraday cage caused by the copper net layer in the walls. From a similar experience, the doorstep of my apartment is really close to my other 2 neighbours (ground floor), and they all have WiFi routers above the entrance, inside — it was very hard to connect and use Wifi in the house on 2.4GHz due to the bandwidth, even if I changed the channels manually, so I was forced to buy a 5GHz router to circumvent the shortage. Also, my LTE doesn't work at all at my doorstep, so it's pretty apparent.
Not really - more as an open-source alternative that has many benefits for running it yourself instead of paying or being limited by existing, highly-reliable SaaS products.
> My guess: Their motivation is probably that they used a SaaS product, which was totally overpriced for what value it provided and they want to show that they can do it better for cheaper.
Yes, and what I replied earlier in this thread: I'm not the only one having this issue with overpriced Pusher, I just dont want to be limited by Pusher on how many messages I wanna distribute to my end users.
> Anyway, what exactly is the use of this compared to just using uWS straight away? It’s build on uWS, so this is basically just a pusher implementation and some notification features with cool branding?
uWS is cool to be used in any WebSocket client. However, Pusher has a strict protocol, so I wanted a product that works with any Pusher SDK - so I won't have to rely on custom clients or something of that ilk.
The creator of Soketi here. Even if I have 50-100 concurrent connections on most of the projects, I don't wanna be throttled by how many messages I can distribute to my end users - I might have < 100 users, but maybe I have to distribute fresh updates each 5 seconds, what do I do?
The library is built on top of uWebsockets which is fairly well-known as being highly optimised and performant, especially if you skip the Node.js wrapper and use the underlying C/C++ lib directly. Does anyone know what tradeoffs or different performance characteristics one would expect to see from e.g. Elixir/Erlang vs uWebsockets?
Elixir/Erlang are surely slower but the BEAM is a fantastic runtime and compensates with fault-tolerance and predictable performance. I know I prefer my server to be as responsive at 1 million connections as at 1 hundred.
I chuckled. This works so good.
reply