Engine-browser
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 21
- Forks
- 23
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 17
Description
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 🤔
- 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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by mapping the current Node.js runtime and adaptor sandbox, then investigate the browser-compliant build proposed with tsup and the impact of disabling vm.SourceTextModule. Validate whether adaptor download, extraction, compilation, and execution work in the browser, including UUID crypto dependencies. Done means a browser engine can run supported jobs, enforce offline adaptors, and emit logs for an embedding component.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, typescript
- Domain
- security, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100