feat: refactor runner code into multiple runtimes to simplify the addition of new ones #62
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Runner
struct had logic to process requests using different runtimes. Every of them requires a specific configuration for the source code and the WASI environment. Since we only supported two inputs (javascript
andwasm
), conditionals were simple and the code was maneagable. However, our goal is to introduce more languages in the future so this specific architecture doesn't fit these requires.Here, I refactored the
Runner
code into a separateWorker
module. This module defines both the mainWorker
class and the N runtimes we support. Adding a new runner only requires to add a new struct thatimpl
theRuntime
trait. Then, you only need to configure it in theinit_runtime
function (pending to implement).Apart from that, I introduced another major change. Now, interpreted languages will mount their source code into the module. Other language requires to mount
lib
folders to work, so it feels natural to use the same approach to all of them. Note that inWasmtime
we can preopen folders, but not files. It is an important statement as a folder may contain multiple source files and we want the runtime to have access only to a single one.For this, I added a new
.wws
folder. This temporary folder contains folders with the source code that it's required for a certain worker. To avoid collisions, every language will have its own scope and every source file a folder with a name based on its context. The folder name is based on the blake3 hash of the file content. I chose this implementation based on the performance metrics they provide.That approach opens new possibilities as we can add
glue
code in those folders and even third-party libraries. It will also provides transparency as users will be able to see the code that it's run and even debug it.It closes #61
Pending
init_runtime
function to get a<dyn Runtime + Send + Sync>
instance based on the file extension