List of videos

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://docs.google.com/presentation/d/1rM9x_XF7NKfJvG1uCdSSXcLowyZq-tUI1buHo83Dbvs/edit?usp=sharing Bacalhau (https://bacalhau.org/) is the distributed compute network from Protocol Labs (https://protocol.ai/), and open-source R&D lab building to radically improve the Internet. Bacalhau’s mission is to provide the next generation of serverless compute that can bring forth revolutions in decentralised science and distributed applications. Our goal is a global, updatable, resilient compute substrate that can run anywhere, on any device, without restrictions. WASM is the secret behind our new platform. We’ve leveraged the power of the InterPlanetary File System (IPFS) – a distributed data storage system – to build a global library of WASM tools and functions that can be run from anywhere, by anyone. Our system can automatically link together WASM modules from across IPFS, no matter where they are, and can update itself when new versions of modules become available. This all adds up to a global execution environment, running WASM, that ensures compute processing done by scientists and engineers today can be reproduced long into the future. In this talk, we’ll explain the vision and how the technology works, demonstrate the network in action and show how attendees can run their own WASM jobs on a distributed compute network without complex set up or technical challenges.

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://docs.google.com/presentation/d/1k-jxutQx0sqy7mW4Wg06Y3JmXLQCjM17mNReWyWgH1I/edit?usp=sharing&resourcekey=0-0CYXayoSrQpSCRVrjYCjgQ Support for garbage collection within WebAssembly (WASM-GC) will bring a host of new languages and frameworks to the web app space. Learn how the Dart and Flutter teams at Google are building on WASM-GC (among other upcoming standards) to bring richer, faster, more consistent applications to the web Until now, WASM-compiled browser applications have been mostly limited to systems programming languages – allowing a number of traditionally desktop experiences to run on the web. (Think AutoCad, PhotoShop, Google Earth.) The implementation of WASM-GC across WASM runtimes will bring a set of new languages and frameworks to an ecosystem dominated by C/C++ and Rust. The open source Dart and Flutter projects at Google have spent over a year adding WebAssembly as a target platform with the hope of improving application load time and interactive performance for Flutter experiences on the web. This talk will cover how WASM-GC expands the WASM ecosystem, some details on how Flutter and Dart approached migrating our existing JS-compiled web support to WebAssembly, and our hopes for a ecosystem that embraces WASM-GC across the browser and server to enable a more portable, secure, and interoperable future of computer systems.

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://wasmio-threads.netlify.app WebContainers is a Node.js-like runtime that runs entirely within your browser. Their development combines low-level hacking in (multithreaded) Wasm with a focus on delivering a reliable, functional platform. Let’s talk about how we built them, what we tried, what worked and what is yet to work! WebAssembly threads unlock a game-changing primitive for the Web and other targets. Workloads that require shared memory and parallelization can finally leverage the full power of the underlying platform. A much wanted addition to the spec that is now on its path to stabilization. Though this addition has been cooking as an experimental proposal for some time, that did not stop my team from exploiting its possibilities! We shipped WebContainers, a Node.js-like runtime that runs on your browser, years ago. The core of this engine and its performance characteristics are only possible thanks to threads, and to the versatility of the Rust ecosystem. In this talk, I’ll give you an overview of this new specification and how toolchains support it, how our use case is unique, and the bumps that we found along the road to production: what we’ve tried, what worked and didn’t work - and what is yet to work!

Wasm I/O 2023 / 23-24 March, Barcelona So, what does it mean to have maturity in software and systems? I will talk about the end-to-end WASM software lifecycle, from writing and compiling code & debugging pre-production errors, all the way to deploying systems with WASM and observability of production systems. What to do when WASM in production fails? How do you debug issues in code you don’t have the source of? How can we prevent these kinds of common issues from even happening in the first place? I will also talk about what it means to be a team of SREs, Ops, Engineers, etc. who are now tasked with maintenance of a system that has an embedded runtime or otherwise executes WASM code. This operational mode is more like being an “operating system” compared to an “application”, and how we all need to think like the teams at AWS/GCP/Azure whose services run our applications. Dylibso is building the operational tools for teams taking WASM into production, and I will showcase a couple of these products which address CI, security, quality, and resource management. I will announce our founding team as well as funding, open source projects, along with what the future holds for taking WASM seriously and bringing a level of maturity to the ecosystem that we are all looking for.

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://2023.wasmio.tech/docs/sessions/database_apps_in_webAssembly_springio23.pdf Wasm has emerged as a secure, portable, lightweight, and high-performance application runtime for cloud-native workloads such as microservices and serverless functions. However, the standard Wasm sandbox does not readily support database connections. The Wasm community has created several solutions to address the diverse use case scenarios for database applications. There are three important approaches. - Use host functions, such as Spin framework and the upcoming component model framework, to handle database connections outside of the VM and expose the data through APIs to Wasm guest apps. - Support existing database client libraries and drivers in Wasm guest apps through WASI-like socket APIs. - Embed the Wasm VM into a data pipeline and exchanged data with the Wasm guest app through shared memory space. Each of these approaches has pros and cons. In this talk, we will present examples of Wasm apps connecting to MySQL, TiDB, and Redis, databases. We will also discuss database UDF and ETL use cases built on Wasm functions.

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://2023.wasmio.tech/docs/sessions/wasm-blocks-procedural-modeling-with-micro-webassemblies-wasmio23.pdf This talk is about a crazy experiment where a DOM/DAG of nodes in a graphics application have been implemented as small Wasm modules, leading to an executable procedural model that can be streamed for an interactive experience. See it in action in interactive graphics editing and maps applications! Webassembly has become a robust tool for building client-side applications, and has recently made large advances on the backend as a tool for running distributed workloads. What about the data that lives in those applications though? In graphics editing applications, typically a DOM-like structure exists in-memory, and more interactive applications similarly store a Scenegraph/DAG of nodes. Recent advances in the graphics field involve procedural modeling techniques, essentially replacing the output of complex graphics operations with the steps to recreate the output. There are many proprietary mechanisms for doing this, but Wasm’s secure-by-default model is very compelling for the execution of arbitrary code from distributed sources. This leads to an experiment where procedural graphics nodes are compiled to Wasm (both cached, built-in functions, and user-authored nodes). They are then executed at runtime to see if we can run a massively parallel DAG in near-realtime. Applications are then shown, both of a map that can stream in procedural tiles, as well as in an interactive graphics editing application for sharing nondestructive edits. Hear some of the lessons learned from this demo, including how this technology could scale, and how it could benefit from initiatives in the Wasm ecosystem like the Component Model in the future.

Wasm I/O 2023 / 23-24 March, Barcelona Come for the async; stay for the bidirectional, reactive streams. WasmRS brings RSocket inside WebAssembly to deliver high-performance, asynchronous streaming on standard WASM. Current WebAssembly needs layer upon layer of care and consideration before you can use it in real-world applications. Jarrod has been adding, removing, and refining layers for years as he’s seen WebAssembly hit new limits. WasmRS is the latest iteration at ironing out major pain points with WebAssembly in real-world, high-performance situations. Use asynchronous, reactive streams complete with automatic fragmentation and back pressure as naturally as you would in native code. All with standard WebAssembly. This talk will show you how to build a streaming WebAssembly module in under ten lines of code. We’ll build a small wasm module that can handle gigantic files or remote streams without breaking a sweat and finish with a visual demo of wasmRS powering browser graphics.

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://docs.google.com/presentation/d/1A1EZDXgEG4lf5xZjBjRlP4SjvXZCCnJXJ1hGlIJvaVQ/edit A common use case for WASM is plugins. But setting up the infrastructure for hosting WASM plugins is tedious, and the experience of writing WASM plugins is often far from developer-friendly. fp-bindgen aims to solve these challenges for Rust developers by generating the runtime and plugin bindings. fp-bindgen is developed as an open-source project: https://github.com/fiberplane/fp-bindgen It’s goal is to make it as easy as possible to develop full-stack plugins (WASM plugins that can run in both a server-side environment and a browser) for Rust developers. Unlike wit-bindgen (a comparable bindings generator), fp-bindgen is opinionated in that it uses Rust data types as its source of truth for the plugin API. This makes it so that Rust developers don’t need to duplicate their data types to an external schema format. From those Rust data types, it can generate a Rust server runtime, Rust plugin bindings (to be used by plugin authors), and a TypeScript runtime for running the same plugins in the browser. Another difference between fp-bindgen and wit-bindgen is that fp-bindgen uses Messagepack for serialization, which allows more flexible extension of data types without breaking plugins that use an older version of the plugin API.

Wasm I/O 2023 / 23-24 March, Barcelona Slides: https://2023.wasmio.tech/docs/sessions/the-world-of-wasi-wasmio23.pdf WASI Preview2 is the name for the next major iteration of the WASI Command APIs in development, including WASI filesystem, and now also including WASI sockets. Based on the new Wit IDL, they offer much better bindings for non-C-like languages, much better virtualizability, and establish some important infrastructure for future WASI evolution. And, they have much more complete documentation, including some demos that you can run yourself to see how everything works. I’ll talk about the new features and design changes and show off some demos! WASI HTTP and WASI Cloud are two families of WASI proposals in development that show how WASI is about more than just POSIX APIs. I’ll talk about these new APIs, and I’ll discuss Worlds, and the infrastructure we’re building to all users and embedders to use just the APIs they need for their use cases. And finally, I’ll discuss the future of WASI. The Component Model gives us powerful new tools for composability, virtualizability, typed interfaces, and more. What will it look like as we built out more of the System Interface with these tools? I’ll give a brief tour of the future as it looks like with these tools in hand!