Hey HN! I'm a co-founder of Jamsocket, happy to answer any questions. We've previously been on HN for Plane, which is the open-source engine behind Jamsocket. https://news.ycombinator.com/item?id=33178797
Sorry for the website performance issues, I've disabled the animation which should help.
If you write a socket.io service that uses broadcast, and then scale up to more than one server, your users will be split between those servers and won’t be broadcast to the other. Jamsocket allows you to generate a unique hostname for each room that ensures that every user is talking to the same server. That server can still use socket.io in addition to Jamsocket; they work at different layers of the stack.
Pusher solves the problem of scaling in a different way, which is by giving you an HTTP endpoint to send events to. It’s better for large broadcast groups (e.g. sending people sports scores) but doesn’t run any compute for you.
Thanks for the feedback, I agree and it's something that we're working improving.
Currently most people are paying the $25 flat rate; for this we bump the per-backend memory limit to 2GB and give them a soft limit of 20 concurrent backends, up to 24h duration for those backends, and enable eager image pushing for faster start times. The pricing will become more sophisticated over time as we deal with a wider variety of usage patterns.
The bring-your-own-compute model is a bit clearer because it's simpler for us to model from the side of our own costs. That has a $25/month base fee plus $10 per “server month” of compute connected to the control plane. For bring-your-own-compute there is no cost or limit to the backends that run, since they run on our customer's own hardware.
I didn't read very deeply, but I was surprised to see something like a Jupyter notebook mentioned as a use-case. The marketing pitch seems to suggest that these hosted sessions are relatively stateless, so I'd hesitate to trust an interactive Jupyter session with one.
Accidentally closing a browser tab seems like it would end the session and wipe out my whole Jupyter session, variables and all.
The use case in that example is for ephemeral notebooks used for demos. It's also good for running notebooks for temporary classroom use.
When backends are spawned, there is a period of time that they remain alive without a connection. By default, it's 5 minutes. So if you accidentally close a tab, but open it back within 5 minutes, the kernel is still there.
It’s been a while since I’ve done server push in production… Back in the day, you couldn’t count on the browser or the ISP supporting real WebSockets correctly, and I expect this is still the case some percentage of the time. WebSockets were best seen as one possible transport, and if they were detected to be not functioning, the client library responsible for the “socket” would fall back to long-polling. Or, the client library would start out with something simple and known to work and “upgrade” the connection if possible.
WebSockets also don’t ensure messages are delivered (once) across network hiccups. And browsers have different limits on how many there can be open at once across tabs for a domain (IIRC). In the end, I think it makes sense for them to be the main transport for a real-time app, but they are just one part of creating a conceptually simple model for real-time communication between client and server.
Does Jamsocket have or use a client socket library?
I used to work at a company that fully blocked WebSocket, I know the pain!
We don't provide a client socket library, we just expose an HTTPS endpoint that also supports WebSockets. So you can use something like socket.io to provide fallback options, reconnects, etc. Some customers don't even use WebSockets at all and just hit HTTP endpoints.
Liveblocks is a full data layer solution -- you use their JavaScript library in your client, and they run code on their servers for synchronizing standard data types like lists and key/value maps.
By contrast, Jamsocket gives you a place to deploy your own WebSocket server, which means you can write your own data layer. This give you the control to do more advanced things like enforce invariants in the data structure.
I think of it as akin to using Firebase vs. using Postgres -- there is a place for both, and Liveblocks is a solid product, it just depends how much control you want vs. how much you want to lean on a managed service.
This looks really interesting, and something that could solve a semi-immediate pain point but I can’t find any data on the production plan other than the price. Is that information available anywhere?
Thanks, we are working on adding more details about the production plan and I agree that it's currently sparse. We do have some details about the limitations of the free tier[1].
With the production plan we increase the memory limit of the backends to 2GB, up the number of concurrent backends to 20 (it's a soft limit), up the limit on backend runtime to 24h, and have images eagerly pushed rather than lazily pulled for faster start times. If you're open to chatting about your use case, feel free to reach out to the email on my HN profile.
Readit News
Sorry for the website performance issues, I've disabled the animation which should help.
Why would I choose this instead? That isn't clear to me yet.
Pusher solves the problem of scaling in a different way, which is by giving you an HTTP endpoint to send events to. It’s better for large broadcast groups (e.g. sending people sports scores) but doesn’t run any compute for you.
Currently most people are paying the $25 flat rate; for this we bump the per-backend memory limit to 2GB and give them a soft limit of 20 concurrent backends, up to 24h duration for those backends, and enable eager image pushing for faster start times. The pricing will become more sophisticated over time as we deal with a wider variety of usage patterns.
The bring-your-own-compute model is a bit clearer because it's simpler for us to model from the side of our own costs. That has a $25/month base fee plus $10 per “server month” of compute connected to the control plane. For bring-your-own-compute there is no cost or limit to the backends that run, since they run on our customer's own hardware.
Accidentally closing a browser tab seems like it would end the session and wipe out my whole Jupyter session, variables and all.
When backends are spawned, there is a period of time that they remain alive without a connection. By default, it's 5 minutes. So if you accidentally close a tab, but open it back within 5 minutes, the kernel is still there.
I've seen a lot of bad engineering go into solving that problem, this seems like a better way.
WebSockets also don’t ensure messages are delivered (once) across network hiccups. And browsers have different limits on how many there can be open at once across tabs for a domain (IIRC). In the end, I think it makes sense for them to be the main transport for a real-time app, but they are just one part of creating a conceptually simple model for real-time communication between client and server.
Does Jamsocket have or use a client socket library?
We don't provide a client socket library, we just expose an HTTPS endpoint that also supports WebSockets. So you can use something like socket.io to provide fallback options, reconnects, etc. Some customers don't even use WebSockets at all and just hit HTTP endpoints.
Deleted Comment
Sometimes I explain it to Erlang/Elixir world people as “GenServer-as-a-service”.
By contrast, Jamsocket gives you a place to deploy your own WebSocket server, which means you can write your own data layer. This give you the control to do more advanced things like enforce invariants in the data structure.
I think of it as akin to using Firebase vs. using Postgres -- there is a place for both, and Liveblocks is a solid product, it just depends how much control you want vs. how much you want to lean on a managed service.
With the production plan we increase the memory limit of the backends to 2GB, up the number of concurrent backends to 20 (it's a soft limit), up the limit on backend runtime to 24h, and have images eagerly pushed rather than lazily pulled for faster start times. If you're open to chatting about your use case, feel free to reach out to the email on my HN profile.
[1] https://docs.jamsocket.com/free-tier-limits/