Hacker News new | ask | show | jobs
by jkarneges 1388 days ago
> 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.

2 comments

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?

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

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.
How much slower though, I think we’re talking everyone getting the message in a Phoenix channel in < 100ms?
I can't believe this article is 7 years old.