Session-lived Application Backends | Hacker News Reader

Session-lived Application Backends

driftingin.space

42 pointspaulgb15 comments

Blazor [1] has a concept of "circuits" [2] where each connected browser has a corresponding instance on the server.

It's part of the reason why I personally don't like it being recommended for simple CRUD apps (brings back memories of webforms) as it doesn't seem very "webby", but this makes a great point that for some kinds of apps it's the best or at least a very advantageous model.

It's great to grow terminology and maturate platforms so that we can recognize and then adopt appropriately.

[1] https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... [2] https://docs.microsoft.com/en-us/aspnet/core/blazor/state-ma...

Is there an easy way to achieve on-demand docker containers this way? As I understand this, for a private setup, I'd have to code the initialisation and run Kubernetes as well? Might be a noob question, but i have a few containers which are really resource intensive and spin them up manually when needed.

Possibly I'm not the right audience, but a guide on how to get your current docker setup incorporated into your service might be useful for people wanting to give it a spin.

Just to make sure I'm understanding, you want to run docker containers on demand (and programmatically), but you want to run them on a single machine, so Kubernetes feels like overkill, right?

Your best bet might just be invoking the docker command-line tool directly from your code.

Very cool, excited to see this launch! Similar ethos to ink&switch[0] local-first apps, but taken to their logical conclusion

[0] https://www.inkandswitch.com/

Thanks! We're big fans of Ink & Switch.

Congrats on the funding and soft launch.

I'm a believer in serverless, and think it could be better still! The continued progress of companies like darklang, replit, singlestore, planetscale (to name a few) have been super exciting.

And so: How'd you compare your approach with James Cowling's convex.dev which is a slightly different take on marrying data with serverless [0]? Thanks.

[0] https://docs.convex.dev/guide/convex-fundamentals/intro

Thanks! Convex looks neat, and you’re right, there is a lot going on at the data and data/frontend layer. Our approach is to provide a generic compute layer with the session-lived backend model, so you can do more than just store data with it.

So, I presume, instead of a shared multi-tenant architecture convex), Spawner prefers per-user business-logic container + a per-user database container (+ any other module)? If so, once a user-session is adjudged to have been over, does Spawner snapshot them all to restore it whenever a session is to be resumed?

You could run a database for each user inside Spawner, and there are use cases for that, like being able to run queries against arbitrary parquet files or materializing a sample of a larger dataset for fast queries. But in general if you just want to store program state, you would probably want to use Spawner for the compute and a multi-tenant database for persistence. We expect that Spawner will usually be part of a larger system that involves some multi-tenant components.

Spawner doesn’t manage any persistence automatically, it’s up to the application. For some use cases, sessions are meant to be ephemeral (like a whiteboard session, or read-only data exploration), so there’s no state to persist at the end.

For apps where there is state to persist, one option is desktop-style auto-save. By that I mean that the ground truth document state is in-memory, but every change to it triggers an asynchronous write to a persistent store. This is preferable to one-shot persistence at the end of the session for the same reason as it is on desktop apps: if there’s a power outage or hardware failure, you only lose a few seconds of work.

It seems that CloudFlare’s Durable Objects are another take on solving this problem.

Any thoughts on comparisons/contrasts between this and Durable Objects?

I think Durable Objects is a great product and Cloudflare have been ahead of the curve on this trend. The main difference is that the unit of code is a container image rather than a JS/WASM bundle, so you can run just about anything in there (we’ve run instances of Chrome and an OLAP database). We’re mainly focused on use cases where developers want a more powerful compute environment than they have in the browser, so we wanted to be as unrestrictive as possible about what runs in it.

The other difference is that it’s open source. We’re also working on a managed version for people who don’t want to manage a cluster, but we don’t want to tie developers to a managed platform without an open source on/off ramp.

This feels like what unikernels were aimed at. I wonder how this compares with that technology?

Somehow, that's the default model when working with Phoenix/Elixir.

As long as you deploy it to infrastructure that supports direct communication between servers. Few cloud providers offer that in managed application platforms (e.g. Google's App Engine doesn't offer it).

This looks like the sort of thing we would have needed to build ourselves to take a remote control pixel streaming project from a while back into production.

Reply on news.ycombinator.com