Episode #93: WebAssembly and WASI with Aaron Turner
March 22, 2021 • 57 minutes
On this episode, Jeremy chats with Aaron Turner about the use cases for WebAssembly, how WASI makes serverless compute at the edge even more portable and powerful, some popular WASM toolchains, and what the future of this technology looks like.
Watch this episode on YouTube:
About Aaron Turner
Aaron Turner is a senior engineer at Fastly. They were previously doing rad stuff at Google and various startups and agencies. In their spare time, they are hacking on various WebAssembly projects on the web, cooking up some dope beats, and shredding local skateparks.
Jeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm joined by Aaron Turner, hey Aaron, thanks for joining me.
Aaron: Yeah. Thanks for having me. I'm really excited to be here.
Jeremy: Awesome. So you are a Senior Software Engineer at Fastly. So I'd love it if you could tell the listeners a little bit about yourself and your background and what you do at Fastly?
Aaron: Yeah, totally. So what is it about me? So what I do is I work a lot of WebAssembly. We've been doing that for about two and a half years. I started getting really involved in the community and through that work, I was going through a lot of meetups and things, and I ran into Tyler who was the CTO Fastly and they were working on this new edge WebAssembly thing. And just the timing lined up and our interests and both were passionate about the moment it did. So I joined the company and it's been going great so far. And there, what I'm working on is a lot of WebAssembly work, both in terms of bringing on new languages to the platform, but also it's a lot of community work, participating in a lot of events, still doing podcasts and things and just hanging out with people and having a good time.
Jeremy: Awesome. So actually I had Tyler on the show not that long ago. And we talk mostly about computed edge, but we got into WebAssembly a little bit and I'm finding this whole thing fascinating. Because I remember way back in the day Java applets and of course Flash if anybody remembers that, I think that's still around. But this idea of trying to bring compute and more complex applications in a bytecode form, bring those to the browser. And this a really interesting thing, I don't think it worked out really well in the end, but it seems like WebAssembly is a better shot at doing that. And I find that really, really interesting. So I'd love to just pick your brain for a little while here and talk about WebAssembly, but I think maybe for the benefit of the audience why don't we start with what exactly WebAssembly is?
Jeremy: All right. So there's a lot to unpack there. And so what we can do is we'll go through some of those things. But just in terms of like, I think this is where we look at things that run in the browser. And I know we'll get into this, that you can run a WebAssembly in more places than just the browser. But running in the browser one of the things that I think we think a lot about is security, what does it have access to? Can it do network calls? Can it access local resources, things like that? What are the capabilities of WebAssembly?
In this case, log out a number let's say, and then let you continue executing. So this opens up all types of cool use cases of depending on what the host wants to provide, you can start doing some really cool things and have this security where the user can give you some code that you don't really know what it's doing, but only has as much power as you will let it have a doing those calls really. And that, since that memory is sandboxed they can't work out of there either. So starts to build this very secure. You can start trusting code that people are giving us because of these two features, which is really exciting.
Jeremy: Even if there was, it's not going to work the same way in all browsers I'm sure, so ...
Jeremy: I get the point.
Aaron: That type of business logic where you're trying to translate things and just stuff that's really tedious on the CPU. You can start to put that on WebAssembly modules and from the portability too, you can start sharing it on different platforms. And it's like, oh, this is really exciting. Yeah.
Jeremy: I'm not either. So yeah.
Aaron: I've definitely seen some projects that are like, hey, look, we can make this things secure with WebAssembly. Here's our white paper on why, but I wouldn't be able to confidently sit here and be like, oh yeah, totally just throw secrets and WebAssembly, no one will ever know what it is. You know what I mean? So I would definitely suggest maybe I always get back to you about that or we can do ...
Jeremy: Yeah. No, I'm just curious. I'm thinking through the places where it really fits in. Because I think that's a problem, security in the browser, it was with so many people using APIs now usually, and again, a good use case for serverless is essentially setting up a function that all it does is just adds that secure key or whatever it is that access token into a third-party API calls so that you can just pass it through from your from browser. So if you could eliminate that step, you know what I mean? And be able to do some of that I think that would be interesting.
Jeremy: Awesome. All right. So let's move on. Let's talk about WASI. What is WASI?
Aaron: Oh yeah. So WASI is an acronym for the WebAssembly System Interface. And this is where in my head, WASI is the node of WebAssembly. I know it's a very loaded term, so please take it with a grain of salt, but essentially it's a standardized system interface for WebAssembly. So you get things a lot of positive Slack calls, if you're familiar with a lot of ... it's getting low level, but you can imagine stuff like fd write, fd read. So reading file descriptors and things, you get access to those things. So you can imagine a Node, you have file system and that's how you would let's say, make generate files on a server. He used the module fs. WASI offers that lower-level primitive that allows you to do those things in WebAssembly like create files, read them and move them around your file system, which I'm talking in circles, but I think I get the point. So what actually ...
Jeremy: So you wouldn't use WASI in the browser, right?
Aaron: So it gets funny there because there have been some ... you can use things IndexedDB if your familiar to create a pseudo file system and start to port, maybe let's say you wanted to compile something in the browser. If you want to bring a C compile into the browser, you could use the WASI things and mock out some of these system-level resources as a browser equivalent and get into this funny world where it does make sense. But WASI itself one of its goals right now isn't really to run in the browser if people are bringing it there. So if you want to, again, bring a compiler but you totally could, which is exciting and really cool. And I think that there's a talk by Ben Smith they did this exactly for their class. They taught I think I forgot what university, but yeah, they made like a C compiled WebAssembly compiler that link took C source compiled it. And then there's something else is I wanted to say about that?
Jeremy: Well, I'm just curious, so then if it's not really for the browser, I get it. Everybody loves to do those things like, oh, can I take this thing that wasn't built for this and make it work in that. But so what would you say are the primary use cases then for using WASI?
Aaron: So a lot of it is probably bringing WebAssembly to the server. Yeah, probably for the server or just even standard command line applications. WASI is really exciting. There's a lot you can do. And you'll hear me say that a lot about WebAssembly, there's a lot you can do with it. So really I like to think of WASI as like all the benefits of WebAssembly, so that sandboxing that you get and that host calling interface. Because really what WASI is using is it host call just like, hey, you have access to the file system please, do what you want with it. So because you get those benefits. There's an infamous tweet. I know I'm talking, but ...
Jeremy: I think an infamous.
Aaron: Infamous, that's not the right word, but a tweet that went viral by Solomon Hykes. If you're familiar, the co-founder of Docker about how WASM plus WASI existed. And I think in 2008 is when they made Docker that they maybe had not needed to make Docker. And the reasoning there is that like, if you could take different applications and compile them down and give them access using a system interface that's standardized and have access to things like file systems, you can start to imagine this world where you get container-like functionality where you're just like, hey, I'm gonna compile my whole app and all of its dependencies down to WebAssembly, give it access to WASI and they can start to do things, and operate in a sandbox way where you don't have to worry about it messing with the parent operating system or completing with other apps and things like that.
And then of course we're on Serverless Chats. So a lot of serverless use case there because WebAssembly is very I guess lightweight and things of that sort. Sandbox, it makes it a great contender for serverless because you can just instantiate the WebAssembly module start running immediately and then close it down. And even do things like snapshotting of the memory and saving state and things like that. But we get to in the future there's still some kinks to figure out there just in general in the whole ecosystem. But yeah, and then a lot of standalone applications. So we were mentioning if you want to compile a C compiler to WebAssembly, give it access to WASI and run it on your local machine. Now you can start compiling things on your actual let's say standalone runtimes. If you just wonder if for some reason it gives C source code to just a WebAssembly module and have it compiled.
Yeah, sure. Cool. And I'm sure there will be use cases for it because then you could imagine a world where it's like, I won't use the exact same file that I used my exact same compiler binary, because I use Mac windows and Linux all do recompile for each architecture at each operating system. So again, that portability and yeah, it was probably, those are really good use cases I can think of off the top of my head right now.
Jeremy: Right. And this might be a stupid question, but I guess the idea of it being the Node of WebAssembly in that sense where basically that's what it is. It's its own container essentially that can do anything, it can interact with the file system, it's got all of the capabilities, HTTP networking calls, it can do all that stuff. And I know the V8 engine is pretty popular with edge computing and things like that, is that something where that can run on like a V8 engine or is there another type of underlying, I guess, container management system or something that would need to run those?
Jeremy: Right. So there are standardized runtimes for WebAssembly?
Aaron: Yeah, totally. So I will say these are also still in flux, they're still being developed. And if you want to participate there's totally community group for WASI that you could totally hop in and join, but this is me, I attend the meetings, having for a little bit. So it's like sharing this little things is going on here and there. So yeah, one of them is definitely crypto, a colleague of mine, Frank Dennis, is working on that where there's a lot of common crypto applications that we would want the host to say, hey, the host runtime we know that you're running just raw bytecode, there is no layer between you and the kernel essentially. So could you please provide SHA256 and make sure that it's working correctly, you won't expose the right thing.
So probably like common crypto functions that people are often using. I don't know if SHA256 is one of them I heard ... you can imagine. If you're a crypto person out there you know, exposing those common ones that folks use. And then machine learning, I'm a little bit more familiar with that because the Bytecode Alliance is a group of different companies that are working together on WASI and WebAssembly and all these specs and they recently announced they're working on a WASI. So a neural network and WASI and providing the primitives there of, if you want to build neural networks on top of WASI what are some of the host calls that we'll need? What are some of the functionalities that we'll need? So we start to build our own neural networks in WebAssembly, which is really exciting.
Jeremy: So are these standardized APIs? Again, this may be a stupid question just because I don't know enough about this stuff yet, but are those NPM packages or Python packages from PyPI or something. Whatever it, is that the idea behind some of these APIs where you say, I need a crypto package, or I need a machine learning package, or I need an image manipulation package, is something where there will be an ecosystem where people can write and contribute packages that other people could just pull in?
Jeremy: Yeah. Cool. So let's into the toolchains here and maybe we just focus on the popular ones because I'm sure they're a lot of people that are going down this road but you mentioned earlier that WebAssembly was language-agnostic, so you can just write it in any language you want or? There's got to be some limitations here.
Jeremy: Well, just thinking back to things that I've heard, I feel like whenever I hear Rust I just think WebAssembly, is that the wrong way to think of it?
Aaron: Rust does a lot of different things, but it's not maybe the wrong thing just because they spend a lot of time really building out a lot of the tooling, a lot of the community around it and things. So Rust definitely also has lots of great use cases that I've seen at Rust conferences where they were in Rust on no server, they do it in games, so on and so forth. It's a systems level approach, so programming language. So you can imagine you can run see there. Nine times out of 10 I think you could run Rust there, but just there WebAssembly ... What's the right word? Involvement, there's another word starts with an "I" that means what I'm trying to say, but they spend a lot of time working on creating a great developer experience on WebAssembly and Rust. So yeah, because right now I will say like some languages like Go and things are still very young in their WebAssembly implantation. So some of the tooling is like, good luck, but I'm sure that will get better over time as more of the community works on it and things.
Aaron: Yeah. So one thing is I'll definitely point out is that we mentioned earlier about SPAs, but just imagine not even ... I'm trying to think. So if you take a TypeScript React app or TypeScript Node app, you can't just grab the AssemblyScript compiler and be like, hey, I get WebAssembly for free. Cool. That's not how ... There's a lot of small fundamental differences where you have to actually take the time to port things. But the porting comes down to like, okay, you know this number type number isn't again, that strictly type integer of whatever many bits. So you have to take your numbers and convert them to i32s, you'd use a float there, you need to specifically say like, I want to float here. And things of that sort. But for the most part, I actually wrote an article in the Facet Blog about porting TypeScript to AssemblyScript and what that looks like.
Jeremy: So in terms of the workflow for some of these things, like I'm writing TypeScript now you got to compile it, right? And then I usually run tests against my TypeScript and then compile or compile and run the tests. So what does that workflow do I have to go from ... Or I guess I just writing in AssemblyScript which has to be very similar to TypeScript and then just compile it down to Rust, but how does the testing work and some of that other stuff?
Aaron: Yeah. So that's actually probably the best closest thing. So AssemblyScript is an NPM package that you MPM install into a project and you can scaffold out in AssemblyScript project essentially. Another thing is AssemblyScript it pretty much uses the .TS file extension, so if you'll put the .TS code it's like, oh, hey, this is a TypeScript. And it comes with a TSConfig. So the TSConfig will say like, hey, i32 was an alias for number for your Linters and things. So you open up VS Code and it's like, oh, this is just TypeScript. Cool. Awesome. So you can just hit the ground running in that aspect. If you're used to writing TypeScript, the amount of workflow difference should be near nothing to my experiences. When you start doing some really specific TypeScript things or if you have small things here and there, it gets funny.
Jeremy: Right. So you write something in AssemblyScript, I know we were talking, so that is compiling it down, is that using WASI? And then what can I do? Can I pull in Node packages in there or does everything I do need to be AssemblyScript?
Aaron: Yeah. I'm glad you asked. So it ends up compiling to it. So this is really technical but it uses a compiler backend called Binaryen. And it pretty much sits at the same level as LOVM if you're familiar. So it uses their immediate representations you then compile to WebAssembly. And then on the note of using separate NPM packages, it would have to be AssemblyScript all the way down. So that is one thing that some people are like, oh, but my favorite image thing is it there? And it's like, we'll have to port the dependencies to you which is annoying, but the ecosystem is really growing. For example, I've been running a lot of URL packages lately for URL parsing. And I saw we have the testing library, there is someone who recently wrote a JSON parser. So there's lots of little small things popping up. The community is growing and it's all an NPM.
So if it says like, hey, look, I'm an AssemblyScript package the VM can install it, and then it should work in your MPM project. I think you asked one more thing.
Jeremy: No, I was just wondering again, if you have the same access to some of the low-level things. So if you're compiling down to WebAssembly using AssemblyScript, are you then able though to do things like HTP calls and access the file system and those things?
Yeah. So that's what you'd ask about WASI. So yeah, essentially you would say, hey, import WASI, and then it'll give you access to those fd read, fd write and stuff, you don't have to directly access through file descriptors. Another community project as-WASI, is kind of like sitting at the same level of Node where you import file system as a whole word. And then it has a create file or maybe not create file, read file, write file, whatever the API names are that I can't remember in my head. But we do into this interesting place. We have a project, an AssemblyScript project, that we're waiting for HDP to be standardized on WASI for that is just called AssemblyScript/Node, because ideally since the APIs are so similar there's nothing stopping us from creating a very as close as to Node as possible API where you can start to just maybe copy paste notes then they should just work, because the languages are so similar.
Aaron: One last ramble if you don't mind ...
Jeremy: No, go ahead.
Jeremy: Well that's portability too, right? That's really actually, that's cool. So you mentioned a little bit about the ecosystem and the community around it. That is a huge thing where again, things grow when stack overflow is a lot of people's friends, right? So if you can't get your questions answered there or you can't Google for some of these things. So I know you said you've got the ecosystem is growing and you've written a bunch of blog posts and there's a bunch of other people working in this. But if I'm out there and I'm working on AssemblyScript, am I going to be able to find a lot of blog posts on this or is this still very, very early?
Aaron: Yeah. So I think it's probably a little 50/50 not that it's that early. So I guess the reason I'm saying 50/50 is because there's not swaths of people in stack overflow, they're all the AssemblyScript experts that can answer all your questions. The community's a little tighter. So we have a discord server and we have a help channel that's very active. If you want to have a question asked by the person that writes AssemblyScript. Yeah. They're there almost ready to answer any questions, I'm there. Our teams about four to five people, I'm sorry, a sixth person, but we're all there. And I check at least maybe every couple ... whenever I have downtime at work, I'll check and see if anyone asks me any questions. So it's a tight community on our discord.
In terms of blog posts, there's a lot of blog posts. The only reason why I'm 50/50 there is because the project has grown really fast. So there are some blog posts even that I've given that's like, hey, here's how you use pointers in AssemblyScript. Yeah. Not everyone wants to do that. Now it's like, we have more mature runtime, garbage flexes to someone's stuff. So your mileage may vary depending on what block ... There's a lot out there, yes, but maybe 50% of them are still very relevant to the AssemblyScript you would write today. If that makes sense. Or be there like, here's how you write your own JSON thing, but now there's a package for it. So they don't do it? So yeah.
Jeremy: That makes sense. So have people been using this? Are there some success stories here? Have people been successfully building applications with AssemblyScript?
Aaron: Yeah. So just going chronologically in my head. The first one if I may a little self-plug here, is that the reason why I got involved in the project was because I was really excited about WebAssembly when I heard about virtual performance and I was like, oh, I got to get on this asap. So one thing I like to do was build emulators because I think they're really good at testing any new technology because you need graphics, you need audio, you need to make sure that it runs fast enough or things of that sort. So I built in Game Boy emulator called WASMBoy in AssemblyScript. And it's really early days where I was just pointers, memory, stuff's moving, but because it was a Game Boy emulator that's what you have to do anyways. And from that, we found a lot of bugs in the project and we worked through them together.
And then I know Shopify publicly announced they've been playing with AssemblyScript a lot. I know from being on the team we chat with them a bit, but I don't want to get too into their business, but I'm very happy for them. But I would redirect you over to what they've said, just I don't see any wrong. Yeah. But they're trying us out as well, which is really exciting. And shipping stuff if I'm not mistaken. So, yeah.
Jeremy: Awesome. So it sounds like WASM and WASI, AssemblyScript, all of these things are coming together. It's growing, it's becoming more solid like you said, you wrote some blog posts where it was really low-level stuff, and then you started building ways that make that easier. So I guess there's still some limitations in here, it's probably not the right choice for everybody, but I'm excited about it because I think that it could change a lot of things, but I guess maybe since you work on this team and you're part of this ecosystem, what's the future? Where do you think this is going to go? And are we going to get to a point where we can use this for pretty much just everyday stuff?
Aaron: Yeah, totally. So the first one that I'd probably be most excited to bring up is this idea of nano processes. So that sounds really flashy. So I'm not the one championing this, I'm not the main person behind this. I would very much redirect you to Lin Clark's talk who gave a talk about this idea WASM summit of last year. But from how I interpreted when nano processes has this idea of that there's this concept of shared nothing linking. So for example, in the MPM ecosystem, if you have an MPM module that requires another MPM module, and this top MPM module was like, hey, look, I want access to everything that MPM or Node provides. And in this bottom module, and for some reason, this module is like, going to throw some things on global because I feel like it, and the bottom module is like, oh, that's cool. I'm going to figure out some way to get required by this person. That way I can start accessing the things that I didn't have to require.
So trying to specify that and find a where we can standardize that so that WebAssembly stays fast in that regard of passing memory around between other WebAssembly modules and leading towards that. And take it with a grain of salt, but that MPM-ness, everyone is connecting these packages, like LEGOs that build a bigger picture and a better structure using community and open source and things. So, yeah. Let me try to think, and then ...
Jeremy: Was there anything on performance? I know the performance is pretty good, but any updates or ideas on performance?
So that's really the idea is that if you had a vector by the mathematical terms, but if you had an array of numbers and you want to add them to another array or do the same single instruction to multiple data, it just does it all once. And it's lots of performance benefits out of that. So getting that working in WebAssembly it has a ridiculous number of different instructions because you have to think, okay, well, if I have an i32 that's six long versus it just creates a lot of WebAssembly instructions. I'm probably rambling a little too much. And then I had one more note and threads. Thread is another ...
Jeremy: Yeah. Threads, I was curious about that because I didn't ask you that earlier. And I'm just wondering is when WASM runs, is it single-threaded multi-threaded, can it do to do multiple threads? How does that work?
And they're really building a lot of their port on top of WebAssembly threads, which a lot of folks at Google are doing a lot of specification work there. So it just shows like, hey, look, we can watch whatever random video format, the browser, only the supported ones using a VLC port. Yeah. And also, again, I'm not an expert on the work at VLC. So we can do some Google searches I can send a link or provide more research later, but yeah, those are super exciting. So yeah.
Jeremy: And that's actually ...
Aaron: ... not to downplay myself, but you know what I mean.
Jeremy: No, no, no, no. No, but that's interesting because that's the thing where, think of a global NPM, you know what I mean? Where it's just some functionality was built and if you can pull that in to maybe you're AssemblyScript person because that's what you're familiar with, but you can't make AssemblyScript, do some complex crypto thing or whatever that may be some other language could and compile down because it's either further along or whatever it is. Being able to share those across applications and reuse those. That sounds pretty exciting.
Aaron: Yeah. It sounds super exciting. Definitely, I think that's the future we're headed towards. As a community, we'll see what gets announced here and there and things. And again, there are some folks trying it out already, this idea, but no, we'll see. Really it began also, as you are very bullish on this idea of like, yes, we can totally have this cross. It's no longer are we bounded to our languages. It's like, we just write code and we can all be one large ecosystem. It's going to be awesome. I'm looking forward to it.
Jeremy: Cool. So I want to ask you one more thing though. So let's say that I'm a developer I'm listening to this. And I say, WebAssembly sounds amazing, how would I convince my development team or more importantly, probably my boss, how would I convince them, hey, this is something we should start investing in?
Aaron: Yeah. I'm so glad you asked. So the thing about WebAssembly that's really interesting, and I get asked this often, it really depends on what you're doing. We've maybe covered like, oh, you can do this, you could do that, you could do this, so it depends what your area is. For web applications definitely if you're building an application that does computationally-intensive things, maybe you're working on an online photo that, or whatever it may be. Maybe you're working on a spreadsheeting tool where you have to do complex math functions. Just understanding really where WebAssembly fits into an application that's where you can start to make the pitch to your boss. So if you're really excited about this right now, I have some resources that I built called WASM By Example which is how you can get started with little bite-size examples of WebAssembly, but another one is Made with WebAssembly.
So wasmbyexample.dev and then madewithwebassembly.com. WebAssembly is just a showcase of a bunch of folks using WebAssembly in production and side projects pushing like, okay, well what's what WebAssembly good at, these are some examples. So if you can go on madewithwebassembly and you're like, oh, my app does something similar to that, maybe you're on the right track. Maybe it's worth considering well, what your team needs and things. So yeah, I guess really just understanding what WebAssembly is good at and then see, how can we fit this into our application is probably your best bet, because then you can make a solid argument for why.
Jeremy: Awesome. All right. Well, I'm going to put all of that information in the show notes. I know there's a bunch of links that you have and all really good documentation and just good ideas, like you said if you want to convince your boss or whatever to use it. So I'll make sure I get all that in the show notes, but Aaron, thank you for sharing this. This was super exciting because I just don't know enough about this stuff. So anytime I can, I just love learning this stuff. And I'm super excited about the computed edge stuff. I think WebAssembly is such a great packaging format for that. But I'll put some of those other links you mentioned in the show notes, but if they just want to find out more about you how do they do that?
Aaron: Yeah, totally. Probably the best way to get ahold of me is on Twitter. So my username is torch2424, just as a quick, people ask me why? I got to be in it really young when I was like six, Torch was my imaginary friend. And then 24 is my favorite number when my kid Brian was 24, 24 twice. So ...
Jeremy: There you go.
Aaron: Yeah. Hopefully that story helps drive with my name, but yeah, I'm on Twitter most of the time. Yeah, probably reach out to me on Twitter, probably the best. I'm trying to think. If you like ...
Jeremy: I've got your LinkedIn here, I've got your GitHub which is torch2424 as well, check out Fastly.com and everything that your team is working on over there. And then I think, yeah, you mentioned The Bytecode Alliance too, right? So that's just bytecodealliance.org. Probably some great information there and then I'll get everything else in the show notes so people can check this stuff out. Give them some weekend reading to do, but thanks again, Aaron. I really appreciate it.
Aaron: Yeah. Thank you very much for having me. I super appreciate it. And yeah, looking forward to keeping in touch and things.