vmware-labs / wasm-workers-server

🚀 Develop and run serverless applications on WebAssembly

Home Page:https://workers.wasmlabs.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Run a project from a remote repository

Angelmmiguel opened this issue · comments

Is your feature request related to a problem? Please describe.

There are many different ways a project / workers could be stored. Currently, we are allowing only local resources by pointing wws to a system folder:

wws ./my-folder

However, this restriction introduces an extra step of downloading and configuring the project in the environment. wws can identify the resources based on the path, extension and protocol, and prepare the environment on behalf of the user.

Describe the solution you'd like

All the examples require you to clone / download workers. Ideally, the demos must be available in a single command:

wws https://github.com/vmware-labs/wasm-workers-server.git

wws must detect the resource and prepare the environment based on it. For this initial implementation, it will detect links that ends as .git to process them as git repositories. I would like to set other specific configurations related to git like:

  • --git-folder
  • --git-branch
  • --git-rev

Describe alternatives you've considered

The current alternative is to ask you to clone the repo in advance. We want to avoid this and simplify the process.

Additional context

Related issue from @k33g (#121).

The first step to add this feature would be to identify a place to add this logic. wws goes through the following process every time you run it:

stateDiagram-v2
init: Initialize project
routes: Identify routes
workers: Prepare workers
server: Initialize server

[*] --> init
init --> routes
routes --> workers
workers --> server
server --> [*]

The project initialization requires:

  1. Load the project
  2. Install missing dependencies

Currently, the first step is not required as we only support the local filesystem. The second step is done as a separate step (wws runtimes install). Both steps are part of the same process as the project is not ready until the files are in the local filesystem and the runtimes are installed.

For me, it makes sense we consolidate these two steps into a single crate. For this reason, I will first rename the runtimes-manager crate into project to highlight the new scope.

Thanks @Angelmmiguel! I agree with the assessment of the current situation.

For me, it makes sense we consolidate these two steps into a single crate. For this reason, I will first rename the runtimes-manager crate into project to highlight the new scope.

I agree in consolidating both steps in one crate. I like the new crate name, I think it is descriptive. Another alternative name could be wws-worker-initializer, which is more verbose. I think we can go with wws-project though.