Replies: 1 comment
-
If nothing else, native bindings could maybe also be useful to provide mock implementations for the bindings that can be used in unit tests for the plugin. Not using WASM for your unit tests makes a lot of sense because it makes your code easy to step through with the debugger. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Based on a Reddit thread, I started thinking: There’s clearly a demand for people to share code between their Rust backend and WASM frontend that doesn’t fit exactly within the plugin usecase. We’re doing this ourselves at Fiberplane: We have code that we share between both environments and server-side this code runs natively without WASM.
For us, we can make this work relatively easily because the code we share are all pure functions with no outside dependencies. But if you want to make calls outside it can be a bit tricky, because I think calling the functions from the plugin binding directly would get you into trouble with the linker outside the
wasm32
target. It’s possible to work around this, probably by using a little dependency injection shim that sets up the external APIs to either come from the plugin bindings or from a custom server-side implementation.So my thinking is, it absolutely makes sense to make this use case easier by providing a
rust-native-runtime
generator. Thoughts?Beta Was this translation helpful? Give feedback.
All reactions