Engine-browser

[josephjclark]

Overview

engine-browser would be a version of the runtime (a Runtime Manager) which runs in the browser.

It requires adaptors to run in an offline-only sandbox mode. Adaptors which don't support this would not be supported.

Benefits

The immediate benefit of this is to allow examples on the docsite to be executable, enabling users to see output and better understand examples.

We will need an embeddable component which uses engine-browser. Maybe it has a tab to show log output from the run.

It will also enable the creation of an editable playground, allowing users to change job code before running it. This would be a separate app/page, hosted on the docsite.

Requirements

• We need to build the engine in a browser-compliant target. I think we can do this with tsup
• We probably have to disable vm.SourceTextModule, which the current runtime uses for sandboxing. We may need to create a lightweight eval context instead
• The engine should compile and run job code
• The engine must download and extract adaptor modules in the browser. I don't actually know if this will work :thinking:
• Logs should be diverted to the console, but also emitted from the engine as events, so that a wrapping component can consume and display logs.

Security Considerations

• I am pretty sure we need to stop adaptors calling out to the internet with real credentials, so the adaptor sandbox thing is important
• The running job will run in an eval context, which is a much less secure sandbox than the regular nodejs runtime. But users are running jobs on their own machine and be fully in control. It's no more risky that opening the console and pasting a bunch of code, surely?

Risks

• There's a bunch of stuff in adaptors which I suspect won't run in the browser. Crypto stuff for UUIDs, for example. I don't know if we need to introduce browser builds of adaptors or provide polyfills or what.