 Here's a web UI framework for building rich interactive web UI using just .NET. Blazor WebAssembly apps run directly in the browser using a WebAssembly-based .NET runtime. Blazor is pretty clever and efficient with how it handles component rendering and UI updates. However, the WebAssembly support in browsers doesn't yet support .NET JIT compilation like you would get on the server or in a native desktop application. .NET compilation takes your code and at runtime compiles it to native instructions for much better performance. Because of this limitation of WebAssembly in browsers, the .NET runtime is limited to .NET IL interpretation. This means that certain CPU-intensive .NET code can run a bit slower on WebAssembly. In .NET 6, we're addressing this by adding support for WebAssembly ahead-of-time compilation, or AOT compilation. AOT compilation compiles your .NET code directly to WebAssembly as part of publishing your app. Your .NET code then runs directly in the browser as WebAssembly for much better performance. Now when you AOT compile your .NET code to WebAssembly, it does get a bit bigger than the original .NET assemblies. It's about two times larger, so you are trading off some load time performance for much better runtime performance. Whether this will make sense for your particular app will depend on your specific requirements. For many apps, the existing .NET interpreter-based runtime, combined with the laser's efficient component rendering, is more than adequate. Hey everybody, it's me, Jay Gordon. I love those little videos. They're really so great. You get a really great opportunity to hear from people right on the dev team who are building these things with Web, or actually building WebAssembly support with Blazor, and really talking about how to make these products work the best alongside your development cycle. So, hey, welcome back to Azure FunBytes. My name is Jay Gordon. I'm so glad to be here with you. Thank you very much to the IT OPS Talk community where we're streaming now. Happy to be saying hello to you all. And more than anything, I really hope you had a great Thanksgiving that was last week. It's why we were not on the air. It was a great opportunity to spend some time with family, enjoy some quiet time. And for those of you who are in other parts of the world, at least you got quiet days from us over here in the States. So I hope you enjoyed that. So anyhow, this week on Azure FunBytes, we're going to be talking about WebAssembly and to help me do this. I'm bringing back someone who's done the show with me a few times, none other than Steve Moroski. Hey Steve, how are you today? Doing well, Jay. How about yourself? I'm doing great. I'm really glad to have you here. It's always been so, so wonderful to have these conversations with you. Because I think that we come from a place that's not too far off as far as our love for IT operations and how infrastructure is built and how to keep things moving along with an organization. So thanks again, Stephen. Oh yeah, my pleasure. We have some similar background there. My career though, it's kind of twisted and turned a little bit and I've dipped into the development side of time or two and that brings us back to kind of what we get to talk about today. And I like the little one minute video you had to kind of kick things off with Blazer and WebAssembly and I think it sets us up well for the conversation we're going to have. Great. So before we get into that, I'd like to ask you, because I've asked you how you got here, you know, I've asked you about your background before. So I want to ask you, what have you been working on lately that really excites you? We had a little bit of a little bit of a reorg in our environment and I moved to working on our cloud native team. And the project I got to kind of jump into is WebAssembly and where that lives in this cloud native world. And so I've really been on an exploration over the last month or so kind of diving in looking at some of the different ways that you can host WebAssembly. Some of the different ways that you can build and interact with these things. And it's really been just dipping my toes into this world where we take WebAssembly and just like the video was talking about running it in the browser. How do we run it out of the browser? Just like we had the conversation about, well, we didn't directly, but in the industry, we had JavaScript that was really popular in the browser. I was like, oh, well, let's do server side apps with this thing too. And so we took the Node.js route and we could build CLIs, we could build server side utilities, all sorts of fun stuff. Well, WebAssembly is kind of going that path as well. It's like, how do we get more performance in the browser? Well, that's what drove the idea of WebAssembly. How do we get secure and performant? Well, secure and performant, that's a pretty good idea outside the browser as well. We're taking this WebAssembly idea of this compact, low level language with a binary format that's intended for running in a sandbox in the browser. Let's bring that sandbox out and run it in different places. Sure. I hear assembly and I think a lot about old assembly language for actual low level programming. For that most basic of programming that we think about. I've looked at how this is close to being like assembler in just the concept. Obviously syntax and utilization differ. I know that it's supposed to provide you with just like a low level programming language to do things that are manipulated in the browser and also to add some cross compatibility. But we'll get to that. I want to ask you for your definition, but before we do that, I just want to give everybody a little bit of information. One, if you can, please, please, please take our poll this week. Every week we get together and I have a poll. So if you go to aka.ms slash splitter TV, you can answer, have you worked with WebAssembly yet? I'd love to know, Stephen and I would just like to get an idea of what your experience has been. We want to remind you to send your questions into the chat. We definitely want to hear from you. And then, of course, there's really just a great education available for Microsoft learn. If you go to aka.ms slash learn, you'll be able to find a ton of spectacular learning modules on all these different types of subjects. Here's one. Publish a blazer WebAssembly app and dot net API with Azure static web apps of great service. And we're going to be doing a really good Azure FunBytes on that with one of the latest Simona and then having Anthony back as well. So that should be great. So I've kind of set everybody up today with what we're going to be talking about. And I'd love to first start, Stephen, by answering, I guess, the question that we get started at with is, what is WebAssembly? Yeah, and I think, you know, we talked about this just a little bit already, but you know, it's that really it's at low level language. There's a binary format and a text format, and it was designed to run in the browser and actually we'll take a look at we'll build a little WebAssembly app. And using some of the tools in Visual Studio Code, we can take a look at that text representation and it will look a lot like assembly language for, you know, pick your processor. Now, one of the cool things about WebAssembly, right, is it is this really low level compact, compact thing that we generate. However, how we get to it, we can use a lot of the length programming languages and libraries and things that we've come to know and love. Right. And I think the coming AOT stuff that was mentioned with Blazor is going to help Blazor play in this, in this other realm that we're going to be talking about today. But you can use things like Rust, Go. There's, I think, Swift, there's like 10 or 11, actually C or C++ will work, and you can compile into WebAssembly. There's like 10 or 11 languages, maybe 13. And it's the WebAssembly reference sites that we're going to have in the show notes will point you in the direction of those. I'm going to show off a little Rust because I like Rust and that's what I've been playing with lately. But you can use these languages that you have experience with that have an existing package system that have, you know, that you have all of this capability with. But now we can compile it down regardless of what platform we're on into a binary format that can run just about anywhere. And that's always really important. And so we've got some of the main concepts of what the basic outcome is that they've tried to put together. And so one, it's creating something that's efficient and fast. I see it's referring to a stack machine. Have you dove into what stack machines are? No, I haven't. One of the things in part of my exploration to this is kind of boning up on some of those computer science-y things that I didn't get by not going that route in college. Sure, sure. I went to kind of go to class sometimes and then drop out later, route in college. Hey! There's a little bit of catch up I'm trying to do. Sure. I mean, ultimately the thing is, so JavaScript gets, you know, it has to go through this like interpretation process. And so there's a little bit of overhead as that runs in your browser. WebAssembly is designed to provide a much shorter route to getting to execution inside that sandbox environment. And that's what helps you get to that kind of efficient and fast. And then safe because it's architected to have this sandbox around it. And we talk about sandboxes in all sorts of different places, but the WebAssembly sandbox and runtime is actually very, very tight, right? And so what we're going to look at later is a particular runtime that the things that your WebAssembly code can see and can access. You have to be very explicit about what you make available, you know, whether it's file system paths or so. But I'm getting a little ahead of myself. Sure, sure. We'll move along, but let's take a look quickly some of the high level goals from the WebAssembly documentation. It's defined a portable size and load time efficient binary format, just like you were saying, Steve, for execution to serve as a compilation topic. But Target, we want to specify and implement incrementally a minimum viable product. There are additional features like threads, zero cost exceptions. We want to design to execute within and integrate well with existing web platform. There's so much that people have already put together that cross compatibility is super important. Design to support non browser embeddings and to make a great platform. And I think that a lot of communities strive to do that first is to build a platform that people feel comfortable with that they find is easy for them to implement. And so the next question, Steven, that I have for you. So we've covered what assembly WebAssembly is, is why would I use WebAssembly? Yeah. And so right now, there's not a ton of places that you can use WebAssembly outside the browser, but we're starting to see more. One use case that we see, you know, people interested in is moving compute to the edge, right? Because this is this lightweight compact runtime, it runs really well at the edge on IoT devices on hardware constrained devices. If you want to stack multiple or if you really want to take advantage of the compute that you have WebAssembly, you know, running multiple instances of a WebAssembly application is vastly more performant than, for example, a full container, or even which is, you know, of course more performant than running a separate VM for something. So, you know, there's a, there's definitely going to be a place for WebAssembly in kind of in this cloud native future, right? And whether it's at the edge, whether it's server side, but it's evolving. And so right now, what I would mainly encourage folks to do is really just kind of get an idea of what's possible, play around a little bit, and be prepared for when this ecosystem matures. You know, there's, I mean, we're already pushing out some features in Azure to take better advantage of WebAssembly, which we'll get to as well. And the earlier you start playing, the earlier you can start having feedback into your vendors who are providing some of these platforms into the open source projects and communities that are building these things and even come in and participate and contribute, whether it's documentation, whether it might be some code, or just start contributing to the ecosystem of what's available in terms of samples, projects, get up, just kind of get out there and play around. And the earlier you're in this community, the earlier you have a chance to influence the way it goes, whether for everybody or just for the organization that you work with, right? So, such a common trait of open source projects is that the people who actually show up early and often for that matter end up becoming big influencers of the direction of these projects. We've seen it, especially in like the Kubernetes world, where the people who came on pretty early really helped lead the direction of where the project was going, and then kind of left it up to the community to then make good choices to add features, to improve features. And that's just like a common trait of open source and how the community can work together to improve products. And so, we've talked about why I would use it. And I brought up some use cases, and one of those use cases was outside the browser. And so, where can I use WebAssembly outside the browser? And I've got some of those examples here at the bottom, but if you want to talk to those even, please feel free. Yeah, and if you want, we can even go jump into some code and start using it outside the browser. Yeah, sure. Let's give it a shot. So, all right, cool. All right, so what we're going to first thing we're going to look at is we're going to actually build a little WebAssembly project. And we're going to run it right here on my local machine. I'm running Windows 11. Again, it's a cross-platform runtime. So, hey, there's an opportunity to run this thing or run these type of things wherever. Now, we're going to build a little project in Rust. Let's open up some code. Oh, that's interesting. So my local screen, I don't see the thing open, but I do see it reflected in the screen share. So that's cool. So let's go to main. Wow, this is really weird. Do you want me to give you a second? You know, I think, I think I know what might be going on. Let me make that natural screen. Sure, I'll give you a second and just want to remind everybody. Oh, here we go. Just remind everybody while we're at it, like make sure you take the poll. Have you worked with WebAssembly yet? Go over to aka.ms/. And you can give us whether or not you've actually used this technology. Are we preaching to the choir here or are you learning something brand new? So head over there and take a look. And if you have questions, please put them in the chat now. We would love to hear from you. We really appreciate our community. All right, Steven, I'm going to bring you back right now. Now I was able to see things and working all right. So here's the deal. We've got a really, really simple Rust program, which is almost human readable. And we're going to build this and we're going to run it in a Wazzy runtime. So Wazzy is a WebAssembly system interface. So this is a standard that is being debated right now. They've coalesced around how to access things like file system resources and some other core operating system type features. So this is the gateway that it has to operating against a particular computer. They're still trying to come together around what does networking look like. So there's definitely some limitations in running in this WebAssembly sandbox. But again, it's an evolving story. And if you want to weigh in on that evolving story, now's the time to start looking at it. So we're going to build this. And so the build command in Rust here, I'm going to use cargo build. We'll build to release. Actually, we'll just build target. So I'm going to tell what platform to build for. So normally it would build for my Windows system. I'm going to tell it to build for the Wazum32 Wazzy build target. That's going to help see the change in the directory with the actual source for your application. Now let's try it. All right. So we compiled FunBytes. And if we go take a look at target.wazum. So we got a couple of files that were created here. The actual binary that we built here is this FunBytes.wazum. Now I told you that we'd be able to actually go take a look at what the text will represent. This is a binary file here. Visual Studio Code has an extension from the WebAssembly working group that lets, that gives you some additional capabilities. So we'll take a look. If we go look at our Wazum file here, there is save as WebAssembly text file. And so we're just going to save that. FunBytes.wazum. And take a look at that. Sounds good. So, you know how you were saying, you know, when you hear WebAssembly, you start thinking of assembly? Yeah. This is the type of thing you start thinking of, right? And, you know, you've got stuff here. This is the textual representation of the binary that we just built. And many of the runtimes offer capability to run either the textual version or the binary version. So let's just see what that looks like sidewise. So, I mean, the textual version is even smaller than the binary, which is kind of interesting. But all right. So we built the file. That's kind of interesting. But how do we actually run it locally, right? What's going to run it for us? And that's going to be this project called WazumTime. And WazumTime is a implementation of the Wazzy standard. It's a Wazum runtime. That's how I got the name WazumTime. And so we can actually go and run with WazumTime and point to our Wazum assembly. And it will execute our content. And for those who are wondering, Wazzy stands for WebAssembly System Interface. And it's an API designed by the WazumTime project that provides access to operating system like features, like files, file systems, Berkeley sockets, clocks, random numbers. And the socket support is still provisional yet. I mean, they're still kind of working on that. But that should be coming together as soon as I hopefully. All right. So now what we've done is we've taken, we've executed, we've executed our little code here, our little snippet of code. Now, the reason I've got this content type and Hello World here, that comes into, okay, where, when I want to host this, where am I going to host this? And so one of the things that's, one of the platforms that we're building off of is because we don't have that socket support, I can't create like a TCP listener in my WebAssembly runtime. So I can't listen for requests coming in. So I need something to proxy those requests in. Now, Jay, I know you're familiar with this, but do you remember, do you remember in the days where we would run some of the early websites on Apache and we'd have CGI handlers? Yes, very much so. So we have a CGI type. Yeah, making directories executable and the biaries within them, sure. So the CGI, so there's a standard for CGI, common gateway interface, that defines how an incoming web request gets passed on to some executable. And Waggy is the WebAssembly gateway interface and it follows the CGI standard and proxies those requests in, as it acts as the HTTP handler and then passes in that content to your WebAssembly runtime and then whatever standard output becomes the response. And there's a lot of cool stuff you can do with that. We're going to start out super basic and then kind of move forward there. Now Waggy, in and of itself, you can run Waggy locally. It's a project you can get the binaries, you can build it locally. However, it gets more interesting when it's integrated with things. So the first thing that we're going to look at is Hippo. Hippo was designed as a platform as a service to host WebAssembly runtimes. And so it uses Waggy to provide a sandbox, secure, performant runtime, and Hippo provides some of the developer experience around it. And those are from our friends over at Days, if I'm correct. Yes. They worked on that project. They'll have a link to the open source repo on the show notes after. Yep. So now I'm going to pop over into, so in this repo that we're working in, and this is a public repo and we'll put it in show notes or share it out. Yep. Right here, everybody, github.com. Yes. Funbytes. It'll be in the show notes, but here it is for you right now if you want to take a look. So in here I've got a provisioning folder and I have a little PowerShell script that I put together that helps stand up a new Hippo dev environment. And so we can kick that off. Let's do, so what I will do is I'm going to give it a resource group name and a VM name. So it's going to spin up a Linux VM and supply a cloud init file to that so that that will provision the developer tools that we need. It will provision Bindle, which is an artifact repository that Hippo will use, and it'll set up Hippo and it's going to run those things as services for us. Now we don't have to wait for this thing to happen because just like on your cooking shows, I already stood one up and we've got one that we can go to. You baked the cake already and now you're going to pull it out of the not warm oven just to be able to show. Yep, exactly. But before we get there, I did also want to show that part of this provisioning process, there's a couple of bicep files, which I don't think it copied down for me. So let's, in that, in my repo. Yeah, your Dockerfile. Yeah, so there are a couple of bicep files that spin this thing up, but the main thing is this VM bicep file and just, you know, we have a Ubuntu server and it spins up our storage account or IP addresses, but it maps in the security group. It's going to open up some ports for the two services that we care about so that we could work either locally on this VM, because the VM will be provisioned with all of the tools that you need to do this, or if you have them locally and you'd rather work on your local machine, you can do that. So we could actually connect to that machine with like VS Code Remote and get a local Dev experience, get the best of both of those worlds, where I do all my development remotely, put my code editor and all my testing is local because we could proxy things through. And that's the approach that I took in the blog post series that kind of led to this. But today we're going to just work locally on this machine. And we're going to go and create a new project from source, or from kind of from scratch here. And let's go to the source directory. Yeah, I was doing a live demo yesterday. And the one thing I can always say that's the most frustrating part about live demos is when you're like, you paste something in or you do a line and you just know it's off by one little thing. And you're just like, like earlier before when you meant to do something within a specific directory and just forget happens. We'll create a new directory, FunBytes Live. And the easiest way to kind of get started with the WebAssembly and these different platforms is using a code generator. So if you're not familiar with Yeoman, Yeoman is a way to generate out some projects. You can mix in some API calls. We're going to use Yeoman to help us set up our Hippo app. And actually it will also help us set up the environment on our Hippo server. So before we get too far from that, I'm just going to show you our Hippo server. So I've already said there is when you spin it up, you have to register an account. I've already done that, but you give it a username, email, password, confirm that. And this is a local or is this from a remote host? This is running in Azure on a VM that I spun up. Gotcha. And I put a nice friendly URL on it for myself. It is using a development cert because this environment is going to go away when we're done talking today. Yeah, let's see. So I've already went through and spun up that FunBytes app that we showed earlier that we ran with Lazm time. I've actually already deployed that into here. We're going to create a brand new one. But what we're going to end up creating is on this dashboard here, we're going to see another, we'll see FunBytes live. And it's going to create three environments for us. Canary, a latest release in a development environment. And then we'll be able to push our app into our development environment and see what that looks like. Now right now, that app that we ran before, let's make that bigger. Hello world. Right? That's the text that we had output. And the content type that came back was the headers. Because it was separated by a space, which is part of the CGI standard, where you can give it your headers and status and everything like that. And then you give it your content. And so that's just the body that we returned. We'll make ours more interesting. Sure. All right. So let's get ahead and let's get to that. Now I want to set up some environment variables that make it easier. It's a few less questions that I have to ask. And so I'm setting up a HIPAA URL, a HIPAA username, my password. And then because we're talking to DevCerts, the global agent force, global agent thing, lets me talk to a development certificate. But let's start out. We're just going to do yo-las. Now this is going to walk us through. It's going to ask us some questions. Some of the defaults will be set. Now my shirt says don't accept the defaults. We're going to take some of the defaults because I used environment variables to set those defaults. But for some reason, yo has been really slow on my machine lately. And yo is a binary that you can install whether you're using PowerShell like you are. You can use it within a bash shell. Any way that you... It's very, very cross-platform ready. Yeah. It's a Node.js app actually. So you can just do npm install, npm install yo-g. You want to make it available, you know, wherever. And then the generator wasm is an extension to that. There we go. All right. So the first question that it asked me was, what's the name of my module? And it defaults to the name of the folder that it's running in. The directory that's running in. Then it asks what type of application do we want? Do we want a console or batch job? We want a web service or web application using Waggy. It's a web application author. It pulls from your environment. Now, programming language. Selection of what programming language you want to use. And I know you say you really are digging Rust lately. I am. So we're going to continue on with Rust. And where are we going to publish this thing to? So Hippo, which we're going to look at, has its deployment mechanism. So what we're going to look at later, or hopefully we'll get a chance to dig into is crosslet. And crosslet in Azure. Runs in, in AKS node pools. And so we could deploy into Azure container registry is no CI artifact to have that pulled as part of that. So we're going to go to Hippo first. So it picked up from my environment variables. Where my Hippo service or services running. And I would like to create a Hippo app. So it's going to go talk to the API of my Hippo server. And set up those environments that I mentioned. And then what storage ID. What I like. And then the domain. So what it does for the domain is it defaults to the name of your project. And then the name of where your Hippo server is running. It takes, it takes the. It takes that first subdomain off and then adds your, adds the rest of that domain on. And that's fine because I've already set up the DNS. To handle that for us. And then. My Hippo user names admin. My password. And now just created a bunch of files. For me. For my project. So it basically creates this little hello world. Project. It sets up some VS code stuff for us. As well as creating a GitHub. Actions workflows. For us. So that we could. Go right into GitHub and start doing automated CI CD. From. From the project. And then give us some instructions. And if you want to do deployments to. Azure you can just configure a service principle. Have that part and then. Have it part of that Azure log in portion. Of your workflow file. Yep, exactly. So in this case we're going to, we're going to Hippo and Bindle. So we don't have to go that particular route. But let's take a look at our. Code and we're going to, we're going to make a change to that. Typical hello, hello world that we have. So we got some bites live. Let's change. This to. HTML. And we'll. Make this one. So we're just modifying now what the content type is. That's going to be parsed and then. Just adding some tags. To make it so that we can have some style on it. Yeah. And. And we could do, I mean, you can return. All sorts of stuff and. In our next iteration. I want to show you some of the environment things that are available. And then what it looks like to take input. Into this world. Because it, because the way this behaves. Is very similar to how it's going to behave in. Crustlet in node pools. So, yeah. So there's a similarity and experience there. So. Now that we've got that. I can. Build my. Component, just like I would normally. Or just like I would do before. I could run it locally if I want to see what, what's going to happen. With wasm time. Nope. Helps if I give it the right URL. Release. There we go. So we've got our. No, it's going to be a clear shot at it. All right. So we get our content type coming back and then our content body. Now to. To push this. I'm going to go ahead and go to the. Hippo CLI. Okay. Which I don't have on my path, so I had to go. Grab the path to it. We're going to tell it hippo push. Dash K for insecure because I've got. My dad certs. And to push locally here now. It knows where to look for the file. Because of this hippo facts. Thing that was scaffolded down. It was kind of like a state file, if you will. Yep. And so it's going to. So it knows kind of where. To look for. The artifact to push. And. In the, you know, in here, I could specify other files. If I needed to send some like images and stuff along with. I could, I could add that kind of stuff there. We're going to keep this nice and simple. So I'm going to push that. All right. So we got phone bikes. Excuse me. Fund by slide pushed. Let's see what our hippo environment looks like now. Sure. Let's go back to the main dashboard. Here we have fun bites live. Now I glossed over this environment thing pretty quickly. We can go in here and edit. Just to see. I can supply specific environment variables. I can adjust. The domain name that. I can do that. The host header that's looking for. And we can specify a version of artifacts to look for. To auto deploy or to lock the particular deployments. We don't have to mess with any of that just yet. But. We're going to go and take a look at CR deployment here. Sure. I will accept the fact that I'm going to insecure. Site. And there's our. And so we can see that. Hey. We've got. We've pushed new code. It landed on our hippo server. Great. But. Writing out text. We could, you know, we're writing out, you know, some simple HTML. You can do that in a lot of ways. You know, what makes. You know, You know, What are some of the different things that we have available to us? Or how do we access some of the information to make, make our environment. More active. More responsive. Well. We want, we may want to. You know, see what's what type of environment variables are available to us. Sure. Right. And so let's. Go and. Our main file here and. Change up. Our body. I'm like a standard text. Sure. A little bit more. Text. But I'm going to use. A. Standard library in rust. To access the environment. And it's going to read the environment variables as my run time sees it. I'm going to change up. Our body. I'm like a standard text. To access my run time sees it and print them out on a page for us. So we just need to. Build that. And then we can hippo push it. So does it handle that semantic versioning there for you? Yeah, so it, so it's always creating some, it's taking the timestamp. And adding that to what you're pushing. And then there's a version number that you can set. Inside your hippo fax file. Gotcha. So you're keeping track of that along the way. Yep. So now we can refresh this. And we can see. A dump of all of the. Of all the environment and we can see a lot of the HTTP headers and stuff. That we would normally that we might want to get access to. As part of our determination of what to do. Right. Now, here's where we would see. Let's see. I should have told this thing to sort. So, so if there's a query string, you know, we get that in there. But what about a post body? Well, according to convention for CGI processes. That if there's a post body, that's treated as a standard in. So what would that look like? Let's. Go back here and. We can add in a little bit of. Code. To help us see our standard in two. So what we're doing now is we're going to use another standard library. Okay. I'm going to import standard in. This provides us some nice convenience methods for. Working with. Working with standard in so I can get it as like an array of lines and I can iterate over over it. So we can do that. Let's. Build that and publish that. Publish it. And now I'm instead of going to my browser because I know we've gotten update there. I'm going to use. The HTTP are the rest. The rest extension in VS code. And we can we can actually test that API out. Right from within our. Right from within our visual studio code instance here. Let's bring that down to get a little more space. And we'll post up to. Our environment here. And we can see that we get back. Our text plane. Here's our standard in. This is what we get reading back to us here. It didn't take content type the way it was. There we go. Let's try. Sure. There we go. Now our standard in is just the body of content that fake content that we that we submitted. We can see. That should tell us our HTTP content type header is set to what we set it to here. So it's application JSON application JSON. And we can continue on could do different things here we could you know I could submit some YAML all sorts of fun stuff right we could do. We could do much more complex things but this is one way that I can go and test my test my APIs. And this is one of this is how we because we don't have a great right now we don't there's not like a great live debugging experience. This kind of print line debugging. This is when I first learned a program this is kind of how I learned to figure out what was going on is like I got some information and I printed it out to the console. This is kind of that you know we're kind of back to that experience until the DevTools ecosystem kind of catches up with where we want to be. So all right so we can see where we can see where we can take in the post body. We can see where we can set some headers and things I could in my response I could set different headers here I could set status codes I could set redirects right we can there's all sorts of controls that we can have here I can send back error codes you know all the standard stuff that we would want to do in responding in a kind of a webby way for working with this you know within the waggy way of working in the way of handling and working with WebAssembly. Now once we get socket support that's going to that's going to open up a lot more doors towards how we can handle content and things but for now this is it's a pretty interesting way to start playing with things and I've been having fun. So we've got about 10 minutes left a little less and I was curious if you wanted to talk a little bit about the crosslet project and how that kind of fits into this story. Yeah so great definitely so the so crosslet is a project that that exists. It acts like a cooblet and so if you're not familiar with the cooblet is that is it's a it's a way that we can interact with with Kubernetes of Kubernetes is exists to schedule jobs and this cool it will listen listen so crosslet will listen for jobs of a particular type. So it looks for jobs that are that are specific that specify the architecture of wasm 32 wazzy. So just like the way just like what we compiled our application down to. And it will run those workloads in a wasm run wasm time runtime rather than a container runtime. So we can use Kubernetes to to run our WebAssembly workloads. Now there's actually a great great doc in on Microsoft docs on how to kind of go through and set up. Set up the node pools and so. In my repo I've actually got a nice little. Provisioning script. That I've gone through and and done ahead of time. For us and we just. The simplest way to kind of get started and start playing around with this is to create a resource group. Create your AKS cluster and then we're going to add a node pool. And this requires the AKS preview. Extension to the Azure CLI and the docs call that out. Mm hmm. But we need to give it this workload runtime. Jump back as workload runtime of wasm wazzy. And what that's going to do is it's going to spin up a node. It's going to spit up a node because I specified one. That's going to. Offer that's going to use crosslet. To offer. Wasm wazzy runtime workers. To be scheduled by Kubernetes. Now what are we going to deploy there? Well. Because we're in Kubernetes, it's time for some Yannol. So. So I have a pod definition here and this isn't the repo as well. And it's a little bit modified from the demo that is in docs. Not much, but a little bit. And this is a preview feature, right? So this is not something to move all of your production stuff over to. But it is there to try out and to experiment with and it is. It is early, right? You can see from some of the annotations, you know, alpha across like them, right? Like. The experience is still getting sorted out here. And. And I'll be, I'll be honest. I was playing with this yesterday. And about 50% of the time I failed to make this thing work. I had some challenges with authenticated repos. A lot of this is operator error because this is new. This is new for me. But it's also a preview feature. And so there are definitely rough edges. So what we have here in our pod definition. We have, we set some annotations. And so that's information that's going to get passed down to the crosslet runtime. So that it knows some information to listen to. So this is going to set it up to listen on. So unlike. Unlike containers where each node gets its own IP address the way. The way the waggy runtime in crosslet will work. Is on the node that's running. It's going to listen at the port. And then it will use. This module set up here. And map routes. Back to the individual handlers. So it's a little different than how you would do. Then how you would. Then the experience you'd have using a container. Inside Kubernetes. And one of the things that I'm hoping to be able to do. Over the coming weeks. Is kind of look at, okay, how does this experience work with existing within, you know, how would you, how would you bring this into. An existing environment or what, what are the scenarios that you'd like to use. This type of, a type of experience way. But. The way we can get it going now. Here's, we're going to listen that to the, at the host level. And provided that a certain port. We set some, we said some handlers back. We can set some options like. We need to allow certain, you know, host header set some allowed hosts back. But most mostly we're defining some routes. And the names that we're assigned to these. Are the names. That we specify to our containers. Container. Yeah. The container images with all the binary. Or runtimes I would imagine. But they're not actually container images. They're OCI images. Right. But they are. They're taking advantage of. Like the unsupported package type thing where you can. Pretty much you're pretty much creating a manifest of what you. Of what you want. What you want to contain and packaging up in a standard way. So that it knows how to pull the thing. So it, and we can store it in. Like a repo. Bicep uses a similar mechanism to. For modules. Right. So we have a number of these. Container images, which are really. Wasm modules. Specified. And so in addition to the ones for the. For the, for the actual for the demo. I included this wasm test one. The one I built, I was working on. And I added it in a route for fun bites. And so we've got a Kubernetes note. Now we set some. Tolerations on this. And these are the things that help us find. The nodes that support wasm runtimes. And so we want to look for. An architecture of. Wasm 32 waggy. And, and, and look for no schedule and no execute. Effects. Right. So we want to, we want to find these things there. Network available. It's got a network. Otherwise. What's the point here? But. With this pod specification, then. We can apply that. It's going to spin up all those, all those services. We have an engine X. Service. That's listening and proxy and connections back. And so we can go. And let's get. We got about a little, little more than a little less than two minutes left to go before we got to say goodbye. Not to rush it. Okay. No problem. Cuttle. Let's get. Grab the right coop cuddle command here. So I'm going to take a look for the. URL that are the IP that my Kubernetes coast is listening on. Mm hmm. And we will go there in our browser. That's a default. That's the default route. And then we can go to the fun bites. Route. And we've got that right. So, um, you know, so that is our, you know, that's our waggy experience, but running in Kubernetes in Azure Kubernetes service in, in Azure. So it looks like. Sorry, Steve. I was just going to say, you know, if we want to see what that looks like. Coupe cuddle. Scribe. So the pod that we're running. Has all our container images. It shows that we're running. It shows all the annotations that we provided. So it's pretty much the same as the YAML file I was showing you before, other than it's got some statuses now. And but yeah. Well, well, Stephen, we're just about out of time. I wanted to say thank you so much for giving me all this information this week on WebAssembly. Most of you haven't really used it yet. But it's okay. Is it 89% of you said you just haven't worked with it yet, but that's okay because this is an opportunity for you to get started just like Stephen did. So Stephen, where can people find you online if they want to get in touch with you about it? So I am Stephen Moroski on Twitter as, as it shows right up on the screen here. It's probably the best way to get a hold of me. Like LinkedIn and things under my name. Otherwise, leave comments or issues on the repo if you're, if you're trying or comments in the blog posts. So if you're looking to get started, I would start there. I go into a little bit more elaboration than what we were able to do today, but that's where I would start. Well, Stephen, thank you so much for being here. I really appreciated your time and I am looking forward to the next time we can get together and talk about something that's really cool with Azure. Until then, why don't we give everybody the good big wave. Goodbye. We'll see you all next time. Thanks a lot, everybody for watching. We really appreciate it. Have a good one. Take care of each other.