mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 268 seconds]
mnutt has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 272 seconds]
<kentonv>
so on the sandstorm.io / capnproto.org / alpha server (they're all backed by one machine...), I just replaced nginx with the soon-to-be-open-source Cloudflare Workers Runtime
_whitelogger has joined #sandstorm
<ocdtrekkie>
neat!
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 268 seconds]
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 240 seconds]
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 252 seconds]
<kentonv>
everything seems to be going well, so it's now permanent
mnutt has joined #sandstorm
mnutt has quit [Ping timeout: 268 seconds]
mnutt has joined #sandstorm
<ocdtrekkie>
Does that open up anything for the future or any expected benefit? Future with less Google?
mnutt has quit [Ping timeout: 245 seconds]
<kentonv>
ocdtrekkie, not really. It just means I replaced a bunch of nginx config with JavaScript. Maybe that logic could run in Cloudflare now, but alpha.sandstorm.io itself is going to keep needing a VM...
<kentonv>
open sourcing the runtime, though, could be interesting for Sandstorm. It'd be pretty easy to integrate the workers runtime into Sandstorm, since they are both built on Cap'n Proto / KJ. If we had a new workers-based app format, we could make grain startup time much, much faster for those apps...
<kentonv>
of course... that requires apps to be written in a particular way. But given the recent convergence around JavaScript Workers as a server stack, maybe that's an easier sell then it would have been 5 years ago.
<ocdtrekkie>
I mean, the best Sandstorm apps are built for Sandstorm anyways.
<kentonv>
cold starts are really quite bad in Sandstorm today. :/
<ocdtrekkie>
Gmail has trained users to tolerate some crazy load times.
<ocdtrekkie>
I am pretty sure I can cold boot Windows 10 faster than Gmail loads now.
mnutt has joined #sandstorm
<isd>
I think step 1 would be actually package/write some workers apps with vagrant-spk; the baseline grain startup time is Not The Bottleneck, and I expect performance would be fine without adding code to the TCB.
<kentonv>
what do you mean by "not the bottleneck"?
<isd>
I mean the apps where startup time is noticable, it's not spinning up a container and spawning a process that's the problem -- we have some apps that do just fine. Grains that have bad startup times it's because the framework is doing a bunch of other stuff, or they're doing a ton of disk io on startup, or...
mnutt has quit [Ping timeout: 245 seconds]
<isd>
I would love to be in a place where integrating the workers runtime into sandstorm was the low hanging fruit. I don't think that's where we are.
<kentonv>
hmm... though arguably code that is designed to run on Workers is also naturally going to optimize for faster startup, since workers start on-demand
<isd>
Agreed - but, as I said, step 1 would be a vagrant-spk stack. We may not even have to directly integrate the runtime to reap the benefits.