Replies: 2 comments 4 replies
-
I have to examine this more thoroughly to be sure, but my working hypothesis on this topic is: For apps that already use a lot of Rust-based WASM to do authz stuff, using rs-ucan in WASM will feel natural and good. For apps that are primarily written in TS/JS and rely mostly on TS/JS tooling and distribution mechanisms, a "native" JS implementation will be most welcome. There is a fair chance that a JS implementation will be smaller over the wire. Also, the tools have a better chance of successfully applying bundle optimizations to a JS module graph than a WASM blob. That said, there is relatable appeal to having a single implementation for both environments (and possibly for other languages as well). |
Beta Was this translation helpful? Give feedback.
-
On the topic of Rust language constraints on the web, the number one thing that has bothered me is: async fns in traits. More specifically: there is no language support for async fns in traits (support is coming). There is a popular macro that sort-of gets you async fns in traits: https://crates.io/crates/async-trait. However, if you are like me and you deploy to both web and not-web, you end up using it like this in order to skip the #[cfg_attr(not(target_arch = "wasm32"), async_trait)]
#[cfg_attr(target_arch = "wasm32", async_trait(?Send))]
pub trait StorageProvider<S: Store> {
async fn get_store(&self, name: &str) -> Result<S>;
} This leads to a lot of macro / type noise for us that varies depending on the other bounds needed for the trait. |
Beta Was this translation helpful? Give feedback.
-
This is less of a spec-level concern, and more of an ecosystem one. Happy to move the topic elsewhere if there's a better place.
Something that has come up a few times is using rs-ucan to target both native code and Wasm, and then writing bindings into various languages (e.g. ts-ucan would become a layer on top of a UCAN Wasm UCAN, rb-ucan would wrap a native binary, etc).
This would save maintainer overhead, but we haven't tried this strategy in production yet. Wasm-flavoured Rust is certainly more constrained than arbitrary Rust, will sharing a common core restrict the wrapper language's APIs, how much of the project can be Wasmified, etc.
Just to toss my own hat in the ring, I'm all for trying this approach, but would love to know what others think.
Beta Was this translation helpful? Give feedback.
All reactions