3 ms·

> Stop paying for €xpen$ive realtime First time I've seen what appears to be a purely free project going on the offense against SaaS providers, complete with a

> Stop paying for €xpen$ive realtime First time I've seen what appears to be a purely free project going on the offense against SaaS providers, complete with a mock pricing table. I wonder what the motivation is. Bad experience with a SaaS? Brilliant website in any case. And I say this as someone who works on a realtime/push SaaS.

mccorrinall 4y ago
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. 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?
- rennokki 4y ago
  > 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.
rennokki 4y ago
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?
- nesarkvechnep 4y ago
  You use a stack which supports it. Elixir and Erlang support millions of concurrent websocket connections on a single, albeit beefy, server. https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs...
  - jamil7 4y ago
    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?
    - nesarkvechnep 4y ago
      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.
      - andy_ppp 4y ago
        How much slower though, I think we’re talking everyone getting the message in a Phoenix channel in < 100ms?
  - conradfr 4y ago
    I can't believe this article is 7 years old.

mccorrinall 4y ago

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. 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?

rennokki 4y ago
> 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.

rennokki 4y ago

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?

nesarkvechnep 4y ago
You use a stack which supports it. Elixir and Erlang support millions of concurrent websocket connections on a single, albeit beefy, server. https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs...
- jamil7 4y ago
  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?
  - nesarkvechnep 4y ago
    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.
    - andy_ppp 4y ago
      How much slower though, I think we’re talking everyone getting the message in a Phoenix channel in < 100ms?
- conradfr 4y ago
  I can't believe this article is 7 years old.