Blogs›Shopify›WebAssembly Runtime for Extensibility
Shopify is exploring and implementing WebAssembly (Wasm) as a secure, performant, and flexible runtime for executing untrusted partner code on its own infrastructure, moving beyond browser-based use cases. This involves leveraging the Lucet Wasm runtime and compiling code from languages like AssemblyScript to enable extensibility for partners. This post details four approaches to debugging server-side WebAssembly, including compiling to a native architecture, using LLDB with Wasmtime, employing WebAssembly-specific debuggers, and leveraging browser developer tools. The post highlights the trade-offs of each approach, with native debugging currently offering the most refined experience for variable rendering and interpreted languages, while other methods are explored for WebAssembly-specific behaviors.
10/18/2023
Introduced Ruvy, a toolchain that compiles Ruby code into WebAssembly modules. Ruvy builds upon ruby.wasm and offers performance gains through pre-initialization of the Ruby VM and inclusion of Ruby files during the build process. It also simplifies execution by eliminating the need for runtime WASI arguments. Benchmarks demonstrate a ~20% improvement in execution time and ~70% reduction in compilation time compared to ruby.wasm with wasi-vfs.
9/7/2022
This post details four approaches to debugging server-side WebAssembly: compiling to a native architecture, using LLDB with Wasmtime, using WebAssembly-specific debuggers, and leveraging browser developer tools. It outlines the pros and cons of each, including variable rendering fidelity, support for interpreted languages, and the ability to reproduce WebAssembly-specific behaviors. Specific examples and tool recommendations (e.g., rust-lldb, CodeLLDB, Wasminspect, Chrome DevTools with DWARF) are provided.
12/18/2020
This post introduces Shopify's adoption of WebAssembly (Wasm) for executing untrusted partner code on its infrastructure, outside of the browser. It details the technical requirements (security, performance, flexibility) and the choice of the Lucet Wasm runtime. The architecture involves wrapping Lucet in a Rust web service (Wasm Engine) for I/O and module management. Performance metrics show negligible impact (under 5ms execution time) compared to Storefront Renderer. The post also discusses the generation of Wasm, choosing AssemblyScript as the primary language due to developer familiarity and static compilation benefits, and highlights the community-driven nature of Wasm development.