WebAssembly Unleashed: Powering Server-Side Applications

JSConf 2024: This talk starts talking about the beginnings of WebAssembly and its contribution to the modern web development as a critical tool to build amazing applications. Later the main topic becomes to explain how this technology can also have a big impact in server-side applications by allowing performant and portable code that can be used across multiple programming languages.

Transcript

1. WebAssembly Unleashed: Powering Server-Side Applications. Made with 💙
2. Chris Fuentes • Geek & Software Engineer. • I’m from El Salvador, living in Tokyo. • Open Source and community lover 💖 • Google Developer Group Leader 🇸🇻 About me :) @chrisft25
3. What if… the same code could be used anywhere? on the web, cloud, embedded devices or your toaster…
4. Portability • Portability is one of the biggest goal in software development, and we have specially seen this in the Javascript ecosystem since Node.js was born. • But, what if we can be polyglots and have the best performance?
5. ✨ Introducing WebAssembly✨
6. WebAssembly • First appeared on March 2017. • A high-performance, portable, binary instruction format. • Designed for browsers. • Port server-side code to the browser. • Generates modules. Our old friend
7. Designed for browsers… can we use it somewhere else? Yes :)
8. WASM Runtimes And many more…
9. • Easy install as a library. • Sandboxed runtime. • Allow us to use the WASM modules inside of a host language (Go, Rust, Ruby, etc.)
10. Are we ready to use WASM in server-side languages? Yes and no… let me explain
11. Challenges • We can’t perform I/O operations in a server-side runtime. • Type-safety development
12. WebAssembly System Interface (WASI) • A group of standards-track API speci f ications for software compiled to the WebAssembly standard. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere—from browsers to clouds to embedded devices. • WASI P2 was released on February 2024.
13. Available APIs at this moment
14. FileSystem APIs • Read-via-stream. Return a stream for reading from a f ile. • Write-via-stream. Return a stream for writing to a f ile • Sync-data. Synchronize the data of a f ile to disk. • Read-directory. Read directory entries. • Many more… https://github.com/WebAssembly/wasi- f ilesystem
15. HTTP APIs • Outgoing-handler. Allows a module to make HTTP requests (similar to a fetch() operation) to external servers. • Incoming-handler. Allows the host environment to deliver HTTP requests to the module. This is useful for creating server-like WebAssembly applications capable of responding to HTTP requests.
16. Socket APIs • Instance-network. Allows querying and managing network interfaces and associated IP addresses. • IP-name-lookup. Provides APIs for resolving domain names to IP addresses. • TCP-create-socket. Enables the creation of TCP sockets. • TCP. Includes functions to manage TCP socket connections, send/receive data, and close connections. • UDP-create-socket. Facilitates the creation of UDP sockets. • UDP. Handles data transmission and reception for UDP sockets.
17. Now, we can build • Modules that read/write f iles. • Modules that perform HTTP requests • Very useful for HTTP-based microservices ;) • Modules that open socket connections with databases. • Modules that can instance queues in message exchangers • Many many more…
18. Other APIs • CLI: https://github.com/WebAssembly/wasi-cli • Random: https://github.com/WebAssembly/wasi-random • Clocks: https://github.com/WebAssembly/wasi-clocks
19. Great! Now how can we make it type-safety?
20. WASM Interface Type (WIT) • WIT is an Interface Description Language (IDL) to describe the imports and exports of a module. • It is easy to read and write and provides the foundational basis for producing modules from guest languages (the one you use to create the module) as well as consuming modules in host languages (the one where you use the module) • WIT have two main concepts: interfaces and worlds.
21. WIT: Interfaces • An interface is a named set of types and functions, enclosed in braces. • An interface can reuse types declared in another interface via a use directive interface types { type dimension = u32; record point { x: dimension, y: dimension, } } interface canvas { use types.{dimension, point}; type canvas-id = u64; draw-line: func(canvas: canvas-id, from: point, to: point, thickness: dimension); }
22. WIT: Worlds • A world describes a set of imports and exports for the host to know the full type de f inition, enclosed in braces. • Describes the contracts of the module. interface printer { print: func(text: string); } interface error-reporter { report-error: func(error-message: string); } world multi-function-device { // The module implements the `printer` interface export printer; // The module implements the `scan` function export scan: func() -> list<u8>; // The module needs to be supplied with an `error-reporter` import error-reporter; }
23. WIT Core Module. Our main code. Quick Recap ~ WASM Runtimes Server-side Implementation System’s APIs Interfaces to extend capabilities Type de f inition of contracts How do we unify them?
24. ✨ Introducing: Component Model ✨
25. WASM: Component Model • Components are portable, interoperable WebAssembly binaries (.wasm f iles) that implement stateless logic. • Components may be compiled from a variety of languages including Rust, Go, Python, JavaScript, and more. • Because components can be compiled from many di ff erent languages and then interact with one another, they enable developers to break down language silos and utilize libraries and tooling in new ways. The component model leverage WASM, WASI and WIT all together.
26. Features • Portable: Because WebAssembly binaries execute against a virtual instruction set architecture (essentially a tiny VM), they are agnostic to architecture and operating system kernel. They are also very small compared to containers, so they can easily run in embedded devices. • Interoperable: Components can interact with one another over high-level APIs regardless of their respective languages of origin, so that a component written in Rust can utilize the functionality of a library from Go. • Composable: Multiple components can be combined into a single binary. This enables developers to build applications as if with lego bricks, satisfying dependencies with other components as needed.
27. Why “components”? We already have modules…
28. • A module corresponds to a single .wasm f ile, with functions, memory, imports and exports, and so on. These "core" modules can run in the browser, or via a separate runtime as we have seen. • Core modules are, however, limited in how they expose their functionality to the outside world and return only a small number of core WASM types (essentially only integers and f loating-point numbers) • Richer types, such as strings, lists, records (a.k.a. structs), etc. have to be represented in terms of integers and f loating point numbers, for example by the use of pointers and o ff sets. • For WASM modules to interoperate between them, there needs to be an agreed- upon way for exposing those richer types across module boundaries.
29. • In the component model, these type de f initions are written in a language called WIT (WASM Interface Type). • A WASM component is thus a wrapper around a core module that speci f ies its imports and exports using WIT.
32. Example Let’s build a simple component to make API requests
33. npm install @bytecodealliance/jco
34. Creating the WIT. • We are going to create a f ile called pokemon-http- client.wit. • Inside the f ile we de f ine: • The world we are going to export: pokemon-http-client • The type of Pokemon. • The function we are going to export: get-by-name
35. Making the code. Fetch, is being provided by ComponentizeJS in the runtime
36. npx jco componentize pokemon-http-client.js —wit pokemon-http-client.wit -o pokemon-http-client.wasm
37. Now we have our component created :D
38. Let’s test it out. JCo allow us to also transpile WASM to ESM.
39. npx jco transpile pokemon-http- client.wasm -o wasm
40. If you notice… is returning only the speci f ied f ields on the WIT. Even though, the API retrieves more f ields :)
41. Now we can easily create components that can be reused anywhere!
42. Key Takeaways • WebAssembly is not only for browsers anymore. • Write once, run anywhere—WASM modules can run across platforms without modi f ication. • Assemble applications by combining reusable components, much like LEGO bricks. • WASI allow us to extend the capabilities of our WASM modules. • Strong security is under a sandboxed and a capability-based environment. • The sky is not the limit.
43. Fun sharing ~ webvm.io
44. Happy Coding! :)