Open christian-bromann opened 1 year ago
Note that the WASM stuff is still needed for Windows, and available as a fallback through feature flags.
Is there any discussion on why WASM was originally used and why it was removed?
My assumption was that WASM was used to allow the VSCode Notebook Serializer to be implemented in GoLang (stateful/runme#64). It seems like the decision was to replace this with doing serialization on the backend and have vscode communicate via gRPC.
The reason I'm interested in this; is because I'm very interested in being able to run VSCode with RunMe entirely in the browser; similar to https://vscode.dev/. In this scenario you want to run serialization/deserialization in the browser so that vscode can open/save data without being dependent on a gRPC server. I think its advantageous to be able to open/save without depending on a gRPC server because then you don't risk data loss or slow down if a gRPC server isn't available.
Below is an architectural diagram illustrating a centralized deployment I have in mind.
Notably I'd like to be able to run the gRPC service in a stateless mode so it can be deployed in a serverless fashion. This is a lot easier and cheaper than managing stateful servers. This type of architecture would make RunMe a very compelling alternative to something like CloudShell. This would also make RunMe an improvement over bastion architectures for accessing infrastructure.
This is an example of some of the interesting use cases https://x.com/mattomata/status/1579195173489475584
One of the use case would being able to embed links in your runbooks that could open directly in the browser into a RunMe notebook that would execute commands inside a container.
After we now fully migrated to the Runme CLI we should clean up the code base and remove all WASM artifacts we have left, e.g. https://github.com/stateful/vscode-runme/blob/main/.github/scripts/downloadWasm.js