Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

WebAssembly Unleashed: Powering Server-Side App...

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.

Chris Fuentes

November 23, 2024
Tweet

Other Decks in Programming

Transcript

  1. 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
  2. What if… the same code could be used anywhere? on

    the web, cloud, embedded devices or your toaster…
  3. 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?
  4. 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
  5. • Easy install as a library. • Sandboxed runtime. •

    Allow us to use the WASM modules inside of a host language (Go, Rust, Ruby, etc.)
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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…
  11. 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.
  12. 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); }
  13. 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; }
  14. 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?
  15. 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.
  16. 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.
  17. • 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.
  18. • 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.
  19. 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
  20. If you notice… is returning only the speci f ied

    f ields on the WIT. Even though, the API retrieves more f ields :)
  21. 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.