Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there anyway to use the "cli" in the browser to produce the wasm file? #123

Open
dgrbrady opened this issue Jan 22, 2025 · 2 comments
Open

Comments

@dgrbrady
Copy link

I'm currently using extism to allow users to write plugins for my app using JS. Everything about the setup and experience has been pretty good aside from one detail: producing the wasm file.

My current solution is that I have an API endpoint that accepts the source code the user wrote. It then writes that file to disk, uses the node function (I forget the exact name atm) to call the extism-js CLI and pass it in the name of the temporary file to produce the wasm file.

It then deletes the temp file and sends back the wasm file.

On the client side, it takes the wasm file and saves it to storage via OPFS. Then when the plugin actually needs to be loaded, instead of it being fetched from a remote location, it's just read in from that client side storage.

This works, but it would be great if the client could just produce the wasm file locally without having to send it to the server. I understand that this repo is meant to be a CLI, but is there something else in the extism ecosystem I should look at to accomplish this?

Any advice would be fantastic! Also, thanks for making such an awesome toolset!

@bhelx
Copy link
Contributor

bhelx commented Jan 22, 2025

Currently, the compiler and steps behind extism-js are a bit too complicated to compile to wasm itself. there are too many tools involved and they are doing some system level things that might be tricky to do in a browser. The next version of this runtime will have this capability by allowing you to split up the "runtime" and the "user code" into two separate modules. So then, it will be easy to just create a wasm module with a data section with your js code (or bytecode) and ship that separately.

I think your idea of creating a builder service works. You should check out this project as a starting point: https://github.com/MAIF/wasmo. it's a whole extism plugin builder in a box. it's fairly tied to otoroshi but could be adapted.

If creating a builder service is out of the question, there is one other technique. Since wasm is sandboxed, eval is effectively safe to use. So you can create a single plugin that just takes user code and evals it. To understand what that looks like, see this tutorial: https://extism.org/blog/sandboxing-llm-generated-code. you could probably re-use that plugin or write your own variant.

Hope this helps!

@dgrbrady
Copy link
Author

dgrbrady commented Jan 22, 2025

Thanks for the tips! I'm pretty new to the wasm world, so I have to brush up on a lot of points but you've unblocked me for now. Speaking of things built on top of extism, is there a community repo/showcase site or something to show off the extism community ecosystem? I was looking for something like that last night but couldn't find anything.

Quick edit: I was already halfway to your second solution in my implementation, but just hadn't really thought about how wasm unlocks the usage of the eval function. Dropped the call to the builder service over the network and now it works without it. Thanks so much for the workaround!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants