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

Possible to generate as wasm library #452

Open
kesavkolla opened this issue Sep 21, 2021 · 6 comments
Open

Possible to generate as wasm library #452

kesavkolla opened this issue Sep 21, 2021 · 6 comments

Comments

@kesavkolla
Copy link

I would request the dev team to make this implementation available as wasm so that we can use it in many other programming languages. Currently there is only go and cpp implementations available for cel-spec. There is one Python implementation done by some other project but it would make sense to make it as wasm compatible so that we can use it any programming language.

@TristonianJones
Copy link
Collaborator

The team is pretty small and currently focused on Go, C++, and soon Java. WASM is an interesting exploration after that for web-portability and nodejs, but not an immediate focus area for us since in general the performance of the native libraries is still significantly faster than WASM and the memory lifecycle is better-understood.

Could you tell us more about your use case?

@kesavkolla
Copy link
Author

Our usecase is to use CEL from Python and also from JavaScript. Currently there is no implementation for JS and Python implementatioin is not up-to-date with implementations of go and cpp.

If you support making either cpp or go implementation as wasm then we can use it in other programming languages. Yes WASM is not as fast as native calls but gives a immediate portability.

IMO interpreted languages like Python and JS WASM is not going to add that much overhead. wastime claims they provide as native speed as it can get.

@bivens-dev
Copy link

bivens-dev commented Jan 19, 2023

I'm also interested in using something like CEL & WASM to bring in a explicit policy layer into a front end web application where I would be using it for things like UI controls and I'm sure other use cases would naturally appear along the way.

I was also interested in using it for some backend services I was developing in Dart which isn't a supported language obviously but has pretty good support for working with WASM modules as an extension point in the language which would make it a consideration for me there too.

Beyond that, Node and Deno would also benefit strongly from a WASM solution similar to what OPA offers.

Not sure if there is any further thinking from @TristonianJones and his team since he last mentioned it. I know there were significant changes to the WASM environment too lately that might be of interest such as WASM-GC about to land in the browser.

@josephschorr
Copy link

Just noticed this issue and thought I might provide some guidance in case someone is still interested in running CEL via WASM.

SpiceDB compiles to WASM and uses CEL as part of its caveats computation system

@bivens-dev It would be (fairly) straightforward to run SpiceDB in-browser if you'd like to do frontend authorization-like decision making.

Otherwise, running CEL directly should be possible now, since we do so in our playground.

Take a look at https://github.com/authzed/spicedb/tree/main/pkg/development/wasm to see how we build, test and call the WASM code from the browser

@TristonianJones
Copy link
Collaborator

@josephschorr so you're running a WASM build of CEL (and all of SpiceDB) in the browser? How are the binary sizes? Last time I tried for cel-go, I got a 20MB binary.

@josephschorr
Copy link

josephschorr commented Jun 1, 2023

@TristonianJones Yep and yeah, the binary size is quite large (~25MB) but since we can aggressively cache it, its not a huge deal to background load it the first time the Playground is used and then keep it cached moving forward

Edit: one additional benefit I should note is this means our Playground is executing the same production-level code for computation, so we have a guarantee that it won't diverge from a "real" implementation

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

4 participants