Practical WebAssembly with Apex, wasmRS, and nanobus
0 likes71 views
This All Things Open 2022 talk shows how to use current-gen WebAssembly to build complex applications out of components.
![8 Node.js Frameworks Every Developer Should Know [UPDATED].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/8node-220510071716-1ceeb91f-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
Similar to Practical WebAssembly with Apex, wasmRS, and nanobus (20)
More from Jarrod Overson (20)
Ad
Recently uploaded (20)
Ad
Practical WebAssembly with Apex, wasmRS, and nanobus
- 1. 1 Practical WebAssembly @jsoverson How To Get The Most Out Of Vanilla WASM
- 2. Who here has used WebAssembly? @jsoverson
- 3. Who here uses WebAssembly now? @jsoverson
- 4. thinks the WebAssembly experience is straightforward and intuitive? @jsoverson Who here
- 5. 5 WebAssembly is dif fi cult because it can be anything
- 6. WebAssembly Isn't Easy @jsoverson For two reasons It Changes What Is Possible In Software 1 It unlocks potential we've never had before.
- 7. 2 WebAssembly Isn't Easy @jsoverson For two reasons 1 It Changes What Is Possible In Software Everyone's Still Figuring Out 1 There are many questions, few answers, and myriad parallel solutions
- 8. WebAssembly standardizes logic Containers standardized processes The Last Artifact @jsoverson WebAssembly is the fi nal step in standardizing distribution VMs standardized the OS & environment There is no next step. This is all software. VMs standardized the OS & environment
- 9. • Author, Web Expert, & Lifelong Hacker • CTO Candle Jarrod Overson @jsoverson Posts about WebAssembly, Security, and JS/Rust topics here Looks like this
- 10. 10 1 2 3 Understanding Fragmentation Bridging The Gap Building Something Real Agenda
- 11. Flavors of WASM Vanilla WASM WASI WASI Proposals WASM Proposals Plain ol' WebAssembly that adheres to the MVP spec. Runs everywhere. Browser: Server: Baseline Extensions @jsoverson
- 12. Flavors of WASM WASI WASI Proposals WASM Proposals WebAssembly that leverages early proposal implementations (e.g. threads). Support is variable. Browser: Server: Baseline Vanilla WASM + @jsoverson Extensions
- 13. Flavors of WASM WASI WASI Proposals WASM Proposals WebAssembly that targets the WASI (WebAssembly Systems Interface) spec. Great support on server side. Not tailored to browsers. Browser: Server: Baseline Vanilla WASM + @jsoverson Extensions
- 14. Flavors of WASM WASI WASI Proposals WASM Proposals WebAssembly that leverages early WASI proposal implementations (e.g. sockets). Support is universally poor. Browser: Server: Baseline Vanilla WASM + @jsoverson Extensions
- 15. Flavors of WASM SDKs Platform-speci fi c SDKs that leverage speci fi c host features. Compatibility is tied to host compatibility. Browser: Server: - - Baseline Vanilla WASM + @jsoverson Honorable Mention WASI WASI Proposals WASM Proposals
- 16. Just Because It's WebAssembly Doesn't Mean It's Portable @jsoverson
- 17. Lessons From JavaScript The community tried to make a universal module format with JavaScript, but we had momentum working against us Mobile: Server: Other: JavaScript + DOM + WebView APIs JavaScript + Server (e.g. Node) APIs JavaScript + Random stuff Browser: JavaScript + DOM @jsoverson
- 18. Lessons From JavaScript The community tried to make a universal module format with JavaScript, but we had momentum working against us Mobile: Server: Other: JavaScript + DOM + WebView APIs JavaScript + Server (e.g. Node) APIs JavaScript + Random stuff Browser: JavaScript + DOM We tried to write tools that would shim and transpile everything that wasn't core JS into core JS. It was an arms race. We never ful fi lled the vision.
- 19. The Opportunity With WASM We have a baseline already. It's up to the community to preserve it. Mobile: Server: Other: WebAssembly WebAssembly + WASI WebAssembly Browser: WebAssembly WASI is great for entrypoints like CLI apps and servers, but it's not critical for most libraries. If our libraries accept WASM/WASI as a default we turn our nose up at 1 billion+ devices.
- 20. 20 1 2 3 Understanding Fragmentation Bridging The Gap Building Something Real Agenda
- 21. What we want @jsoverson Building our basic needs into Vanilla WebAssembly is not trivial, but it's possible. 1 2 3 4 Rich data types Asynchronous operations Automatic linking Generated bindings
- 22. 4 What we want @jsoverson Building our basic needs into Vanilla WebAssembly is not trivial, but it's possible. 1 2 3 Rich data types Asynchronous operations Automatic linking Generated bindings Future: Component Model Now: Apex + wasmRS
- 23. What we want @jsoverson Building our basic needs into Vanilla WebAssembly is not trivial, but it's possible. 1 2 3 4 Rich data types Asynchronous operations Automatic linking Generated bindings Future: Threads, sort of and ...? Now: wasmRS
- 24. What we want @jsoverson Building our basic needs into Vanilla WebAssembly is not trivial, but it's possible. 1 2 3 4 Rich data types Asynchronous operations Automatic linking Generated bindings Future: WIT & wit-bindgen Now: Apex
- 25. WIT & Apex @jsoverson WIT Apex Both are IDLs. Both are interpreted by generators to generate code that would be cumbersome and error-prone to write by hand. WIT is a project tailored to the WebAssembly component model and fl uctuates as proposals fl uctuate. Apex is generic and use-case agnostic. It's a good parent IDL.
- 26. Until the component model @jsoverson Apex can help generate bindings, boilerplate, and integration code for WebAssembly today. https://apexlang.io
- 27. After the component model @jsoverson Apex can generate WIT and wit-bindgen can generate bindings WIT https://apexlang.io
- 28. After the component model @jsoverson You can throwaway Apex or keep using it generate other artifacts. JSON Schema API impls Docs WIT https://apexlang.io
- 29. Async Operations + Rich Data @jsoverson The wasmRS suite gives us reactive streams in and out of WebAssembly wasmRS WebAssembly wasmRS opens a socket into WebAssembly with bidirectional streams complete with backpressure and fragmentation. wasmRS will exist for a long time and will incorporate standards as they land. https://github.com/nanobus/iota
- 30. Years of Production Experience @jsoverson wasmRS takes lessons learned from waPC and pushes ideas further Complex Data Errors Host/Guest calls Browser- compatible Reactive Streams Async Operations waPC wasmRS Both give developers a common way of interfacing with Vanilla WebAssembly. Both have support for multiple languages on the guest and the host side. waPC will continue to work while the future is wasmRS. https://github.com/nanobus/iota
- 31. Automatic Linking @jsoverson Components built with Apex & wasmRS contain the data necessary to understand how they connect to others. and their exports Components declare their imports A runtime can connect them all, automatically
- 32. Nanobus @jsoverson Nanobus connects disparate components into one running application. microservice iota low-code iota wasm iota wasm iota Components (we call them iotas) postgres redis etc External services Nanobus runtime https://github.com/nanobus/nanobus
- 33. 2 33 1 3 Understanding Fragmentation Bridging The Gap Building Something Real Agenda
- 34. 34 URL Shortener First, we fi gure out the interface we want to expose In this case, we need two methods... ...each take a string... ...and return a string shorten URL ID lookup ID URL
- 35. 35 URL Shortener What it looks like de fi ned in Apex. Apex looks like code but it's just con fi guration.
- 36. 36 Where Do We Store URLs? shorten URL ID ??? We could store them in a database, but then we tie ourselves to a storage implementation. It makes our component less reusable and DEV/QA/PROD testing more dif fi cult.
- 37. 37 Where Do We Store URLs? shorten URL ID storeUrl(id, url) It's easier to ignore the implementation completely.
- 38. 38 Where Do We Store URLs? We can de fi ne our interface and leave the implementation for later.
- 39. 39 The Component Definition @service tags what we deliver (export), @provider tags what we need (import). Note: these are Apex directives. Directives extend Apex for project-speci fi c purposes like nanobus
- 40. 40 Generating Everything Let the apex CLI or the VSCode plugin generate everything automatically.
- 41. 41
- 42. 42
- 43. 43 This is the business logic. That's it.
- 44. 44 In lookup() there is zero unique logic. We're just calling the storage provider. We don't need code for that. We can get rid of it. After compiling, we end up with a wasm binary from 1 line of business logic.
- 45. Implementing Our URL Repository Provider But hold up... How much of the code you write to persist data or query databases is actually unique and valuable?
- 46. 46 Components don't need to be WebAssembly Code that already exists. Our Repository component then becomes 100% con fi guration. We de fi ne our Repository component in terms of its namespace and interface name
- 48. 48 We turned what amounts to a library with 1 line of business logic into a database-backed web service by reusing existing components and connecting them together
- 49. WebAssembly Is Ready Now 1 The Investment Will Pay Off @jsoverson
- 50. WebAssembly Is Ready Now 1 2 The Investment Will Pay Off Be Bold and Uncompromising @jsoverson
- 51. WebAssembly Is Ready Now 1 2 3 The Investment Will Pay Off Be Bold and Uncompromising Software Is Changing, Be Ready For It.
- 53. Appendix