Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jamsocket: Back Ends for Realtime Apps

jamsocket.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Jamsocket: Back Ends for Realtime Apps

#31

Post by paulgb »

pcthrowaway wrote: post #29
paulgb wrote: post #7

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.

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.

Re: Jamsocket: Back Ends for Realtime Apps

#32

Post by paulgb »

hdidhdish wrote: post #30
paulgb wrote: post #20

Earlier quoted context omitted.

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.

Re: Jamsocket: Back Ends for Realtime Apps

#33

Post by pcthrowaway »

paulgb wrote: post #31
pcthrowaway wrote: post #29

Earlier quoted context omitted.

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…

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?

Re: Jamsocket: Back Ends for Realtime Apps

#34

Post by juberti »

paulgb wrote: post #28
juberti wrote: post #27

Earlier quoted context omitted.

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.

Re: Jamsocket: Back Ends for Realtime Apps

#35

Post by paulgb »

pcthrowaway wrote: post #33
paulgb wrote: post #31

Earlier quoted context omitted.

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…

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.

Re: Jamsocket: Back Ends for Realtime Apps

#36

Post by dgreensp »

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?

Re: Jamsocket: Back Ends for Realtime Apps

#37

Post by Alifatisk »

seabrookmx wrote: post #4
paulgb wrote: post #3

Earlier quoted context omitted.

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

Re: Jamsocket: Back Ends for Realtime Apps

#39

Post by paulgb »

jelling wrote: post #38

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.

Re: Jamsocket: Back Ends for Realtime Apps

#40

Post by paulgb »

dgreensp wrote: post #36

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 cli…

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.

Post reply on HN