 Our last speaker this morning is Saul Cabrera, staff developer at Shopify. He's passionate about functional programming, concurrency, compilers, and computer science. He has been involved in a variety of open source projects and regularly gives back to the community, primarily through code contributions and documentation. He is speaking today on Wasm from the Inside Out, a journey through the impact of WebAssembly in production. Please help me welcome Saul. Hey everyone, thanks for having me. So this talk is about a journey through the impact of WebAssembly in production from the perspective of Shopify. And here Shopify is mostly an example, just to pick some. It's the use case that I'm most familiar with and I think it's going to highlight where was and was when we adopted it and where it's now. So my name is Saul Cabrera and I work in engineering at Shopify. And you might ask yourself, well, why I'm giving this talk? Mainly because I've been working in several places in this stack by need, but because it was needed in order to enable Shopify functions. So the first place that I was introduced to Wasm was Shopify Functions, which is where we at Shopify use Wasm. Then I've also been involved in creating a JavaScript on WebAssembly tool chains like Javi. And also my latest project is working on a baseline compiler for Wasm time in order to improve startup time. So as you can see, this goes from highest levels of the stack all the way down to low level. And this is why this talk is called from the inside out. We're going to see how this low level pieces have made of Wasm what it is today. So in order to understand the context of this talk a bit more, we need to understand how Shopify uses Wasm. And so my colleague Duncan wrote this article back in 2021 and you can refer to it if you're interested in all the details. But the use case behind Shopify's adoption of WebAssembly is really extensibility. And extensibility means opening Shopify's back end for execution of third party code as a way to customize business logic. And to concretize a bit more the concept of extensibility, we can take a look at the personas involved in extending Shopify. The first persona is merchant, which is really important. It's someone that wants to sell physical or digital goods online. Then the second persona that comes around is the buyer. The buyer is someone that wants to buy something from a merchant. The third persona here is a developer, which is a third party developer that creates an application to enhance Shopify's functionality. That could be similar to how other developers create apps for the iOS app store. And in the middle of this personas we have Shopify functions which enable complex interactions between these three personas. Now I'm going to make a step back from Shopify right now and just make a reference to a talk that I gave back in WebAssembly Summit in 2021 where I pointed out some challenges regarding adopting WebAssembly at the time. This talk presented an analogy between Wasm and the Concord, this earth plane that was revolutionary to the aviation industry. And the analogy basically was that the Concord was really great, revolutionary, but it was expensive to get access to by the masses so tickets were like 12k per person. So this was one of the factors that made WebAssembly, sorry, the Concord fail. And so I was making the analogy that if Wasm keeps being expensive to get access to it might fail too. And so with this talk I want to take a moment to reflect on those challenges and also celebrate because I think that those challenges have been sold. And so I want to reflect on those and just make sure that we can get a sense of how those challenges have been sold now. And so the challenges that I was mentioning in that talk is that authoring programs was hard. The lack of non-system programs targeting Wasm was basically non-existent. The other challenge is that understanding programs was hard. Debugging a WebAssembly program or knowing what this program was doing was hard too. I was not evident how to do it correctly. And the third challenge is that guest host interaction was really complicated. The amount of glue code that you needed to write in order to make sure that you could pass complex types around was hard. So let's go back to 2014. In 2014, Wasm was not ready to be adopted, I think. But Shopify was already thinking about solving problems that would be a perfect fit for Wasm's model. And the core problem at the time, and this is still the core problem today, but with better tools, is to enable more complex interactions between a merchant and a buyer. So in the end, when you buy something, what you're doing is you're finalizing a purchase proposal, and that proposal can have infinite terms, right? And those terms might only mean something to the merchant and the buyer. So Shopify as a platform doesn't really need to know and encode all those terms, because this is going to make Shopify hard to scale and hard to maintain. So by 2014, extensibility was handled as a product at Shopify, and the solution that was proposed was having a light Ruby VM. In this case, we were using M-Ruby, secured through SecComp. If you attended yesterday's Dan Goman's talk, he didn't mention SecComp, but for those of you who are not familiar, SecComp is a feature of the Linux kernel to secure system goals, basically. This solution also had to be fast. Because all these customizations are happening at checkout, where this third-party code is running inline. So you can imagine that you cannot delay the process of determining if appreciation needs a discount, for example. And so this solution solved a particular business problem. It worked, and it was designed with a specific need in mind, with the tools available at the time. But the question was, is it going to be scalable? Can this be improved? And the answer is that there were several cons that came around over time. And one of the first ones was optimization opportunities were tied to the Ruby VM itself. Now, General SecComp drawbacks, too, came around. Also, this solution was not polyglot, meaning that you were tied to Ruby as language. So thinking about supporting another language like JavaScript, for example, meant having to adopt a new engine like V8 or SpiderMonkey, or whichever any other JavaScript engine would that be? And then the fourth challenge here was storing untrusted code efficiently. As you can imagine, depending on what language you're choosing, that's how you're going to be storing your source code. And this could mean wasting space if this can be compact and efficient. So we fast forward to 2018, and the buyer and merchant interactions are starting to get more complex and harder to handle and scale. And the need for new use cases arose, and it was hard to think about scaling the current product into a platform to handle more demand. So by the time a hack using a Wasm interpreter written in Go showed that this new WebAssembly thing could be leveraged as an alternative, potentially removing the need to maintain many of the key features in-house, like, for example, security. So this new solution was, in theory, polyglot. It was secure, which was one of the main selling points of this new solution, and it was performant. An interpreter wouldn't caught our performance requirements, but thankfully at the time, Fastly open sourced Lucid, which was the first, I think, had a Wasm compiler in runtime that we eventually adopted, and Lucid represented a major step-up in performance over the interpreter-based approach that we had, and all the work behind Lucid enabled the first iteration of a new platform to enable synchronous execution of untrusted code. And so here I have this small chart of one of the initial experiments that we did, and here you can see that we have 100k Wasm modules running for five minutes per minute, running for five minutes, and which the P99 was around five milliseconds, which is pretty good for what we were looking at at the time. Eventually, given all the efforts that went into Wasm time and Lucid, and these two merged, we ended up adopting Wasm time, which is our runtime of choice today. Now, more questions came after the initial adoption of WebAssembly, and after having proven that it feeds the needs of the platform, and one of the first questions that came around was, well, what's the path to enable other languages to run fast on Wasm? Because C, Rust, C++ are cool, but they're system programming languages, and not everyone wants to use them to write extensibility code, which is fair, given that everything that Shopify does for partners is written in TypeScript or JavaScript. And pre-initializing WebAssembly modules was in great part the answer to this question, so this pre-initialization process was provided by this tool called Wiser, which is used in many other projects in the byte reliance to enable other languages to run in WebAssembly. And so with Wiser, we were able to snapshot a module ahead of time to improve a start latency. In the context of dynamic languages, you can, like for example, JavaScript, we could generate a snapshot modules, which most, if not all, that JavaScript initialization work will be completed ahead of time. In fact, there is a very good article written in the byte reliance blog that explains all this in detail, so if you're interested, you can go and read that one. But Wiser served as the foundation to creating these dynamic language toolchains, like for example, Javi, which is JavaScript on Wasm toolchain, that was the thing that brought support for JavaScript on WebAssembly to Shopify functions. Then the next question came around, solving the dynamic language problem on Wasm was not necessarily enough. The next question is, can we have smaller modules? Because when you start thinking about dynamic languages on WebAssembly, your modules start getting pretty big. If you're not familiar with this process, this normally involves compiling an engine and then having almost the entire engine in your WebAssembly module, so this tends to create very big modules. But then thankfully, the process of being able to link two modules together was the answer to this problem. And the way you would do that is that you would have a core or a code module that would be linked against an engine module and then you would be able to detach this process and have a smaller modules that would only contain the code that the user was interested in running. So you would just save a copy of your engine module in your servers. And so now we fast forward to today. There's a lot of work that's been going on and you're going to see that in the talks later today and use so that in many talks yesterday. But one of the main things is the component model. This is helping alleviate many of the challenges that were already presented in this talk and that we were thinking about in 2021. Also, a better debugging story in Wasm time is coming. There's a lot of work that's going in there so that we can understand better what the WebAssembly programs are doing in the runtime. And there are some initiatives to bring faster JavaScript on WebAssembly so that we can have better performance and better throughput. So before ending, I want to go back to all the challenges that I mentioned and just making analysis how these challenges are being sold. So authoring programs is getting easier and easier as time passes by. There are many tool chains that you can get access to in order to write programs that would compile, would bring support for Python into WebAssembly. Joel Dice is going to be talking about this later today. Guy Bedford talked about component.js yesterday and tools like Javi also help make this process easier. Understanding programs is also getting easier. As I said, there is a lot of work going in the Bicode Alliance to improve the debugging story in Wasm time, but also there are companies like Dilip, so doing a lot of work so that you can understand and observe what your programs are doing. And the guest and host interaction is going to be alleviated by the component model. With this, it means that you no longer need to write huge amount of glue code in order to make this interaction between the guest and the host easy to manage. So with that, I think that's everything I have. Thanks.