Session-lived Application Backends

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.

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).

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