 Hey, everyone. Thanks so much for being here. I'm really excited to share with you a few thoughts on serverless web assembly and how that could be a really powerful tool for compute-intensive workloads. And before we get into that, just a bit about me. My background is a mix of computer science and bioinformatics. I'm currently a software engineer and in VTAY, which is a genetic testing company. And I'm the author of the book, Level Up with WebAssembly. Right. So before we dive into the serverless web assembly parts, I did want to review why WebAssembly can be a powerful tool for analyzing data in the browser. So whether you're talking about a desktop application, image processing, machine learning, or bioinformatics, these four are really good examples of tools that leverage existing code written in languages like C, C++, and Rust, and are able to bring those tools into the browser. And the reason why this is powerful, first of all, is because you are able to reuse existing code so you don't have to rewrite these complex algorithms into JavaScript. It's also nice because in some cases, you can get some performance improvements. For example, in the tool ribbon that I showed in the previous slide, we saw a 3x speedup by replacing slow JavaScript computations with an off-the-shelf tool that we compiled to WebAssembly. Using WebAssembly in the browser is also useful because you can leverage the user's compute power, which means that as a tool builder, this is much cheaper to host because all of the cost of the compute is distributed to the users. It's also useful if the data is local and you're analyzing that data and it doesn't have to go in the cloud. In that case, it makes a lot of sense to use WebAssembly in the browser. But what if these assumptions don't pan out? What if you can't leverage the user's compute power? What if the data is not local? So if that data, for example, is in the cloud and it's pretty large, you don't want to start downloading large data files to your user's browser just so you can run the WebAssembly there. So a few alternatives to that. One is just run it in the cloud, spin up some VMs, download the data locally, run the analysis, save the results, and then shut down the VM. You can even use more specialized things like AWS Batch where you can essentially develop a whole pipeline of tools and then each step can have its own set of CPU and RAM needs. Alternatives to that would be serverless functions. You know, analysis in the cloud is very nice, but it's also can be pretty costly and adds up pretty quickly. And so serverless functions can be an alternative, for example, Lambda or Google Cloud Functions where you can essentially have the scaling done for you so you don't have to worry about that. And the pricing is kind of on a per use basis. But in this talk, I do want to focus on one particular flavor of serverless functions, namely those that are specifically WebAssembly focused. For example, CloudFlare and Fastly. You know, the benefits of those are basically the same as the serverless functions, but on top of that, because WebAssembly is so light compared to something like a container, it is easier for serverless providers to make that function have very little cold starts or none whatsoever. And so that can be really important if your functions are short lived in the first place, you don't want to have to wait for hundreds of milliseconds before the function even initializes. It's also neat because you can now use WebAssembly both in the browser and in a serverless function. And you know, obviously you can do that today with JavaScript, but with this, you don't need your tools to be already written in JavaScript. You could take things written in other languages. And that's really the beauty of WebAssembly is that you can then run these tools wherever you see fit. So let's take a concrete example of this. So the application here is to build an API that simulates data from a DNA sequencing experiment. And so what that's going to look like is you call the API, it does some analysis and then it outputs some simulated DNA sequences. And so what that looks like is just strings of A's, C's, T's and G's that represent the genetic code essentially. And so what we want to do is have these simulations that simulate errors during the experiment, but also genetic variations between individuals. And so to do that simulation, we're gonna use CloudFlare workers and I'll talk later on why that is, but basically the very powerful no-call starts runs at the edge. But to do the actual simulation itself, we're gonna rely on a tool called WGSim. Now this is a tool that's commonly used in bioinformatics to simulate DNA sequences. As it happens, it's written in C and so we can compile it to WebAssembly and run it as part of that API call. Now one thing to note is that WGSim can't run on its own. It needs some initial data to start with and so it needs a reference sequence so that it can on top of that make small changes randomly. And so that reference genome we're gonna store on S3 and fetch a subset of it on each API call. One thing to keep in mind though is that CloudFlare workers are limited to 128 megabytes of RAM for now. And to get around that limitation, what we have to do is not keep in memory all the data and then send it. What we have to do is essentially stream the data in from S3, run the simulation and stream the data out as we have it to the user. So this would let us, for example, output a lot more than 128 megabytes of data. What's neat about this architecture also is that I can run the same thing in the browser or as a serverless function. In this case, it makes sense of the serverless function but there are cases where you can imagine you want to run things both in the browser and a serverless functions depending on where the data comes from. Is it local or is it already in the cloud? So this demonstration, I've deployed this to wgsim.sandbox.bio. This is the API endpoint. You can tell it how many sequences you want which chromosome you're interested in and the error rate that you want to simulate. So if you go to that endpoint, you will see this big mess of a result. This is actually a file format in Bioinformatics called FastQ. It's not the prettiest but you can ignore most of this and focus on the actual data sequences. And so this is what we want to simulate. So if we were to refresh, we can get different simulated DNA sequences from random regions in chromosome one. So this works. It's fast. It's scalable. It's cost effective. And so I'm wondering, well, why did I use Cloudflare workers for this? So I wanted to talk a bit more about that. And just as a side note, I'm not affiliated with Cloudflare. This is just my personal opinion. So one reason is like any other serverless provider, they give you the scalability of the paper use but they also give you first-class WebAssembly support. And in part because of that, they're able to reduce their cold start so that they're non-existent. Again, because WebAssembly is so light compared to containers. And so actually workers used to have a five millisecond cold start and then they recently modified it so that when you make an API call during the HTTPS handshake, they actually warm up your function then. And so by the time the handshake is done, it starts executing. It's very cool. The other thing that's neat is that this is powered by V8. And so V8 is the Chrome browser's engine that executes JavaScript and WebAssembly. And the reason why I mentioned this as an advantage and not just as a random trivia fact is because this means when you're running WebAssembly binaries on Cloudflare workers, you're still running them in browsers. It just so happens that that browser is hosted in the cloud. And so what that means is, like I said earlier, we can be in a point where we can use WebAssembly in the front and end of the backend. Well, this takes it a step further where we use the exact same dot wasm binaries in our browser and in Cloudflare's browser, which is really powerful if you're building tools that need to run in both places. The other thing that's really good is the debugging experience. And just to demonstrate it, this is what it looks like when I'm looking at my WGSim script. So this is the JavaScript code part. And so what I can do is come over here and click send. This will execute the code on Cloudflare servers and return the result right here. So far, so good. No, this is really earth shattering, but what's really neat is this part over here, which is the developer tools. This is not the developer tools in my browser. In a way, it's the developer tools in the browser that executes your code. And you can actually look behind the scenes what's happening. So if you remember, I mentioned that our algorithm needs to reach out to S3 first to download some reference data. And so you can actually see that by going to the network tab. And you can see that it actually, you can click on it, it reaches out to Amazon AWS and fetches some data. And we could preview it. This is the sequence that is being used as a starting point by the algorithm. And then it does mutation on top of that. And so what's beautiful is that this is not running on my browser, but it lets us get a view into the execution platform. Another neat application is the JavaScript profiler. This lets you see which parts of your code are taking the most time. Another thing I want to demonstrate is if you modify the script, you can actually rerun it without deploying the changes. So for example, if we went over here and added a console log statement, you can then come here and click send. You can see this refreshed. It says the script was modified. And so we can see the console log statement. And again, this console log did not execute on my browser. Executed on Cloudflare servers, but we're able to see the output of that, which makes it a lot easier to debug these kinds of applications. The other thing that's useful is a key value store. So if you want to store key value pairs at scale, this is really good for that, especially for read heavy applications. So one thing I've used this for recently is for storing perm links. So there's this app where you give it your local data. It analyzes it, stores the results into a key value store and gives you a perm link that you can share with others. So they could see the results without having your input data. And so this is a great place to store that kind of thing. Other useful tools are cron jobs. So you can run your JavaScript and web assembly on demand via an API call, but you can also have them run at schedules. So for example, I have a script that runs every half an hour, looks at some recent logs, calculates summary statistics, and stores the results in the key value store. So that way when I go to the statistics page, it just pulls the cash results from the key value store and doesn't have to recompute them every time. In terms of the limitations, so as I mentioned, 128 megabytes of RAM. And in terms of CPU, we're talking about 30 seconds for workers unbound. As I mentioned, as far as this is the current limits, it's possible that these limits get increased over time. And yeah, that is all I had to share today. If you enjoy this presentation and you're just getting started with WebAssembly, you can check out my book, Level Up with WebAssembly. And I do also have a whole bunch of free articles and videos that you can check out as well. With that, I wanna thank you very much for your time.