I would interested in hearing examples of software that is a breeze to self host and terrible to self host. And most importantly, why? What can software devs do to make something a breeze? And what should they avoid? Thanks.
> I'm sure there are commercial (not even paid necessarily) apps that do all this, but this one is used only by us and it's built to perfectly interact with our lives
There is another factor you may not be aware of: shopping apps are juicy targets for acquisition by marketing/data mining company. I mean, there is no clearer indication of what you want to buy than what you put in your shopping list, so it's perfect source of data to mine.
Out of milk is such an example: it was a good app with 5 million users, then it got sold. Users became the subjects of data mining, or their account got deleted (if in Europe). Fun!
I've been curious if the play stores etc of the world would mind supporting some kind of banner or other notification for when apps change hands between owners. Something to tip them off to the fact that the app is now under new management, much like how restaurants hang banners when new management takes over a spot. Now that I think about it I wonder why restaurants even feel it warranted to notify the public, must have some positive image optimism behind it I guess or is it something regulated perhaps?
I'm hoping PWAs continue to get better so that app stores aren't the only way of having an app-like experience. App stores just aren't designed for this kind of use case, and hurdles like "We're dropping your app bc you only have 4 users"* take the joy out of home-coding.
* fictional quote but it wouldn't shock me if it became real
> The isolation aspect was interesting in the days before Firecracker...
I don't think Firecracker's existence makes WASM's isolation uninteresting. First, I think you are looking at way more resources running a full VM (even a "micro" VM) compared to a WASM runtime. I think startup times are not comparable either, so if that matters you'll find WASM to be the way to go.
Second, WASM's capability-based security model is wonderful for giving the untrusted code the things it needs to work with. With a VM, you have to stitch together with shared directories, virtual eth bridges or, linux capabilities, maybe some cgroups, and who knows what else. (Granted you may need to do some of that with WASM too, but less so).
Are you willing to talk a bit about how Deno Deploy works internally? I think you have an internal build of Deno that can run multiple isolates (unlike the CLI, which basically runs one). How do you limit the the blast radius in case of a vuln in Deno?
Kenton Varda did a pretty great writeup on CF worker security [0]. Would love to see Deno Deploy do something similar.
We probably will eventually. A talk like this takes a _lot_ of time to prepare though, so it's not on the top of our priority list. But it will happen eventually.
The TLDR is that Deno Deploy works pretty similarly to CFW in that it can run many isolates very tightly packed on a single machine. The isolation strategy differs slightly between CFW and Deploy, but both systems make extensive use of "defense in depth" strategies where you minimize the blast radius by stacking two or more defenses against the same issue on-top of each other. That makes it _much_ more difficult to escape any isolation - instead of breaking out of one sandbox, you might have to break out of two or three layers of isolation.
These levels of isolation could happen at different layers. For example network restrictions could be initially restricted by an in-process permission check, then additionally a network namespace, and finally a routing policy on the network that the machine is connected to. Imagine this, but not just for network, but also for compute, storage, etc.
The "any language" advantage of WASM is theoretical. Each language is at a different level of support of WASM, libraries aren't all caught up and at the same point for all languages, etc...
I love the promise of WASM, but every time I look at it I get lost in a sea of acronyms, and my optimistic ideas of using language X with library Y on runtime Z are dashed because there is some missing piece somewhere.
If anything, the "any language" thing creates a giant matrix of potential pitfalls for the programmer.
In comparison, the combination of JS/TS, the browser API and a solid std lib looks pretty good for some problems.
