0:36 Introduction to Suborbital and Guest

0:36 Hello, and welcome to today's episode of Rawkode live. I am your host, Rawkode. Today, we're gonna be taking a look at Suborbital, a platform from running web assembly applications. And I am joined today by the creator, Connor Hicks. Hey, Connor. How are you? I'm doing well. How are you? Yes. Very well. Thank you. Not too bad. Not too bad at all. I know it's early for you. So thank you very much for taking the time out of your day and and joining us today. My pleasure. So I gave a very brief introduction to what Suborbital is. It's a platform for running web

1:14 assembly applications. And do you wanna just give us a little bit of more flavor on that? And I I believe you've got some slides to help us through that as well. I sure do. Let's try to get this up and running here. Yeah. So I will start sharing those and then I'll give you a little bit more information. Yeah. And I was really rude. And like I said in that little intro video there, I I always mess up the intro. I forgot to even ask you to introduce yourself. Do you wanna give us a little bit

1:20 What is Suborbital (Presentation)

1:42 about you as well, You know what? That's the second slide, so we can just go right into that. Oh, perfect. There you go. Alright. Yeah. So hi. My name is Connor Hicks. I by day, I work for one password. I lead a team called platform, product discovery, I should say. We do research and development, for new products. And, for the last year or so, I've been working on Suborbital. And Suborbital's, goal is to allow building web services, APIs using, functions that are compiled to WebAssembly. And so, you know, it's been there's been several iterations of the project.

2:31 Originally, it actually used Docker, to facilitate, you know, the the actual running of the functions. But about a year ago, I I decided that it just wasn't it it wasn't working the way that I wanted it to. Everything was overcomplicated. There were components that I didn't like how they were designed. So I decided to pivot, if you will, and and switch to WebAssembly. So I'll back up for a second and talk about the actual problem that a developer is facing that, you know, I'm actually trying to solve here regardless of the technology being used. And it's really that, you know,

3:09 The Need for Simplicity

3:11 building web services has gotten more and more complex over the last couple of years, right, the last ten years even. Everything is microservices or, you know, having to string together these these complicated serverless platforms. And I'm I'm really having a focus on simplicity. The the actual the tagline for Suborbital is build web services that are powerful but never complicated. That's kind of the the the line that I've been using. And so I really want to make it easier to get a production web service up and running with with a lot, you know, less fuss. So,

4:02 actually, there's the tagline. So, yeah, I am building for a future based on WebAssembly. I've been coming up with this thing called the SUFA design pattern, that stands for simple unified function based applications. And I can go through a bit more of what that's all about a little later, but the the basic idea is, let's make it easy to deploy, make it so that you only have to deploy one thing, you know, unified function based because I think that's a great paradigm. And then, application meaning having a very specific meaning of it is one program

4:08 The SUFA Design Pattern

4:41 that is serving your entire application. You don't have multiple services that are serving the same thing. You can segment your application logic using the functions rather than using individual services. And one of my goals is to really embrace the edge computing movement that's been that's been going on. Things like Cloudflare Workers and and Fastly ComputeEdge, they're starting to take advantage of WebAssembly on the edge. I do think that there's, you know, another couple steps further that we can take to really take advantage of that, and I'll talk about, you know, how later. And then one of the founding,

5:23 like, principles of just me as a developer is that make make libraries and and and frameworks and such hard to use wrong. Right? There are lots of things that you can you know, there's a lot of libraries that you can get that you can configure every single little nut and bolts down in the guts of the system. And sometimes you can shoot yourself in the foot with that because the maintainer, you know, allowed you to configure something that you shouldn't have been able to configure, and you can, you know, introduce security vulnerabilities or whatever by by misconfiguring something. So it's one

5:58 of the one of the big goals to make that hard to do. So Suborbital is actually a family of projects. The the main one, the one that we're gonna talk about most today is ATMO. It's kind of the the batteries included project, if you will. It has, all of the, the WebAssembly runtime. All of the all of the three projects you see at the bottom are put together to form ATMO, kinda like the Voltron robot. So there's there's Hive, which is a a job scheduler or a function scheduler. And this is where the WebAssembly, you know,

6:02 Suborbital Project Family (ATMO, Hive, Vector, Grav)

6:39 the main parts happen are in the the job scheduler. It uses Wasmr under the hood to, to run WebAssembly modules. But what Hive does is it actually makes it multitenant, and it manages the execution and memory and communication of many, many, many modules all at once. And so that's kind of the core of ATMO. It can be all three of these building blocks, if you will, they can be used on their own if you wish. But Atmo is kind of the plug and play all in one. You don't need to do anything yourself get it up and running.

7:24 And then Vector is is a is an API framework for Go. It does, you know, just make it a little bit easier to build, API servers. It's it's something that I built for myself, and for, you know, just making it, quicker to bootstrap a Go web service without all the boilerplate that you normally need. And then Grav is, it's my kinda my my favorite little project of the bunch. It's a distributed I call it a messaging mesh. So you can think of it like a message bus, kind of like Kafka, but it is completely decentralized.

8:03 It takes plug ins for transport and and node discovery. So, anybody could write a plug in to, you know, use a particular transport, a particular protocol, or whatever to, to do the messaging. But it is really designed to allow, scaling up, you know, large groups of instances to to communicate asynchronously with one another. So I just wanted to quickly touch on WebAssembly itself and say, you know, there's been a pretty big movement coming up, over the last little while, for WebAssembly, not just in the web browser, but also in more of a server side context.

8:30 WebAssembly on the Server Side

8:46 And I've got a couple of examples here. You know, the the founder of Docker, this is a quote that anybody working in server side WebAssembly will probably quote at some point in their, in their tenure, which is that, you know, if WASM and Wazee existed in 02/2008, we wouldn't have needed to create Docker. You know, it's it's a pretty good endorsement, I think, from from the, the CEO of Docker. And then, you know, the CNCF, showed WebAssembly as, one of the five technologies to watch in 2021. And there's a whole bunch of open source work being done right now. I'm gonna show

9:22 off a couple of things, today, I think, couple of projects, obviously, including the suborbital projects as well. But things like Crustlet, that's one of my favorite projects. I think it's so cool. They were able to basically emulate a what they call the virtual cubelet, which is tricking Kubernetes not tricking, but plugging into Kubernetes to make it think that you're running regular workloads when really it's running WebAssembly workloads. It was entirely written in Rust. There was a big splash about it a couple of months ago. I think it's pretty cool. So there's lots of projects like that

9:57 that are coming up and making me really believe that WebAssembly is kind of the next the next big thing. And so I'll I'll just close out the slides by saying, you know, I'm I'm looking for anybody who's interested in coming and working on this. It's been mostly just me for the last year or so. People are starting to try it out. People are starting to get really interested in it, but, you know, I'm I am anybody who's interested in coming to help out, I really appreciate it. And, I am running a little survey. I wanna know what people

10:29 want to get out of a WebAssembly, server side framework. So bit.ly/wildinsurvey. It'll take three minutes to fill out, and I'd love to get everyone's feedback. So with that, I think we can get right into it. Awesome. Yeah. Definitely. That was that was really cool. I think, yeah, everyone's gonna quote that Solomon thing at some point I think over the next few years because it's a very powerful statement to say that, you know, what is now become almost a ubiquitous way of running language and runtime agnostic applications on bare metal and virtual machines. The containers wouldn't be needed to put Wasm and

10:46 Getting Started with ATMO

11:15 I mean, it's not hyperbole is it? Like Wasm really does have the potential to change the way that we build applications within the next five to ten years. And Wasi I think It absolutely does. Super exciting as well. I was really disappointed obviously with the Mazzella layoffs last year. It looked like I wasn't sure if Wazi was gonna pull through and then literally just yesterday my calendar bleeped with the invite to the next Wazi meeting and I was like really excited to see that come back to life again. Yeah. Yeah. Absolutely. And the Crustlet project. I think I actually

11:45 wrote an article on that last year as well. Really really cool thing as well. I was so happy when I got that running. And now we get to look at more web assembly stuff. Like it's definitely one of my favorite technologies It's just hovering on that fringe right now of really awesome things. So this is exciting. Yeah. Yeah. And that's something I want everybody to to realize. Like, this this technology is still very, very young. There's there's not, you know, been the the same level of adoption on the server side as it has had on the browser so far.

12:16 But the amount of work that the community is putting into it right now really makes me believe that it is, like you said, in the next five, ten years gonna be a a really big deal. Yeah, definitely. Alright. Thank you for that introduction. That was great. Why don't we get started then? Let's see where it is. Ta da. I have this Suborbital homepage. So we're gonna be taking a look at Atmo. Atmo is the all in one batteries included component of Suborbital. I guess I'm just gonna click get started and we're we're gonna work through.

12:31 Exploring the Documentation & ATMO Goals

12:54 Yes. So this is my like, I just kind of relaunched the documentation for Atmo last weekend. So, you know, we wanted probably one of the first people to be going through it in full. It used to all live in the GitHub repo and now it's got its own its own home. So, yeah, we can hopefully take advantage of it today. Yeah. Yeah. Definitely. Yeah. I don't think these were here the last time I looked. So the first thing I need to So if you can actually pause on the welcome screen, I do wanna point out something at the

13:27 bottom of that page. So this is where we come back to the simplicity part of it. The the three bullet points you see there is really it it sums up the goal for using Atmo is that you you should be able to get up and running with an Atmo application that is I I'm gonna say the word production ready a couple of times throughout the stream, but let's realize that Atmo is still in alpha. So when I say production ready, it will be production ready when Atmo is production ready. So you write these these self contained composable

14:01 functions, and what that means is all the functions you're gonna write are gonna be completely unaware of one another. They are meant to be running in isolation, and they interact with the outside world using the suborbital APIs. And then you we're gonna look at something called the directive, and that's how you build applications with Atmo. And it's a declarative file. And I I'm really excited about this part of it, and I'm excited to show it off because I think it's a really cool way of building web web applications. And then at the end, once we've built

14:36 our functions and our directive, we're gonna end up with something that I call a runnable bundle. And it is a single file that you can then use to deploy your application. And this really goes back to the simple unified function based apps. It really like, those three things is kind of the embodiment of that, and it shows, you know, how we can simplify building web services by taking advantage of the property that WebAssembly gives us. Okay. So is it I like the thing in your slides where you said, you know, kinda hard to mess this up at least from a security perspective.

15:16 Like is that because it's what we were what we're gonna work with is compiled down to web assembly and we're taking advantage of that sandbox environment or is Atmo and the other components bring in an additional layer of security over the top? I think it's both, actually, because the code that's actually handling these API requests, like you said, it is sandboxed. It is it does take advantage of the strong security properties that WebAssembly gives us. But in addition, you know, Atmo is it it uses vector, that API framework, as its, you know, way of of of

15:52 deploying the actual web server, and that has a bunch of security best practices built into it. So that is really the goal of making it hard to screw up. Okay. I'd like to understand. I mean, maybe that will make more sense when we start writing a lot of a code but I'll throw this out and if you think let's just wait and see just feel free to say that. If a request comes in, the first thing it hits is vector, it works out what function has to be called and then it speaks to Atmo or

16:23 and then it runs the web assembly using Wasimer and then you said they're composable. So how does the composition between these functions work? Is is something capturing standard and standard out? I know this has always been a bit of a challenge for WebAssembly runtimes. Do you maybe wanna give me a little insight into that? Yeah. Absolutely. So so, yeah, like I said, Atmo is you can think of it as gluing those three building projects together. So it so Vector receives the request. It then schedules all of the functions that are needed to handle that request in

17:02 the Hive job scheduler. And then, Grav comes in, we'll talk about a little bit later, something called capability groups, which are still experimental, and we won't be able to try them today, unfortunately. But the idea is that individual functions will be able to be executed on different hosts. And the idea behind capability groups is that you can have privileged instances, some of them that have access to sensitive resources, like, say, your access to your payment provider or access to a particular database. And you can have individual functions running on those privileged instances, so that only a sliver of the execution

17:41 for your request is happening on those privileged instances. But because the whole thing is sitting on this message bus, that is completely transparent to the developer. So you don't need to just you don't need to do any logic related to that transfer of execution, but it is happening happening under the covers because the WebAssembly job scheduler and the message bus are all just kind of handling that on your behalf. Okay. I have loads of questions, but I think let's get started first. Let's see how it works in practice and then maybe that'll answer a few of those questions rather than we

18:17 bombard new with lots of trivial newbie stuff. Let's see, we gotta get started. It says here that we need the Suborbital CLI. So Yep. Pop that open. Yeah. For sure. And this is already all right? All the components are? Yeah. That's right. There's some some Rust stuff and some Swift stuff that we'll look at later. But in for the most part, it's all written in Go. So Sorry, Indigo. Yeah. So this is using a really cool I don't know if many people are aware of this, but it's a service called Go Binaries. It will allow you to automatically

18:23 Installing the Suborbital CLI

18:57 build and install any Go tool to your computer even if you don't have a Go runtime or Go toolchain installed. So that's how I'm distributing it. Nice. No. I hadn't seen that before, so that's that's good to know. Yeah. So you should be able to just run Suborbital dash dash help just to make sure we've got it installed properly. There we go. So yeah. So Suborbital is the first kinda component. This is kind of the build tool chain for all of the Suborbital products. And the goal with Subo is that you shouldn't need anything other than Subo and

19:34 Docker. If you want to install the individual language, you know, tools, if you want to install Rust and configure, you know, the WebAssembly targets, you can, and Subor will let you use them. But by default, it will use Docker to build all of your all of your functions. So you can actually rely on it to provide the tool chains if you wish. Alright. We we got into trouble, I'm afraid, from the audience. Pipe into a shell is not a good idea. Yes. I agree. However, live demos, I think it's okay. Yeah. And yeah, it's it's it's gonna be up

20:18 on package managers at some point. That's something that I haven't done in a long time. I need to remind myself of how all those different package managers distribute and whatnot and get some automation going to distribute that properly. But for now, I think it's a it's an okay solution. Yeah. Definitely. I'm I'm okay with it. I I pipe the shelves all the time. I know I shouldn't. So I'm sure there'll be brew packages soon, next derivation shortly after. And that's why, you know, the community can see how cool is to us and actually go and help contribute them too. So thank

20:50 Creating our first project

20:50 you Kelly Jack o six. You've just volunteered to that. Right. Okay. So we've got the CLI and now we need to create a project. So we just do Suborbital create project important API. Alright. I like it. I'll keep the name the same. So that says it's it's downloaded a template. Do you wanna kinda add this? What what's happening there? What's a template? What's a project in this context? Absolutely. So there are several different languages that you can use to build your functions. Currently, we have official support for Rust and Swift and more to come. And so for

21:00 Creating a New Project

21:30 building those different functions and for just structuring the project as a whole, there are a number of templates, for those empty, you know, projects. It's never something that you as the developer would need to care about. They're all just managed automatically, and they're all available in in GitHub as well if you do want to take a look at them. But, really, all it's doing is, copying a, it's downloading a ZIP of a Git repo in the background and then using, the contents of that to to bootstrap these empty things on your machine. Okay. So we get a

22:05 project directory, a lower directory and some source. Let's just pop this open and and code I guess. Yeah. Now because this is web assembly or at least it's compelling down to web assembly, can I use any language that supports web assembly for my my components? So theoretically, yes. However, the the Suborbital API, the library, is required. So you mentioned earlier, like, sometimes we can do input and output using standard in and standard out. That's not what's happening here. We, there there is a full library. You can see at the top there the suborbital, Rust crate

22:51 that is being imported here, and that provides a number of hosts and guest connections. And so all of the functionality is going through that library. So anytime you wanna interact with the outside world, that is happening through these libraries. So, any language that has those APIs implemented and I'll be like, they're very small APIs. It's really just some memory management and some input output stuff. Any WebAssembly compatible language that has a, you know, a library for it will work. It's just that Rust and Swift are the two that have that library so far. Well, I'm not gonna argue. I'm a huge

23:34 The Suborbital Directive (Declarative API)

23:35 fan and advocate of Rust right now. I'm trying to I'm pretty much doing everything in the rewrite in Rust bandwagon. Sure. So before we really hop into the function, I'd love to take a look at that directive dot YAML that's in the root of the project. So this is what I talked about earlier with the declarative web application design. So this is how we're actually gonna string together those functions, and that's this is where the composability comes in. So what we're doing here is we're actually defining the different endpoints that our application will provide, and then we are composing functions to handle

24:14 them. So, you can see there we have one route defined as post to slash hello, and we're calling the hello world function that was included with the empty project to handle that. So as we go along, we'll and we can add a couple more functions, and I can show you the different ways that those, functions can be put together to handle and do different types of logic. But at the end of the day, this is kind of the entry point, if you will, for the application. This is, where everything is put together and controlled. And it's nice because it is

24:51 from from my use of it, it is a really nice abstraction. It it really toes the line between needing to write a lot of boilerplate and needing to care about, you know, what's happening under the hood. It gives you full control of the execution and what is happening, but it makes it so you don't have to care about how it's happening. The the job scheduler, all of the resources, setting up of the web server, setting up of the message bus, all of that is completely invisible to the developer, and they really get to focus on the

25:25 business logic. Nice. I like it. Yeah. Alright. So this is we're seeing any push request to slash hello to run a hello function thing. Yeah. Which is just You can pop back to that This which is literally just doing a print. Right? Or actually, not even doing a print. It's formatting a string and returning it as a as an option. That's right. Yeah. So we're gonna start super simple. I want us to get this up and running to show that it is working, and then we can start, you know, adding some more stuff to it.

25:31 Writing a Runnable Function (Rust Example)

25:57 So I'll I'll walk through what's here real quick. So it is using the Suborbital Crate to gain access to the Suborbital APIs, the very basic of which is just this runnable trait. So you can see that the hello world struct is adding an implementation for that runnable trait. And then we expose the only required function on that trait, which is the run function. So whenever this function is hit by the job scheduler, it will give you an input, which is just some bytes, and then you provide an output, which is just some more bytes. All of the complicated stuff, all of the

26:38 extra functionality that you get to take advantage of is done through the API. And so we can pretty much, right off the bat, just build this and run it and show it that it's, working. And then we can continue, you know, working on some I don't know if you wanna follow my instructions or if you want to follow the documentation, but oh, you don't need cargo. Oh, oh, I was just falling into my my default in the Wizard. So That's okay. You you actually can like, you can use cargo if you want to, but the the

26:46 Building the Runnable Bundle

27:12 the point of the Suborbital CLI is that it actually abstracts all of that away from you. So if we, dig into the build command, you can do build dash dash help if you want. We can show what the options are. This will take all of the, I should preface this by saying, the functions in a suborbital project are referred to as runnables. So a runnable, in in the ATMO context is a WebAssembly module. But if you were just using the Hive job scheduler by itself, you can implement runnables however you want. So you can use Go code to build runnables.

27:48 You can implement a plug in to run Docker containers or whatever you want. But so that's why I call them runnables, because it is more generic if you want it to be. But in the context of Atmo, they are always WebAssembly modules. So if we run Subo build and then pass dot as the current directory and then dash dash oh, yeah. Sure. That's okay. We'll we'll we can get, more into it. The so the bundle flag is is really what we want because that's going to create that runnable bundle that I mentioned before. So you can hit that. Okay. And

28:21 if I do dash dash native, it'll use my local Rust tooling. But if I don't, it's gonna get docker based on what I can read from here. Right? Yes. That's exactly right. So we can we can run the Docker one first, and then we'll show maybe the differences between the tool chains a little bit later. So we have builders, which are Docker images for all of the languages. Well, I say all. There's two of them. And the the the builder images ship with everything that's needed to build your runnables. And so we can abstract away some of the complexity

28:57 of those individual tool chains, and make it a little bit easier for you. The downside of that, you know, decreased complexity is that it's a little bit slower. As you can see, it's having to download a Docker image. Now it's nice because the slowness only happens really the first time. Once you've got all the images and once you've, you know, done the initial compilation of the of the runnables, the subsequent builds are pretty fast. However, if you were using your native tool chain, this would already be done thirty seconds ago. But we can continue to

29:35 talk for a few minutes while this completes for the first time. Shouldn't take more than a minute or two. Well, yeah. I mean, I've got a question that maybe is I don't know. Glating is the wrong word. But you've written all of the Atmo tools in Go, but Go isn't one of the supported run times. Is there any reason behind that? Yeah. Yeah. It's it's a very good point. So the current support for Go with WebAssembly is not where it needs to be quite yet. There is an alternative Go tool chain called TinyGo that has pretty good WebAssembly support, and I have

30:14 been experimenting with that a little bit. But it's it's honestly just the fact that languages with a simpler, runtime and memory layout work better with WebAssembly, and Go's is not the simplest. So Rust, for example, has a it has a very very, very tiny runtime. It has a very simple memory layout. It's very similar to c and c plus plus. And so it it lends itself very well to the WebAssembly, you know, ecosystem. But then, you know, once Go releases some updates to improve its support, I will definitely be targeting it. It is my my language of choice

30:57 after all. So yeah. I have seen the the conversations around using Go and like the smallest web assembly module compiled. I don't wanna make up numbers, I believe it was like maybe 30 kilobytes or something or maybe it's the hundred. I remember it being a weird figure and tiny go I think they got that down substantially. Yeah, I think I do understand that concern. I also have some good news for our you from the audience. So it's o six jelly jack actually took me seriously when I said that was not their responsibility and I think they've just added Subor

31:28 to the next user repository. So you now have a next day vision for building Subor. Thank you very much, man. That was awesome. There we go. That's awesome. Thank you. Alright. So, yeah, as you can see, this first build is is quite slow. Yeah. I mean, that's a Rust thing. Right? I mean, anyone who's been compiling Rust programs for more than half an hour is is very familiar with the slow compilation speeds, unfortunately. Right. Yeah. And then I think it'll be quite, you know, quite cool to show, like, we can use the native tool chain after this,

31:59 and we'll show how much faster it really can be when you have, you know, some of the dependencies already compiled and whatnot. So, hopefully, this will be done in just a moment, and then we can actually run the whole thing. But I'll talk about what the bundles are first while we're while we're finishing this up. So the the bundle is it really ends up as a zip file. It's nothing complicated, really. But what it will include is it will include your directive, the YAML file, and it will include all of the compiled WebAssembly modules into it. So what will happen is that

32:40 oh, there it goes. You can see there the last line says the bundle was created, runnables dot waz and dot zip. So what will happen is Atmo loads this bundle at runtime. So one thing that I've been having trouble communicating and that I think is might be a little bit, you know, confuse self is not a framework. Atmo is actually an application that runs your application. So it's more of a platform. The The the framework is really, you know, the, the paradigm that it allows you to build applications with, and that is using the directive, using

33:21 the crate and the, you know, the runnable API. But Atmo itself is actually just loading your application and running it. It's a little confusing, and I've been having trouble, like, really getting that message across clearly because I don't even think I can talk about it super coherently at this point. But I hope that makes sense. Yeah. I think so. I think it does. Okay. So I think our next step is to run this. Is that right? Yeah. Yeah. So you can just do Subo dev, and that will spin up a development server. Oh, director. Oh, so you're inside of the

33:51 Running the ATMO Development Server

34:03 no. You're you're inside of the runnable right now. You gotta go up a level. Yep. Oh, yes. Next to the directive.com. So o six Kelly Jack is is thrown in our question as they suggest. They may have missed it but is there a reason that the tooling are starting to go rather than rust? I think the answer you kinda just said it is that Go is your preferred language. Right? Yeah. Yeah. I I am a professionally, like, I am a Go developer, and Go is the language that I can build things the easiest with. And it's important that

34:36 like, I do think that Go is an extremely good language for building web services. And as soon as it is feasible to do so, I will be providing a Go runtime for first of Orbital. But right now, it's just not possible. And honestly, I don't think I would have been able to build nearly as much of these projects as I have in the year that I've been working on it. When it comes to building cloud native type applications, Rust is coming up. Absolutely. It's gonna be, I think, one of the big ones in the next couple years, but it's not quite

35:11 at the level of go just yet in terms of being able to integrate with the other things in the cloud native ecosystem. That's not gonna be true forever, but for now, that's kind of where I stand on that. Alright. Thank you for answering that question. Now we seem to have a small issue. Is that because I did the Suborbital and say that the hello world directory? Should I have done a Suborbital here? Or Let's see let's see, like, an l l what's in the directory for a moment. Oh, yeah. It doesn't seem like the bundle

35:41 Testing the First Endpoint

35:44 got put. I just move it. Yeah. You can move move that bundle up here. Yeah. There you go. There we go. So does that mean I have a web service running on port eighty eighty that I can hit a push request to slash hello and it'll work? Yes. So it it it seems like running that build command inside didn't pull in the directive. So if we can kill this, we can rebuild it. It didn't look like the the directive got pulled in. Otherwise, you would have seen the different routes. No. You so this is something that I need to improve

36:20 the documentation on, but just the dot and then dash dash bundle should be should be good there. Yeah. It's the the CLI and the ATMO itself are the the newer portions of Suborbital. So some of the ergonomics of it is not quite perfect yet. Does change in directory mean that my build context has changed and invalidated the cache? It shouldn't because the Docker the Docker builder gets mounted to the runnable directory itself, the crates index thing is something that I'm working on improving. It doesn't need to update its crates index every time, but it yeah. There you go. What now

37:04 that all the prerequisites have been precompiled, we should be good to go. So you can run that dev command again. Nice. Okay. There we go. So now we can see that first line. It says mounting the route. That means that we've got all of the stuff that we need, and it has set up the application for us. So now if you, yeah, just make a post request to slash hello, we can just see that running real quick. It is It's up. Yeah. There you go. So you can see here it's just returning you a summary of what the request is.

37:43 So it's just telling you that that's what happened and it's giving you the request ID that was generated. And so now we can hop into the the Rust function and actually do some something cooler with it. Right. So, that you're getting that's what it's just a summary of what the request is telling you that it's a post request. It's giving you the URI and the and a request ID. If we want to access the rest of the request and, you know, get some more information from it, we use the suborbital crates to do that. So at the top,

38:00 HTTP Request Body

38:20 if you could include another of the sub crates, which is suborbital colon colon rec r e q in addition to the yeah. Exactly. So now we can use that to access some information about the request. So if we do yeah. Like, let's say we want to get the body, we can say rec colon colon body underscore raw. And then Why am I not getting my auto complete? That's a good question. I can't call if it's auto complete. I find personally that the the Rust the what do they call it? The Rust analyzer needs to be restarted every once in a

39:09 while, and that's just my personal I think I dismissed the message saying, hey. We wanna update Rust analyzer when I started it. That's awesome. Yeah. In fact, I'm not even in the right right now. Let's let's not confuse it too much. Let me do that. Let's see. Yeah. There we go. Okay. Not installed. Not that it needs updated. Wonder why that is. Yeah. I honestly language servers in general have been giving me problems lately. Even the go language server and the rust language server have both been just causing me issues as of late. Alright. Well, that is now indexing those libraries

39:52 some 10 or 75. So let's assume that's gonna take thirty seconds. Yeah. For sure. So I'll I'll talk a bit more about what those APIs are. So so the Suborbital Crate, it's it gives you access to things outside of the Web module, and it does so in a very controlled way. So this this goes back to the security properties of WebAssembly. Right? And we can talk for a second about what those are. WebAssembly modules run inside a, you know, a nice sandbox. In this case, we're using the Wasmr runtime. And it means that only what the host explicitly

40:32 grants to the module can be accessed. And so that means that ATMO and the the the the the Hive job scheduler can control exactly what these modules are allowed to do. And we do that by providing APIs through this crate. So I think it looks like it's working now. We can grab the body raw. I think that will be a vec, so we'll wanna make that a string most likely. Yeah. Let me if I can remember how to do that. There is a util package with Suborbital if you want to use it because I always

41:09 get confused by these. There's a string. Yeah. It seems okay with that. Yeah. Oh, no. Cool. It's okay. You can you can kill most of the stuff that's inside of the sum, and we can just return that something if you if you want. There is a if you import the util module from Suborbital, it will give you a a convenience function to convert vector string. So that this is yeah. It's the vector of of base. Why is there no Yep. Collect. Okay. Never mind. And what's that helper function called, sir? Yeah. So if you import the util module including

41:54 in in addition to those two, then you should be able to do util colon colon to string, I think it is, and then pass in the VEC. Nice. There we go. We have a string. Yeah. Cool. And then, you can delete all the stuff inside line 12 to 14 there, you can just return something there as your, as your return value. Yeah. Something like the variable. Oh, alright. Oh, okay. Okay. Actually, no. That's a string. So we're we're gonna want, you know what? I don't I I I think we went a little bit too far.

42:37 The, we want to return One space. To evacuate. Yeah. So we can we can cancel the string. Yeah. I I I usually do lots of string manipulation with some of these things, I'm so used to converting it to string right off the bat. But yeah. Oh. We can go ahead and just do that. Raw. Okay. And we're retarding that, so we'll leave it as so. Okay. Cool. Yeah. You no longer need that. I mean, you'll wanna change input there to an underscore just because we're not using it anymore. The the actual run parameter called input

43:10 can be a underscore. Yeah. Oh, well, I guess There we go. There we go. So so, yeah, what's happening here is when when a request is being handled by this WebAssembly module, the Atmo will basically bind that request to this module, and then we use these APIs to access more information about it. So now if you go and build again, we can deploy that server. We can just kinda show that very basic version of it. Now that we are After after this build, we'll set up your native one so that we can do it lightning fast.

43:58 I'm assuming I can just pass through any strength as the body. Yep. That's right. That's that's the thing about WebAssembly is that because we are having to pass data amongst, you know, guest modules that are written in different languages, and they're all running inside this WebAssembly runtime, we do need to, you know, transfer stuff around as bytes. There is something coming very soon into the WebAssembly spec called reference types where you will be able to pass more complex data structures like structs and whatnot. And did that Yeah. It worked. Okay. Cool. So that's great. Yeah. So, yeah, reference types will

44:47 be added to the WebAssembly spec soon, and you'll be able to pass more complex data types. But for now, you you're really limited to passing around bytes. Is there any sort of middleware system where I can inject my own parsers for, like, you know, HTTP request headers, deserializing the body into certain structs or anything like that? Yeah. So that is a for now, the way that I've I've approached this is I'm providing convenience things for you through these crates. But the goal is to eventually remove any of that custom functionality in favor of, you know, the standard language things.

45:29 We'll need a little bit more functionality in the WebAssembly runtime before we can really do that well. So, for example, we can do that right now if you, for example, if the body was JSON and and we wanted to access a particular part of it, we could take that body raw and we could, you know, disassemble it into a struct. But Suborbital Crate does provide some, functions to do this for you. So we can say let something equal, there's a body underscore field function that we can use to actually take the request JSON, parse it, and pull fields out of it

46:09 automatically. So, we can just, you know, key hello or whatever. Yeah. Sure. And then and I think that will return I'm not sure if that returns a vector string. I could just oh, no. Body field might return bytes as well. It returns a string. Oh, okay. So then you want to do I think it's as bytes to vec or something. Like, you do as bytes and then dot to vec. Oh, yeah. Yeah. There we go. Yeah. So let's let's quickly set up your native runtime or your native tool chain so we can get those super fast builds.

46:59 Do you have Rust up installed? Mhmm. I do. So if you just do Rust up tool chain install WASM 32 dash Wazi I think it's tool chain install. Let me let me make sure I'm getting that right. Is that children left foot? Let just get the exact one for you. I just keep guessing just Yeah. So Rust up target add WASM 32 dash Wazy. Target add WASM 32 Wazy. Yeah. That looks better. Yeah. Yes. So these are the kinds of not complicated to install these various tool chains, but I did wanna make it extremely easy for somebody

48:08 to just get up and running with the basic version. And then if they want to add, you know, the the easier to use parts of it later, they can. So, yeah, you can hit that command. The passing the native flag will just allow it to use your local tool chain. And as we can shortly see, this will be a fair bit faster off the bat than Docker. And then on that second run through, it'll be, like, milliseconds. So see the well, just well, let's compile on it. So we're now using request body field name. Now

48:44 is that gonna decode whatever JSON I pass in, or is it expecting me to pass in query parameters? What what's the semantics there? Yeah. So that that yeah. That will pull in, yeah, from the body, from the request body just like you have. There are other helper functions for accessing query params. We'll look at HTTP, like, path params as well, headers, all sorts of things. Those are all provided by the library for you to access. Oh, nice. So I can actually just do, like, this was a query param where I pass the name as David or Connor, and it would actually know

49:16 to to parse that to. Yeah. So yeah. We'll we'll we can do that one in a second and we can actually control that with the directive as well. Cool. Alright. So we've got the JSON parsing. Yeah. So yeah. So we can look at HTTP paths if you want or sorry, URIs. If we pop open the directive, it looks like code doesn't have the root open, but you can just I'm trying to make this as difficult for you as possible. That's what that is. You know? That's alright. Yeah. It's it's it's it's always a guessing game whether Versus Code will

49:53 properly handle multiple crates in the same project or not. Yeah. So if we just, you know, after that slash hello, add a slash colon name, then that's, you know, setting up a, basically, a path wildcard, and we can then access that in our crates. So if you switch from body field, I believe it is just param, rec colon colon param, I think. URL param? Yes. URL param. That's the one. And then, yeah, same thing, plus name. And then, we can go back and see that native tool chain in practice. See how fast that was this the next

50:46 time around. Alright. And then we should be able to do yeah. Kill all of the so right. We're doing it. Exactly. Sweet. Nice. I like it. Yeah. So those are the kinds of things. As you can see, like, a lot of the APIs are designed around building, well, web APIs. That's kind of the focus for now with Atmo is is really building, you know, like, the standard REST API. But, that's not the end goal, or at least that's not the entire goal. So the entire goal is to be able to handle, you know, event based traffic. You know, you should be

51:30 able to, attach Atmo to, you know, a Kafka message queue or NATs, and you should be able to handle any kind of input. That's one of the nice things about the Grav project is that it accepts plug ins for all sorts of different transports. And so, connecting to various, you know, messaging or, queue systems will be eventually pretty trivial. And so you should be able to handle all sorts of different traffic using Atmo. But, you know, talk to me in six months and that'll probably be available. Alright. So I think we've done a a good job of showing how we're using Rust

52:00 Workflows through function composition

52:14 to component to Wasm. We're using the the runtime here. Can we now take a look at composition? Can I add a new endpoint and pass data from one to the other? Sure. So let's head back to the terminal and we can do Subor create runnable and then give it a name. Call it translator. Sure. Cool. So, yeah, you should have another one in there now, and it'll be empty once again. And so we can you know, what what do you what do you wanna build here? We can So why don't we just take the hello world, which takes a name

52:20 Creating a Second Function for Composition

52:57 on the the URL parameter right now. So I pass in David or Connor, and why don't we have to translate or just reverse the string and spit it back out? Sure. Sounds great. So this brings us to the declarative application building, and this is the part that gets me pretty excited. So if we open up that directive, file for just a moment, I wanna walk through, some of the basics. So you can see here in the handler, we name a number of steps. And so what's happening here is that each step in the chain will produce an output.

53:07 Function Chaining and Request State

53:35 So the hello world one will just spit out the name from the URL. Every time a step completes, the output gets saved to what's called the request state. And this is, basically a map or, the key value pairs that is, you know, constructed for each request. And if I wanna access the state from one of the runnables, the Suborbital crates, the the library, will allow me to do that. So when this hello world function runs in the first step, its output will get saved to state. And then the second step, which will be our reverse, will be able to access that

54:17 state and pull the value that was output in the first step and then use that to do whatever it wants with. So on line 14 right where your cursor is, we can add another f n, exactly like the first one, and we'll say, translate, I think you called it. So this will now in the translator runnable, we're going to access that state and figure out what that hello world function, gave us. So you can use, we're we're gonna import that rec module again, because we're gonna be accessing the request state. And, yep. And so if you,

55:06 do rec colon colon state, I will put it in a variable. So let name equal, you know, rec colon colon state. Give it a second. See if it catches up. Alright. Yeah. I think it's just a lot of queries. Let me pop it open and just a translator. Yeah. Sure. Those pesky language servers. Yeah. They're not I think it's a handle model ripples really well, I don't think so. Yeah. Okay. Now that looks a bit healthier. Oh, I've not done a cargo install yet. Do I need to or a build? Or So Versus Code usually does that for you,

55:57 but I mean Well, does this fetching metadata. Alright. So But I mean, we can run a Suborbital build and that will build all of the prerequisites and stuff if you want. Yeah. Why not? So So if you just if you're inside of of a of a runnable, I mean, yeah, sure. You can do the whole thing if you want. That'll build all of them. But if you just wanna run one, you can do that as well. But, yeah, go ahead and do that. Yeah. It seems a bit happier now. Potentially. There we go. Alright. So it just wants

56:49 a Yeah. So we'll just ask for so in this case, we're gonna ask for hello world because that was the name of the function. But that's not super ergonomic. So let's go back to the directive, and we can actually make that a little bit nicer. I'm in I'm in limbo. I'll grab beach ball. Okay. Let's open up this whole thing again. You can just maybe add the directive file if you don't wanna add the whole thing. We just got the the most important question of the day. What is my Versus code color scheme? It is It is very nice. This one

57:39 is called plastic I believe. Panda syntax. It's not plastic. Panda syntax. Alright. We wanted the directive. Okay. So we wanna improve the ergonomics of the passing first date. Exactly. So so by default, the the value in state we want to make that a nicer name. So underneath the hello world on line 13, we can add a new line, and we can say as, and then a colon, and then name. So the the as clause is, one of the things you can use in the directive to make, you know, the state easier to work with. So it basically is like assigning to a

58:30 variable. We're saying, run hello world and save it as name. So now we can pop back to the translator, function. And instead of requesting it as hello world, we can just request it as name. And it makes a lot more sense from the from the perspective developer. So then we can do our magic to do the reversal. I'm gonna let you handle this part because a Rust developer, I am not. Yeah. Good. I never really planned this through today. I will do some quick googling. Sorry. Unless you tell me I called it anyway. Don't mind showing people. So Rust, Rivera, it's a

58:51 Implementing String Reversal (Translator)

59:09 string. Yeah. It's looks like .chars.rev will There we go. Do it. Does that return or does it mutate? Yeah. Okay. Oh, and then you might wanna dot collect from that. Okay. So reverse equals. And because we're doing a collect, we need to specify the type. There we go. So now we can use our util function. That's right. Oh, no. We don't need it because it already is. Oh, no. We need bytes. Okay. Reverse. Yeah. Bytes. Not too back, I think, as well. That's right. Yep. Thank you. And this doesn't need to be mutable. Let's get rid of that yellow squiggle here. Oh,

1:00:10 too much. Too much. That piece, the compiler. Alright. Yes. Great. Okay. So, now let's just revisit the directive to make sure that we are summarizing what's happening. So we're running the hello world function. That's returning the name from the URL parameter. We're saving it into the request state as name, and then the translator function is going to run take that name and give us the reverse version. So we can build that and let it run. Great. Hey. It worked. There you go. I mean, of course, it worked. Like, never ending this. Hey. In my head, that's what I'm thinking.

1:01:00 Running steps in parallel

1:01:02 Yes. Composition. Right? You, you can do all sorts of different things. Now there's one more little superpower of the directive that I'd love to show off. If we could create one more runnable, I do wanna show some of the powers that WebAssembly gives us. So if we create runnable, let's just call it, you know, the thingy. Yeah. Sure. Now, it it can honestly, we can just leave it as the default. It doesn't, what it actually does doesn't matter. If we pop over to the directive for a moment, we can do something pretty cool. So, let's

1:01:08 Function Groups for Parallel Execution

1:01:51 say we want to run a bunch of these functions in parallel. Say you wanna do a whole bunch of data fetching all at once. Say you want to, you know, connect to a bunch of different resources and pull in a bunch of different data. We can use what's called a function group here. So, let's go in here. We can just pass group, as the instead of f n. And then, we'll have to go down a line and then add a couple of f n's to that group. So, yes, I think that should do it. You

1:02:27 never know with YAML indentation, but so we can actually put yeah. We can do that, or we can we can actually put, you know, the hello world in there as well if we want to. And so what's going to happen here is that the the job schedule will actually run all of these functions concurrently, and then all of their results will be put into that request state. So if you wanted to do parallel processing, if you wanted to, you know, save to a database and a cache simultaneously, these are the kinds of things that you

1:03:04 can do yeah. With a function group. And it's really nice because you, as the developer, you don't need to do any of the logic that you would normally need to do to run these things concurrently. You know, if you were a Go developer, you would have to be dealing with Go routines. You'd have to be dealing with channels. You'd have to be making sure that they all blah blah blah succeeding. But with this, we just say, hey. We wanna run these functions in parallel, and the job scheduler will figure it out. So, you know, we don't necessarily have to run this because

1:03:35 it's not gonna look any different from an output perspective, but, you know, I I do wanna just kinda point out that these are some of the things that we can do with it. So there's that I think there's two questions in my mind right now. Now I'll start with the first one and then I'll go into well, I guess it is my they're still in my mind. So the first question is is the the base we are passing back as as the state of each of these individual functions. The only way to transfer state between the

1:03:48 Shared Resources (Cache, Planned DB Access)

1:04:05 functions and then I guess the example I'm thinking there is if I wanted to do any form of image manipulation, would I have to store those bytes of memory and return them or can I to have it like shared disk across the invocations at all? So currently, you can't access the disk. That is something that I will be adding once I can get Wazee working reliably across both of the Rust and Swift. But what you can access as a shared resource is a cache. So there is a suborbital API for accessing a cache. If you want to connect to

1:04:42 Redis or something like that, you can do so. I do plan on adding more APIs very soon, which will let you access more resources like that. Like, one of the things I would like to do is give access to, you know, static files. If you want to serve, you know, a static website, you should be able to include those files into the bundle and allow, you know, your runnables to access those files. So these kinds of things, you know, accessing shared disk, accessing files, connecting to more things outside of the modules, these are all things that I'm designing right

1:05:19 now and I'm working on building up. But, you know, they each have to be built individually and they all have their own security concerns and whatnot. So I'm trying to be a little extra careful, with some of those things to make sure that I'm building them in a way that, you know, won't let you screw it up. Alright. And my second question is like we're now in a stage with us, you know, directive failed that we have. Our first step, we then have a group which runs three in parallel followed by our final step which is a translator.

1:05:52 If I were to run this like so, sorry. Let me try and articulate this question in a way that makes sense. But I only see the output from the final step. If I wanted to debug something in the middle, is there a pragmatic way of handling that at the moment? Yeah. So there's two things that you can do. One of them is that the suborbital package, provides some logging functions. So if we want, we can go back to, you know, the translator, for example, and we can add a little bit of logging if you like. And then the other,

1:06:10 Debugging and Controlling Response Output

1:06:27 the other thing is you can control which function's output is used as the response, and we can do whichever of those two things you wanna do first. So if you it just import the log module. Then, you know, if you want, yeah, we can say log colon colon info, and then just pass in you'll have to do an as str on that. Or yeah. That works fine. So now you can we can run that and see that being logged. Right off the bat here. You can see how much faster the data of full chain is than the Docker one.

1:07:13 So then somewhere in the middle yeah. You can see stuff and things popping out there. And so the other thing that you can do is if you want to take the output from a particular function, we can head back to the directive, and you can use the response option. So right at the end of the handler, the same level as the steps key, We can go right to the very end. Or yeah. It it doesn't matter. So if you just say response colon and then choose one of the names. So if you wanted to do thingy

1:07:51 as the the the output, you can actually tell it this is the one that I wanna take the output from to actually respond to the request with. So this one will probably just be that default, once again, the, yeah, the summary of request because we didn't actually change the thingy on the phone. Alright. Cool. Yeah. And this helps that, like, if the if the last step in the in the chain is a group, right, that there's no logical way to choose between the functions in that group. And actually, Suborbital will error out if you just have a group as the last

1:08:29 step. It will tell you that you must give a response field to to make sure that it's unambiguous. Okay. Is, as there are docs on this directive file and all the things that we can Yeah. Absolutely. Because like one of the things popping into my head and probably may not exist yet would be like, you know, flow constructs within here. Like if I could do for each and then tell it like it was from whatever I got from hello world, you know, maybe it returns like a the vector base have like something I could split on and I can say

1:09:09 split on a comma like you know where I could actually build for loops with obviously I can do that and the translator lib. Rs but to build that into a directive I think would be really cool and of course maybe like Yeah. Conditionals too. So only if this far is defined or whatever and like really starting to build out complex. I guess workflow is kind of what I'm thinking up here. Absolutely. That's definitely in the plan. The the four h one particularly, I was planning on doing that very soon. I was hoping to get it done for

1:09:40 this livestream, but I haven't quite gotten that part finished yet. But absolutely. Plus I'm identifying areas of the project where I can hopefully come and help out. Because I I mean, I can see loads of use cases for a tool like this. Okay. You know, I like building the dent driven applications and this is like the perfect thing where I could just build out all those functions in isolation and then chain them together with the composition. It seems like a really powerful tool. I'm very impressed. Yeah. Thank you very much. Yeah. It's the this is one of the things where I

1:10:10 was I was I was developing, you know, the three building blocks. Right? The hive, vector, and grav. And this this idea, the idea of the directive, when that was when I kind of thought of this concept, that was when it really clicked for me of what Atmo was going to be. I I thought it was just gonna be, you know, you just write code and you have to call the functions directly with some Go code or something. And that felt fine, but I wasn't super excited about it. And then when this this idea of the

1:10:45 of the directive came up in my head, that's when I started to get really excited. And that's the day that I created you know, I actually started the Atmo repository and started actually building it because that that was the thing that got me super excited. Sweet. Excellent. So we have another comment on my theme for Kelly Jackson. That's not what it looks like on mine. Jump in the Discord. I'll chat you there. We're not gonna be able to live debug that here. Okay. So we've covered sorry for the segue there. We've covered a fair bit of this.

1:11:00 Advanced Demo: HTTP and Caching

1:11:19 I'm excited about this tool. I believe you've got a few more advanced demos that you may wanna show us. Sure. Yeah. I will show off, you know, one or two more bits of the, runnable API. Let me make sure. Let's get that screen share up and running again. Cool. Just make sure I'm in the right is that font big enough, do think? Or you can make it a bit I mean, it wouldn't hurt to go in a couple more for sure, but it's it's readable. Yeah. Yeah. Okay. Okay. Cool. So we're going to go into

1:11:25 Demo: Advanced APIs (HTTP Client)

1:11:58 I have my own important API, of course. So, of course, that opens in the wrong screen. Alright. So I've got a runnable here that this is this is available in the Suborbital GitHub if anybody wants to take a look at this one. Could you zoom in on that a little bit as well, please? Yeah. Absolutely. I'll get rid of this bottom and just make this smaller so that I can really see it. Okay. So so, yes, this is available in the Suborbital GitHub. It's called important API. That's what you know, it's it's very, very useful.

1:12:34 And this it's designed to show off more of the APIs that are available. So, you know, we've we've looked already at, like, RAC, and we looked at log and util, but there's one more that I wanna show off, which is HTTP. So by default, you know, WebAssembly can't access the network. And in fact, even the Wazi specification, you know, it still doesn't quite give full access to networks. There's some things coming up. There are some things currently in development. There are some limited things available already. But I wasn't fully happy with it, and I wanted to build my kind of own

1:13:15 version of it. So the Suborbital library provides this HTTP, module. And what it lets us do is make HTTP requests. So I've got this runnable here, and all it's really doing is it's using, you know, the the rec, module that we've already looked at. You know, it's checking the URL param just like we did a minute ago. And what it then does is it's gonna go hit the GitHub API, and it's just gonna get the details of whatever repository we pass in, as the the fields in the in the URL. And then we're gonna do something, you know,

1:13:54 pretty pretty standard. You know, we we access the field directly in in the example that we did, but I'm going to just show that this can be a regular Rust program. Right? You can use SerDay and you can deserialize JSON and you can do whatever you want here. So we are gonna take the response from that GitHub API request. We are going to create just a a summary of, the stargazers, so, like, the star count on that repo, and then that's what we're gonna return. So I'm going to, build this. Not build. We'll give bundle.

1:14:37 And, obviously, I've built this once already because that was super fast. And then we're going to start this up in my other terminal here. Suborbital dev. And wow. It really oh, something's already listening on that port, apparently. What do I have running? Apparently, I already have one running. Let's try this again. There we go. I'm gonna clear this. I hope that last one wasn't important. No. I'm pretty sure that was just me preparing for this demo. Right. So you can see, you know, we're mounting this this route. It has a different style of wildcard that lets us pass

1:15:22 any kind of path that we want. And so we're gonna hit local host eighty eighty slash stars, and we'll do, like, Suborbital ATMO, for example. And as soon as we hit that, it is going to execute that g h stars function, and then it's gonna return to us information from that GitHub API. And we can see that it did, you know, do some logging, fetching stars for Suborbital ATMO, and it did all of the JSON parsing with SerDay, etcetera, etcetera. And so, you know, this is just one of the other APIs. And then the last one, that we can

1:16:02 just take a quick look at is, the ability to access the cache. So say I wanted to, you know, cache this this API response. There is one more, here that we can access. Probably should make it the first one. The Suborbital cache, one. So we can say cache set. That is not colon. And then we can say we wanna set, you know we'll call it the we'll say we'll put a repo as the key because we want it to be specific to the repo that we are requesting for. And then the value can be, those repo details,

1:16:04 Demo: Advanced APIs (Cache)

1:16:44 and then we'll set the TTL to zero so it never dies. And so then oh, this is gonna yell at me, isn't it? Borrower group value. And we need to do, I think, as owned? No. Two clone. Yeah. Okay. Oh, yeah. Clone. Yes. See, I'm getting a lesson right here on some Rust best practices. So so then, you know, the the nice thing about WebAssembly and and Atmo is that you as the developer, you don't need to care about the cache, what it is, what it's connected to, you know, how it's configured. The cache is bound

1:17:23 at runtime. And so all of your functions can use this API. And then maybe in local development, it's using an in memory cache, but then in production, it could use Redis or Memcache or whatever. And you as a developer don't need to care. You just bind to this this API, and it will figure itself out at runtime. So, yeah, those are just a couple of the extra, you know, pieces of functionality that it has. More coming. The thing that I'm working on right now, is accessing databases. I think that's kind of the last big piece

1:18:02 to really make this, usable for the kind of average API application, access to a cache and access to a database. Those are, like, kind of the very bare minimum things that you need. So, hopefully, within a month or two, there will be a, you know, suborbital DB here that you can use to do some SQL queries or maybe it'll be GraphQL. I don't know. We'll we'll see where we end up with that. Yeah. Awesome. Very, very cool. I like it. Thanks. So we've we've covered quite a lot. I hope that gives the people that are watching an idea of you know,

1:18:36 Contributing to Suborbital

1:18:43 the project, what is use cases are, why you would wanna use it. You even give us a little bit of extra what's coming kind of next day as well, which is also fantastic. Is there, I mean we kind of deviated right? We paved our own path there instead of even using your brand new documentation. I feel a bit bad there but I still feel that we should have the platform, the docs are here for anyone who wants to pop in through. So I'll leave you with with this then. How can people contribute? What do you want help with? And is

1:19:13 there anything else that we haven't covered that you wanna just quickly drop in at the end there? Yeah. Absolutely. So for con for contributions, literally anything. And I say that with the broadest sense. So it doesn't matter if you are a Go developer. It doesn't matter if you've never used WebAssembly before. It doesn't matter, you know, what operating system you're using. I I want anybody to be able to contribute to this. And, you know, whether it's documentation, whether it's working on, you know, the CLI, whether it's working on the job scheduler, any of the components, really,

1:19:54 I'm I'd love to have people come and and help build these things. In particular, you know, I like I've said more than once here, I'm not a Rust developer. And we didn't even get a chance to dig into the Swift portions of things, bit because there is a support for for Swift here as well. Swift developers as well. You know, anybody with with experience in those languages, very much appreciated any help that they could give. And then I want to bring additional language support as well. So, you know, c, c plus plus developers, anyone with a

1:20:30 who's used AssemblyScript and wants to come in and build that with us, you know, that that's really fantastic. And then even if you're don't want to contribute code, use Atmo and find where it breaks. That is one of the best things that you can do and help me get it from the alpha that it is today to something that can be used for real world workloads. Show me where it doesn't work for you, not just from, like, a crash or a bug, but ergonomically. Where does it feel awkward? Where do you see it as being inferior

1:21:07 to building an application the old fashioned way? Any of those types of things are are always immensely helpful. And then taking that survey. So the, the bit.ly/wasm survey, I wanna know, you know it it's it's really just five or six questions about languages, capabilities, and, you know, things that you would want to see from this type of framework and platform. And I've forgotten what your second question was. Yeah. Was there anything else that we haven't mentioned that you wanna quickly add on? Oh, that's right. The Atmo itself is fantastic, and I you know, that's my main focus.

1:21:51 Standalone Suborbital Projects

1:21:51 But the individual projects are also completely usable on their own. If you just need a job scheduler, Hive is fantastic. If you want to just make building APIs in Go simpler, Vector is really great. If you want a decentralized message bus, Grav is fantastic. And, contributing plug ins for Grav, for example, would be really great. They are, super easy to build and, you know, the documentation is not fantastic, but it's it's really fun to to build on. And I've I'm really quite happy with how that project is coming out. So, you know, any and all of the projects

1:22:30 are open for new users and and contributors. Alright. Awesome. Well, thank you very much for for getting up early joining me today for your work on at more and web assembly and providing tools to make this easier for people to adopt. Really good to see. Cheers. It's been great. And I'll let you into a little secret. My secret power is breaking software. So give me a couple of days with us and I will find you the bugs that you're looking for. That sounds great. Alright. Well, thank you again. I hope you have a great day. I'm

1:22:37 Conclusion and Thanks

1:23:02 looking forward to seeing where this and I'll speak to you again soon. Thank you, Connor. Yeah. Cheers. Thanks so much.