Earlier quoted context omitted.
Isn't that Sandstorm's usecase... more or less?
Interesting, this is the first time I'm reading about it [1]. Well, if anything it looks like a web app would have to be rebuilt from the ground up to fit that model. I haven't yet read much about it, but here's a few questions that pop up immediately: 1) If you have a container per data object, doesn't that mean you also have to start a process every time a user opens a document? So forget about doing any computatio…
Not at all! The app market is full of apps that were not originally written for Sandstorm:
Examples: Wekan, Etherpad, Rocket.Chat, EtherCalc, draw.io, Gogs, Dillinger, NodeBB, EtherDraw, ...
It turns out that converting a web app to Sandstorm is mostly deleting code. You delete your user management, your collection management, your access control, etc. What you have left is the essence of your app -- the UX for manipulating your core data model, of which you now only need to worry about one instance.
> doesn't that mean you also have to start a process every time a user opens a document?
Most apps we've encountered only take a couple seconds to start. But we're working on a trick where we snapshot the process after startup and start each grain from the snapshot, thus essentially optimizing away any startup-time slowness.
> How do you handle indexes, views and collections over a large set of data objects?
Sandstorm is (currently) designed for productivity apps, not for "big data" processing. The data within a single grain is usually small. That said, you can run whatever database you want inside the grain.
(I'm the tech lead of Sandstorm.)