Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Server-Side WebAssembly

Server-Side WebAssembly

Slides van Jesse Wellenberg bij devCampNoord


April 06, 2023

More Decks by devNetNoord

Other Decks in Programming


  1. What is WebAssembly (WASM)? › Binary instruction format close to

    CPU instructions › Common compilation target › Run native code in a browser, at near-native speed
  2. WASM’s Good Sides Portable Fast Binaries are small & Architecture-

    independent Run at near-native Speeds Secure Sandboxed, memory- safe execution Language agnostic Develop with many different languages
  3. What Can It Do? Supported datatypes: - Bytes - Int32,

    Int64 - Float32, Float64 - Vectors - Opaque references Export functions for the host to call Import functions defined by the host
  4. What Can’t It Do? Due to the sandboxed nature of

    WASM, a module can’t directly access the host environment No access to: - Host memory - Filesystem - Network - Environment variables
  5. › Very narrow in scope › Extensible › Unopinionated ›

    No attached ecosystem › Open web standard How is WASM different?
  6. Calling WASM Add ( 20, 50 ) 70 Print() {

    Console.WriteLine(“Hello”); } Add ( int, int ) Print () Guest Print () Host Log: “Hello”
  7. How does it do it? Write “DevNet” Greet ( int,

    int ) Guest Host Greet (&devNet, 6 ) Read &devNet, 6 Write “Hello, DevNet” Read “Hello, DevNet” WASM Memory
  8. How does it do it? Greet ( int, int )

    Guest Host Greet (“DevNet”) Generated Glue Code Glue “Hello, DevNet” Read &devNet, 6 Write “Hello, DevNet” Greet (&devNet, 6 )
  9. WebAssembly System Interface (WASI) › Turns out, what makes WASM

    good in the browser is what we want on the server › POSIX-like API to expose host environment › Host has full control how this access is implemented Portable Fast Language agnostic Secure
  10. Capability Based Security › Explicity define the ‘capabilities’ the module

    has on execution › Grant Access to: › Files/folders › Network paths › Environment variables › Stdin/Stdout/Stderr
  11. Compiling C# To WASI › .NET can’t go directly to

    WASM outside of browser context (yet) › dotnet-wasi-sdk › Generate C entrypoint › Compile to WASI via clang › Limited functionality › Can’t import/export functions in C# › Write C code that does this
  12. WebAssembly Components › Layer on top of Core WASM ›

    Still a single binary › Main goals: › Interact with WASM in a way that’s native to the host language › Cross-language composition of multiple components › Stage 1 proposal › Looks like the future direction of WASM
  13. WebAssembly Interface Types (WIT) interface host { print: func(x: string)

    } interface guest { count-lines: func(x: string) -> s32 } default world line-counter { import imports: self.host export exports: self.guest } Implemented by host, imported by the component Exported by the component Definition of the component
  14. Components High-level WIT host guest CountLines (int, int) print (int,

    int) Guest Host CountLines (string) print (string)
  15. WIT as abstraction interface key-value { get: func(key: string) ->

    string set: func(key: string, value: string>) -> option<string> } default world kv-world { export exports: self.key-value } Key- Value
  16. Composing components Key-Value Http Server Message bus Business logic ›

    Imagine we’re a platform for serverless function execution › Platform provided bindings › Update without impacting users › User only has to care about their business logic component
  17. WASI vs Docker › “Hello World” console app in C#

    › Dockerized with basic dockerfile › Size on disk: › ASP.NET Docker image: 211mb › WASI: 9mb › Compiled from Rust is another 4x smaller!
  18. WASI vs Docker › WASI will be ‘lightweight’ class compute

    › Fire-and-forget logic › Very quickly spin up new environments › WASI is not going to kill containers (yet) › Docker probably better for longer-living services › New docker features allow running them side by side
  19. What’s next for WASM › WASI preview 2 is around

    the corner › Component model! › WASI implemented as components › Standardizing a set of cloud interfaces › Key-value › messaging › Blob store… › Microsoft has made no official commitment, but is watching closely
  20. Get involved! › Learn Rust! › The entire WASM ecosystem

    is built in it › Lots of fun stuff to build › .NET equivalents for existing tooling › Component implementations for Azure services › Experiments with WASI in real-world scenarios
  21. Some projects › bytecodealliance/wasmtime- dotnet › Programatically run WASM with

    C# › bytecodealliance/wit-bindgen › Generate WASM component glue code from WebAssembly interface types › deislabs/spiderlightning › WASM microservices and cloud capabilities › fermyon/spin-dotnet-sdk