<kentonv>
ill_logic, Workers are useful for implementing basically any type of web app. The reasons you might want to use Workers rather than one of the many other solutions out there are (1) it's incredibly easy to deploy an application, because scaling and redundancy are handled automatically, (2) you only pay for what you use, so if you have low traffic it'll be much cheaper than paying for a virtual machine instance, (3) your code run
<kentonv>
s at the closest Cloudflare location to the end user, of which we have hundreds around the world, so latency is very low.
<kentonv>
that said, this is the Sandstorm channel and admittedly Workers are not a self-hosting technology... unless you use workerd, the open source Workers runtime, but then you lose the other advantages I just listed.
<ocdtrekkie>
I can see how it'd fit a Sandstorm stack though... I think. Do you know if there are any samples that would be appropriate for me to try it?
<kentonv>
workerd would be an excellent stack for Sandstorm apps, because it starts up really fast. Also, we could safely distribute the latest version of `workerd` with Sandstorm itself so that apps don't have to bundle their own copy, since workerd has a very strong commitment to backwards compatibility
<kentonv>
in fact it'd be pretty easy to build workerd *into* Sandstorm since both codebases are based on Cap'n Proto / KJ. :)
<kentonv>
for apps that you reasonably trust aren't malicious, you could then perhaps skip the sandbox for even better performance...
<kentonv>
(workerd itself still provides a V8-based sandbox that should prevent the app from accessing anything it's not allowed to -- but V8 sometimes has bugs)
<ill_logic>
Workers don't have database/storage access, right? That's why you don't care where they run. So how could you have a Sandstorm app?
<kentonv>
workerd actually does allow you to configure disk access, though currently it only lets you do basic GET/PUT of whole files
<kentonv>
but the real cool thing is if we could base it on Durable Objects
<kentonv>
Durable Objects are, incidentally, inspired by Sandstorm's grain model!
<kentonv>
but at present workerd doesn't fully support Durable Objects yet... or rather, it supports them, but with in-memory storage only, so you lose all your data when it restarts. It's useful for testing but not real use.
<ocdtrekkie>
But we also would need apps that run in workerd that make sense for selfhosting.
<kentonv>
we'll fix that at some point so it actually stores to disk, maybe backed by sqlite
<kentonv>
sqlite is, of course, great for Sandstorm
<ill_logic>
Where are the files stored? Presumably not in the same ephemeral place as the function?
<ocdtrekkie>
I still see "here's the Dockerfile" at the default approach for selfhosting today, and it makes me sad.
<kentonv>
ill_logic, workerd runs on your own machine, you can point it at whatever directory on disk you want
<ill_logic>
well, sure, but what about Cloudflare workers?
<ocdtrekkie>
Yeah I saw the config for that
<ocdtrekkie>
For workerd should be easy to point to /var for a test stack of it.
<kentonv>
Cloudflare Workers does not support direct file storage, but it does have Durable Objects, Workers KV, and R2
<kentonv>
ocdtrekkie, yes, new apps would need to be built. But maybe that's an easier sell if it's like "you can write one codebase and it works great either as SaaS on Cloudflare or as a Sandstorm app"...
<ocdtrekkie>
If you come across anything that would make sense to try packaging, let me know, I kinda want to try it.
<ocdtrekkie>
As you may have noticed I've been on a bit of a packaging binge only derailed by the entire print server setup at working taking a dive and murdering all my brain cells.
<ocdtrekkie>
at work*
<kentonv>
there's the edge chat demo
<kentonv>
could be a very simple chat room app
<kentonv>
I think we'd want to modify it to have just one room...
<kentonv>
it'll lose the logs whenever it shuts down since Durable Objects aren't actually durable yet but that's not that big a deal
<ocdtrekkie>
I could probably test against that, yeah, though I probably wouldn't want to publish an app without persistence.
<abliss[m]>
I don't understand the bit in the blog post about 'nanoservices' that live in-process. how is that different from a library? how is 'homogeneous deployment', where every nanoservice is on every host, different from monolithic development?
<ocdtrekkie>
Well all your nanoservices can all live on just one host, or they can all live on tens of thousands of hosts.
<ocdtrekkie>
Which is to say for a single host deployment, it isn't different than a monolith, but you don't have to do more work when it needs to scale past that.
<kentonv>
abliss[m], each nanoservice is loaded in a separate isolate, meaning from the JavaScript's point of view, it seems to be running its own process. So e.g. you don't have to worry about dependency version conflicts with other nanoservices, don't have to worry about them messing up the global scope, etc.
<kentonv>
and the communications between the isolates must strictly be through the capabilities defined in the config.
TimMc has joined #sandstorm
TimMc has quit [Quit: leaving]
TimMc has joined #sandstorm
mnutt has quit [Ping timeout: 244 seconds]
mnutt has joined #sandstorm
mnutt_ has joined #sandstorm
mnutt has quit [Ping timeout: 268 seconds]
cwebber has quit [Remote host closed the connection]