Jamsocket: Back Ends for Realtime Apps
jamsocket.comHey 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.
The session thing looks really cool, but when do I need it? I can develop a simple real-time app using socket.io or a service like Pusher.
Why would I choose this instead? That isn't clear to me yet.
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.
Can you clarify pricing? "From $25" is terribly opaque. What are the billing criteria?
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.
Thanks for clarifying.
So how does the price scale with the limit on concurrent backends? That's the really important factor in determining whether this is feasible (though I assume given a baseline of 20 it probably wouldn't be, for me, right now)
Also, how does BYOC differ from using Plane or Socket.io?
At scale it becomes a bit less one-size-fits-all, because compute requirements can vary so much. Eventually we will probably have different backend types the same way that Amazon has different instance types, but for now we tend to talk things through with the customer one-on-one (feel free to reach out at the email in my profile if you want to talk about a use case).
BYOC is essentially a hosted instance of Plane with our hosted container registry, web UI, and command-line tool for deployment.
Jamsocket could be used to spin up a socket.io WebSocket server.
Yep, your homepage breaks on my imac/firefox due to webgl.
Sorry about that, thanks for reporting. Can you elaborate on how it breaks -- does it freeze up or not display at all?
most sane people disable webgl and enable per domain
Fair enough, I have fixed it so that it doesn't break without webgl.
Do you support WebTransport in addition to WebSockets?
Not yet but if you have a use case in mind, I'd love to hear more about it. I'm pretty excited about QUIC/WebTransport/HTTP3.
The basic idea would be a simple voice conferencing bridge that you connect to via WebTransport. There are a number of more interesting things that we would be interested in if we could get this sort of basic scenario working.
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.
Thanks, I can definitely understand the classroom use-case.
I've seen a lot of bad engineering go into solving that problem, this seems like a better way.
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.
Another reinvention of Erlang processes?
Erlang got a lot right ;)
Sometimes I explain it to Erlang/Elixir world people as “GenServer-as-a-service”.
Can you contrast your product with Liveblocks? I am considering it for a real-time application.
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.
I'm unable to view https://github.com/drifting-in-space/jamsocket-nextjs-tutori...
Thanks for letting us know — it’s fixed now!
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.
Believe it or not, the website is barely scrollable with my MB 2015.
Oof, sorry (I'm the one who wrote the webgl code). Are you on Chrome, Firefox, or something else?
We tested on everything we could get our hands on but didn't have any older macbooks that worked. I'll see what I can do.
Edit: I disabled the animation, I hope that helps.
Ditto on my Framework laptop with an i5-1240p (running Fedora).
Might be because I'm running Firefox?
Running FF aswell
It made my Dell XPS13 / Linux / Firefox sweat (i.e. turn on the fans).
same scroll issues - firefox on 2019 macbook pro
for someone new to real time apps, can you help me understand how JamSocket is different from some service like Pusher?
Pusher provides a way to simulate a stateful WebSocket connection using a stateless server architecture. Jamsocket provides a stateful server architecture where WebSockets have first-class support.
What is the latency to start a session?
You can see an example by clicking "new game" on here: https://word.red/
We are working on getting it subsecond for most images, but we're not there yet.
Interesting. Is there a latency difference between first instance of an image and nth?
On the free tier there can be (because images are loaded lazily), but on the paid tier we load the images eagerly so that there is not.
To build a image and push, spwan a pod? Why not just use FaaS service skip the build step?
You don't need to push every time you spawn, only when the code is changed. Typically, you would use a CI/CD action to push the image (this repo has a simple example: https://github.com/drifting-in-space/jamsocket-jupyter-noteb...)
A typical FaaS is stateless between invocations. We have an explicit "spawn" step because each spawn produces a new server process with its own state and own DNS hostname.
Yeah, Doesn't work well for my iMAC.