Should app devs include the sandbox lib? Or should it be injected by DS?

[teleclimber]

Currently the sandbox consists of Deno running /denosandboxcode/ds-sandbox-runner.ts.

The runner starts an http server, and starts a twine client and connects. Then when a new request comes in it dynamically loads the necessary app module and passes the request along.

The key thing here is that denosandboxcode is embedded in the ds-host and ds-dev executables, and is therefore entirely tied to those executables at those versions.

Lately I've been wondering if it would be better to just let the app dev import a published dropserver-sandbox module into their app. So sandbox code would live with the app. Some reasons this might be good:

• Conflicts between sandbox code and app code can be resolved at app testing time.
• Easier to start: import the module, and code against its exported functions.

Some reasons it might be bad:

• Can't make changes to the ds-host <-> sandbox communication layer. Think in particular about Twine, which is the core of that comm layer and is likely to evolve a lot going forward.
• Alternative libs may result in increase in support requests due to imperfect compatibility.

[teleclimber]

Something that needs to be addressed is the entire set of versioned dependencies in a Dropserver + app:

• app code has its own version (irrelevant?)
• app code likely depends on deno std lib, which is unstable. In particular handling requests involves importing the Response class. But what if sandbox code is using a different std lib version?
• DS sandbox code
• DS sandbox imports its own set of Deno std lib modules.
• Deno
• ds-host or ds-dev

If Deno std lib eventually stabilizes, then we can reduce to:

• app code
• sandbox code
• deno
• ds-host/ds-dev

One reason for keeping deno sandbox code embedded in ds-host/ds-dev is that you can evolve ds-host/ds-dev, and use the sadnbox code to offer back-compat, as opposed to having to support all kinds of variations within ds-host/ds-dev.

Note we can also probably have multiple versions of Deno installed, and use an older one if that is what the app expects.

[teleclimber]

There is potentially a third option:

• Don't bundle app code (maybe compile TS, but don't bundle -- it's more efficient anyways)
• Let the app import the sandbox code, maybe using a special url
• DS serves the sandbox code requested from its embedded filesystem.

With this, we can maybe effectively have a "compatibility layer" because the sandbox code import could include a version (that indicates the JS API the app is coded against), but DS could serve the latest version of the lib that works with that API version and with whatever DS expects in that particular build.

Unfortunately this means that the app will have to have its deps loaded and compiled by DS. I can imagine doing that at app install time with the caching option of Deno? Except that since different parts of the app are loaded dynamically, there is a chance that we'll miss deps, and if we run the appspace with "cached only" then it will not work.

[teleclimber]

This discussion cascades into a number of open questions:

• Should app code be "bundled"?
• If not bundled, how to handle remote imports? Pre-cache? How to ensure all remote imports are pre-cached?
• Should app code be dynamically loaded or not?
  • Migration code should definitely not be loaded during regular appspace sandbox runs. Or it should be possible to not load it.

I suspect the easiest might be to have all route and exec code statically loaded during normal appspace sandbox invocations. If it's a migration, then maybe run a different entry point script, that loads all migrations?

Let's establish that migrations should never access the net since we want migrations to be independent of external factors so that they'll always produce the same result (functional). This means we'll have to run migrations through pre-cache with no appspace connected, then run migration with --cached-only.