2:41 Introduction

2:41 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, also known across the Internet as Rawkode. Today, we are taking a look at a API developer platform called WunderGraph. And to guide us on today's journey, I am joined by the founder, Jens. Good evening, Jens. How's it going? Good evening. Nice. You helped me on the on the show. Yeah. I'm excited. I always love to play with really cool technology. And I think what makes this extra special is like I was actually playing an experiment with with with WunderGraph before we even discussed

3:08 TLDR

3:20 doing a session together. And I was like, this is really cool. Like, we we need to to show this to people and and and share it. So before we talk about WunderGraph and what that is and get started with the hands on demo today, Could you just give us the TLDR on who is Jens, what you're up to, and anything else you wish to share? Sure. Yeah. I'm Jens, the founder of WunderGraph. I'm 34. I have two kids, Leonie and Janik, one and three, which are also in my avatar. I think, like, family is probably the most important thing

3:56 in in my life. Plus WunderGraph, You know? Like, I have, like, three kids, if you wanna say so. But yeah. I I think the the and the the the important bit here is why WunderGraph? And and if you look at my career, I started actually as an entrepreneur. I never studied computer science or or anything. I wanted to build a startup at the early age of 20. I just wanted to build a startup, and there was nobody who could build me an iOS and an Android app, so I just had to learn it myself. So there was

4:12 Jens' Background and Motivation for WunderGraph

4:35 a guy on YouTube called Slide Nerd from India with the classic Indian accent. I I and I learned Java from him, and it was such a pain for the first couple of months because I just didn't get computing and and programming. And yeah. But, eventually, this whole thing, it turned into an app. I learned iOS programming and and Android. Later, I switched to React Native. I built my back end first in Java, then I learned about Go. And and, yeah, that startup eventually failed because startups are hard, and we didn't have a clue. But we learned a lot. And then,

5:18 yeah, I started, like, a regular career as a programmer, turned architect team lead. And through that career, I kind of learned the the complexity of actually working with APIs. And at the last big company I worked for, we had to integrate, like, 30 different services, and it was a huge pain in the ass. And we built our own REST APIs and and somehow cobbled everything together, the different protocols and and different APIs, and it was a real mess. And then I joined an API management company, Tyke, where I learned a lot about API gateways, how they work, what they do, etcetera.

6:06 I was, like, two and a half years at Tyke, and I found that there's a lot of, like, full stack developers that don't know enough about API management, and API management doesn't know enough about full stack developers. So what I wanted to create is a developer experience that puts together full stack development, API management, and API integration. So I wanted to build a toolset where full stack developers feel home. They get the capabilities of an API gateway without actually or without having the feeling of using an API gateway. Because if you talk API gateways like Thai,

6:24 What is WunderGraph? (BFF, Gateway, Framework)

6:54 Kong, Apigee, and so on and so forth, These tools, they are user usually designed for ops people. Like, you have a dashboard. You configure it. It's like very heavyweight introducing an API gateway to your stack. It's a it's a complex thing, and it it completely changes your architecture. What I wanted to create with WunderGraph is a simplified architecture where you leverage capabilities of an API gateway, but it still feels like you're just doing full stack. So when you when you use WunderGraph, it looks more or less or very similar to something like Next. Js, but you actually

7:34 have an API gateway. You have a back end. You can put custom codes, and you have a lot of functionality that that helps you with API integration, that integrates with your identity providers, that solves a lot of enterprise use cases when when you want to scale something that you would not normally find in a framework like Next. Js. But it's, yeah, it's it's kind of like a special developer experience if you if you have some experience in in the market and and what what kind of tooling and and patterns can be used, I would say it's kind of like a

8:12 combination of Next. Js, a back end for front end pattern, and an API gateway all together in in one user experience. It's all TypeScript. So we use Go behind the scenes for for performance reasons, but the user experience is TypeScript, so everything is configured in TypeScript. We use infrastructure as code patterns, so there's no GUI. There's no dashboard because developers don't like to click around. They want to code. They want to put their stuff in Git. And, yeah, it's kind of like everything I hated throughout my career, I try to do better, and the result

8:55 is WunderGraph. Alright. Awesome. There is a lot to unpack there. So thank you for sharing all of that. What I'll say is I also have two young kids, four and one. So I feel your pain and then I fuck. Because I couldn't imagine trying to build a start up with kids that young. Must be tough. But awesome. Can I comment on that? Of course. Yeah. You know, the the right time, like the the right time to lose weight is is never The the right time to have kids is never. The right time to start a startup

9:28 is also never. You just have to do things like you know, if you have kids and you're like, should I start a startup? The answer would usually or always be no. Just go to a corporate. And I I just said, like, fuck it. We're we're gonna do this. Like, you know, I I sometimes in your life I don't know who who else feels like that, but sometimes in in your life, you find yourself in a situation where you're like, I cannot work at a company anymore. I must do this. This is my mission. Like, WunderGraph must exist.

10:02 And and, yeah, that's just my personality. Yeah. Awesome. Well, congratulations. I wish you all the best of luck, but I know you're not gonna need it because I played with WunderGraph and it's fucking awesome. So I also quit my job in September saying fuck it as well, but you know, it's not a startup thing. I'm just a consultant, I guess. So no, it doesn't feel as risky when it's just me. Anyway, back on track. I don't even know where we were anymore. Yes. Yes. You were talking about logical technologies. So you mentioned go. So I'm a big

10:36 fan of go. I'm I'm a even bigger fan of typescript and I am a huge advocate of everything as code. The job I quit was from Pulumi. So I spent the last year of my life doing infrastructure. Uh-huh. Yeah. Pulumi is big inspiration for WunderGraph because we we you know, when I saw Pulumi, I was like, hey. I I can create a bucket, and I can create a service all by writing some TypeScript, and then I do pull me up. And I was like, this is what we need for. It's interesting. I didn't know. Yeah. I mean,

11:11 Discussion on Core Technologies (TypeScript, Go, Rust)

11:11 I've been infrastructure as coding everything for many years. I've been using TypeScript as a language for defining Kubernetes objects for years prior to that. Was just in Terraform. I've played with CDKTF. And if in that, can describe stuff as code makes me a very, very happy person. Even things like Prisma, although it's not a readily code, but that DSL for database migrations, I think is very cool. So, yeah, when you say this has got an API that gives you that API is code kind of mentality or infrastructure is code mentality to work with your APIs. It's something

11:12 Typescript

11:43 that I'm very passionate about. Another project that I've been exploring a lot lately is Dagger, which is CICD pipelines as code as well using TypeScript. I always seem to come back to TypeScript because and I'm assuming this is one of the reasons that you probably picked it in the project. It's just it's got that right balance of approachable and accessible with the tape semantics. Like, you don't have to go learn the borrow checker Rust for instance to get a strongly typed system and TypeScript works really well. I think it's a nice language for people to to learn some of these more complex

12:14 intricacies of type based systems. It's an interesting topic because I actually like to talk about Rust, Go and TypeScript. So for example, the the gateway of WunderGraph, it's written in Go, and I think it's the perfect language because Go has this balance between it's crazy fast, and most of the time, you get it right. You don't need a borrow checker. Borrow checkers are for super smart people who who solve crazy hard problems. We're just building an API gateway. Yes. It's hard, but it's not at the hard level. Like, it's you know, we're not building an

12:58 aircraft or a tank. We're just getting HTTP requests. Go is perfect because it's it's much easier to to I feel super productive in Go. Whenever I try to learn Rust, I feel very stupid. And TypeScript, on the other hand, you know, Go is great if you do, like, yeah, like, back end back end stuff. But if you want to do something with the user interface or if you want to create code with the user interface, like code as the interface, I think TypeScript with its rich generic capabilities, it's the perfect language for a user interface. If we think, you

13:46 know, not buttons, but for developers, the user interface is the language. And I think TypeScript is actually the best language to create amazing developer experiences. Like, that that's that's my love for for TypeScript. So everything that should be super fast, I would say, Go. Everything that should be pleasant to use, TypeScript, and everything that should be super safe, I would go Rust. But, yeah, for for us, API gateway, Go is safe enough, I would say. Awesome. Alright. Well, I don't wanna just keep talking about programming languages all day. Although I'm more than happy to sit and talk about all

14:20 Why use WunderGraph

14:26 three of those for the next three hours. I do want us to to kind of focus on WunderGraph and get hands on with it. So we'll start the demo in a few more minutes, but maybe we can give you know, you kind of talked about what it is or what you're trying to achieve with it, but maybe we could be very specific. What is that use case that people should take away from today about why they need to start using WunderGraph? Yes. So I think one thing that's what I learned in my career. One thing that is

14:50 The Problem of API Integration & WunderGraph's Solution

14:57 probably true for every application is or every web application, you usually have a front end, You have a back end, and your back end doesn't talk to a single database. That's almost never the case. What's more likely is your front end, you have back end, and the back end talks to hi, Jamie, by the way. The the back end talks to a database and a couple other services. Those could be internal services. Those could be a partner APIs. Those could be third party services. And one thing that's that's, like, front and center to WunderGraph is the idea

15:40 of we have an opinion on how you should put together APIs. And what that opinion does is, you know, kind of like Laravel. When Laravel was enough, you had a structure of this is how you write a controller, and you knew what to do, and this is how you do a migration. And what we do with APIs is kind of like we're completely in the stone age because if you add APIs to a project, it's kind of like implicitly managing dependencies. And, you know, for code, like Go, we have Go modules. In Java, we have Maven.

16:22 And in in Node. Js, we have NPM. And for APIs, we have nothing. We just do a fetch to Stripe or we import an SDK. And WunderGraph has an opinion here. We say, we're not just an API gateway, and we're not just a framework. We try to be a package manager for APIs, and that changes everything because WunderGraph has the concept of API dependencies. So in WunderGraph, you can add APIs as dependencies. WunderGraph turns all your API dependencies into a virtual graph, which is simply a GraphQL API. And now you can treat all these API dependencies like

17:07 a GraphQL API that's only virtually exists because the moment you write a GraphQL query, we turn it into adjacent RPC API because we treat security. Like, security is super important for us. I think most people shouldn't expose a GraphQL API. So we kind of only use GraphQL on the server similar to SQL to talk to your API dependencies. And and that's, I think, the the outstanding thing. That's the USP. That's what makes WunderGraph so different than anything else. Okay. I'm gonna try and summarize that. And if I get anything wrong, please correct me. Yeah. So

17:45 Summary

17:51 WunderGraph gives me the ability to define external APIs as dependencies. I'm assuming I point to some sort of GraphQL API for introspection. I point to an open specification document to understand that API. I don't know if it supports other stuff. I know as there's the database support as well. Those all get created or exposed as a virtual graph and the interface for me and to other people to that virtual graph is GraphQL. However, you're parsing that GraphQL and then speaking JSON RPC to all the underlying APIs below. Was that was that correct? Did I get

18:31 everything wrong there? Almost. So, obviously, we talk the language of the origin to the origin. Yeah. Yeah. Yeah. Okay. But what we do is on the front end side, we create adjacent RPC API that we also have an an embedded code generator. So you define an operation, like, give me countries, give me weather, and combine that. And from that, we generate an RPC endpoint, and we generate a type safe client. Because one thing that I always found weird is, you know, GraphQL is amazing because it's so dynamic and you can query whatever you want. But the moment you deploy something to production,

19:15 you will never change your queries because your queries are not dynamic. Like, you have variables where you can put an input at runtime. But if you have a a view with your your user info view, you don't change the user info query at runtime. So why would anybody want to expose a dynamic API if you don't need a dynamic API in production? That's insecure. That's just, yeah, making the the the attack surface bigger. So that's that's why WunderGraph by default, like, just exposes JSON RPC. And that's amazing because from JSON RPC, we can also generate

20:01 an open API spec. We can generate a postman collection. So that means you add, like, three API dependencies. You create a couple of operations. You deploy that, and now you have a Postman collection, and you can give that to someone who wants to use your API. That means they can just load it in Postman, play with your API, and they don't have to learn GraphQL. Because I think a lot of people just want to use your API, and there should be as little friction as possible. And not everybody wants and not everybody will learn GraphQL.

20:37 Alright. Last question and then hands on, I promise. So you mentioned something earlier, back end for front end. Yes. I think this is a term that I definitely am not that strong with, and I'm assuming maybe other people in the audience may not be that familiar with or understand what you mean by that. But could you tell us a little bit more about that pattern? Yes. So like a very common pattern in in enterprise architecture is you have internal and external services, and then someone says we need a new project. We want to build an app. We

21:00 WunderGraph and the Back End For Front End (BFF) Pattern

21:11 want to build a website. And what you usually do is you don't let this website talk to all the services internal and external. Instead, you create a back end for front end, so a specific back end for this front end, and it will supply the capabilities that only this front end needs. And it's a very popular pattern. The problem is if you look at frameworks like Redwood. Js and others, those always assume we have a database as we're building something from scratch. And it's not optimized for the use case of we always we we already have APIs

21:56 like Stripe and Twilio and our database and Kafka and whatnot. And now we need an opinionated framework to build a BFF. So WunderGraph is optimized for this use case where you say, okay. I create I want to create a new front end, and we already have a couple of services because, obviously, everybody can build a back end for front end from scratch. Just use, like, Fastify or whatever you want. And then, yeah, combine the services and do it manually. But the question is, do you actually want to invent the right kind of patterns, and do you want to think about how

22:35 to actually build a BFF, or do you want to build on top of a framework that thinks about this topic for a couple of years and the makers behind that and figured out what are the what are the the important bits to to to do this in an efficient way. And this way, you can you can not write a lot of code. Like, you know, for from our business perspective, I I think as a business, it's always super important to write as little code as possible that has nothing to do with your business. And inventing patterns to create BFS,

23:14 that shouldn't be like, you shouldn't be doing that. Just just built on top of something that already works. Sweet. On that, I think we'll go straight over to the screen share, and we'll start showing people what WunderGraph can do. Let's see. What did we decide on again? Like, it's going to be you. Right? Yes. I think we agreed that I will do Yeah. Okay. And we're gonna work through some of the examples because there are quite a few and the WunderGraph model repository. Yes. I've got the website here and people can find it at wundergraph.com.

23:25 Beginning the Hands-on Demo

23:53 Is a whole bunch of documentation, but I think we're going straight to the GitHub repository. So let's get that. Yeah. WunderGraph and then WunderGraph again. And by the way, one thing I can mention is WunderGraph is a % open source, Apache two point o. We believe in a healthy community. And, yeah, there's no enterprise version or or anything. So everything we talk about, you can run it on your own. You can debug everything, the Go part, the TypeScript parts. It's everything is available. Cool. But you are launching WunderGraph close, right, to make it easier for people?

24:48 Yeah. So the what what we do is very similar to to Vercel. WunderGraph, the framework itself, I would call it, like, the the Next. Js for back end. And WunderGraph Cloud is, like, the the WunderGraph to make it easy to not do anything, just focus on coding. That's my preferred approach. So are we working through this examples directory? Yeah. So we have one example that's Next. Js TypeScript functions. So we recently added TypeScript functions, which I think is so cool. So you can go to that, and then you can n p m I, and I think n

25:33 p m start, and we should be good. Yeah. Let's try it out. Alright. So we have something running on oh, it's open to. Yes. So that's our our usual starter package. We already have an operation running on the main page. That's Next. Js, and we have WunderGraph running behind the scenes. So that means we have two services running. And, yeah. Maybe you wanna explore it a bit. Okay. So I'm not I'm not sure what I'm looking at. I'm looking at an XGS website that is used speaking to the WunderGraph API proxy. Mhmm. And if I push refresh, I'm not I

25:50 Exploring the Example Application

26:36 I I don't really know what's happening. So maybe you can Yeah. If you push refresh, it just Says validating for truthful. One nanosecond. Yeah. But the the SpaceX API, it's I think it's static. It's just a popular example when you use a GraphQL APIs, and that's why we put it here. Yeah. So this is calling the Dragon's operations endpoint on some service. Exactly. Alright. Let's take a look at the code. Maybe that will help me. Okay. So when we push the refresh button, we're calling dragons.mutate. Dragons is using use query from the WunderGraph generated SDK,

27:23 Dragons

27:39 I guess. Mhmm. And I don't know what the operation Dragon is coming from, but I'm assuming there's something in here that defines that probably in the GraphQL schema. Is there a .WunderGraph directory somewhere? There is. It's just very small because the size of the explorer, but it is here. Yep. And I see operations. Okay. Okay. So you're proxying the SpaceX API. Correct. Okay. And here's something interesting. If you look at line two. Oh, yeah. You can make it a bit bigger. That would definitely help the audience. You see that k. I I I don't know if you know the the SpaceX API,

28:07 API Introspection and Configuration

28:33 but the SpaceX API itself, it is it has the root field dragons. But here, we see SpaceX underscore dragons. And if we go to the wundergaf.config.ts, we can get some hints why this is happening. So here, we are introspecting the APIs we're using. Dragon starts from the SpaceX API, and one concept we have is API namespacing. So when we started exploring like, this is kind of like, I don't know, a year ago or something. When we started exploring to automatically combine APIs, what we quickly found is that when you try to combine multiple APIs, you

29:19 run into naming collisions. And so to mitigate that and to to not have the user manually change APIs or or have to rename stuff, you can put each API into its own namespace, and this way it's isolated. So that means if you go to the generated folder, we can actually look at the the resulting GraphQL schema when we combine everything. There's a GraphQL schema file somewhere. It's the only GraphQL file. Yeah. And then if you go to the search for the type query, then you can see our entry points. Yes. And here you can see, okay, we have

30:00 the SpaceX APIs, and if you scroll a bit more, then you see here's countries and then weather. And each of them is in their own namespace types TypeScript. GraphQL has no namespacing by itself, so we can fix that on our own. Okay. Do you expose, like, GraphQL playground at a graphical or anything like that for me to play around with this? Yes. You can go to local host port nine nine nine one slash GraphQL. Okay. Cool. So if I type query, and I'm assuming the documentation oh, nope. Wrong button. How'd you get the documentation to show up?

30:23 Graphql

30:58 Good question. Question. Here. Yep. So I could query SpaceX ship. I don't know why my autocomplete isn't working. It normally works on this ship. Oh, ships. Okay. Let's do ships. So this is a list of all the spaceships. Right? Mhmm. And we can get active class. What else? Mission. Oh, no. It's gonna be a nested object and I don't wanna have to find the docs for it. So let's do this. Cool. So let me try and understand then. This GraphQL starter thing that we have here is configured by the dot WunderGraph directory where we have this operations file.

31:53 Supported Data Sources (Databases, OpenAPI, etc.)

32:07 Nope. Not that one. Where did it where was API What what when the graph config Yes. So here you can define any GraphQL API, have a introspect and then make it available over one single API endpoint. This is what this demo is showcasing. How we could speak to a country's API, a weather API, and a SpaceX API, expose them over one API for you to query. Yes. And if you make, like, a new line here and you type introspect and dot, you can see we can also introspect Apollo Federation, MongoDB, MySQL, OpenAPI with a file so we could supply an

32:58 OpenAPI file and then PlanetScale, Postgres, SQLite, and SQL Server. Okay. So these are the compatible data sources we can introspect and add to our virtual graph. Nice. Okay. Well, not just GraphQL. I could speak to a whole bunch of databases, Postgres and MySQL being pretty popular, PlanetScale's in there too. And I guess MongoDB for people playing with Atlas. Yeah. It's pretty neat. So you mentioned like these get versions. Like, how are these versions? Like, you talked about them as sorry. Not version, but as dependencies. Right? So is that what you mean when we say we break this in as a

33:23 Database

33:44 dependency? Yes. So you introspect them here, and then at the bottom in line 30, you see configure WunderGraph application. And here, we can add our APIs, and then we can configure code generators, course for a our API gateway. We can configure authentication, security. For example, here, we can enable or disable the GraphQL endpoint. And, yeah, at the end of the day, this gives us our API gateway. But as I said before, you almost don't notice that you're using an API gateway. Okay. So I'm curious because this was obviously an example from your repository. If I am a developer tomorrow and I

34:34 want to bring WunderGraph into my application, how much of this is generated and how much of this is stuff that I need to type to, you know, provide the boilerplate and the glue for this to work? Yeah. So the generated folder is generated. What you need is the WunderGraph config TS and the operations TS, and I think there's a third file. It's just a bit small. Here, you can configure defaults for your operations, for example. Yes. And this one is the hooks configuration. So, for example, if you want to do something before or after the Dragon's operation is being called, you can

34:51 Project Structure and Generated Code

35:21 define hooks here using TypeScript, and then you can hook into the life cycle of an operation. So we have a command. I think it's something like Wunder CTL in it or something similar. I think create WunderGraph app in it, and that scaffolds you these couple of files. And that's more or less what you need, and and the rest is just, just, yeah, NPM start, and everything else is is generated. So it's it's pretty lightweight. Okay. What are these operations then? Like, if we've already introspect the remote APIs and we've got the ability to query them,

35:53 Operations

36:02 what what is the operation? Is that as constraining the different types of queries or or I don't know. I'm I'm not gonna guess. I'll let you go. Yeah. The operations folder defines our JSON RPC router. So for example, we have in the root, we have I don't know. It's so small. It's like countries. Right? Yep. Countries, dragons, or weather. Okay. So if you open a curl in terminal and you do http colon slash slash local host nine nine nine one, and then slash operations, and then dragons. Yeah. With capital d. Sorry. Now we're calling this file, more or less,

37:11 or we're calling the operation that was defined in this file. Right. Okay. And you could also do you have a Postman installed, by the way? No. No. Okay. That that's unfortunate. But I I can just tell you, if you go to the generator sure. I could do a preinstall Postman. Okay. It won't take long. Yeah. We can use the time. Go to your go to your playground where you created your own operation because you can have your own operation. So copy this thing here. Yep. Yes. And now go to the operations folder, create a new file, and let's call this

37:41 Creating a New Operation (GraphQL)

38:02 ships or whatever you want inside the operations folder. Right? Yeah. Ships dot GraphQL. That's the convention. Okay. Save it. Great. And now let's call ships in call. Ah, Rawkode. Okay. Yeah. Yes. That's Yeah. Okay. So that's the the bit of information that I think was important there for me is because when we have this graphical playground, the graphical playground style setup, we can make any arbitrary query we want against any of the APIs that have been introspective or made available via the proxy. But actually, really what these people what developers should be doing is defining all the different queries as operations

38:52 and consuming them from the RPC API and Yes. Rather than speaking directly. Yeah. Go go to the front end code, like the where you've called the Dragon's API from the front end. Yes. So when you go to operation name and you you remove dragons and you trigger auto completion Oh, hey. That's cool. That's Rawkode. And now if you check, for example, in line 10, you make a new line and you check what dragons contains data, And you see what data is actually inside this thing. Hey. That's pretty nice. And, you know, now the audience would think, yeah, yes, cogeneration

39:01 Frontend Client and Type Safety

39:58 exists. Sure. Everything exists. It's just a question of do you want to care or do you want to have something that just works and that figured out all the hard details? And for example, we we don't reinvent the wheel. We integrate with SWR and React Curry. So we have other examples that wrap WunderGraph, the WunderGraph TypeScript client, which is TypeSave, and we wrap this with SWR and React Query. So you get the benefits of React Query with WunderGraph RPC functions. And you can you can just call your virtual graph and you you know, if you look at this, you

40:42 might be thinking I'm doing GraphQL. Right? It it looks like GraphQL. It feels like GraphQL. It's not GraphQL, and you don't care. And it's secure. And for example, if you define a an input, go let's go back to that's a great exercise. Let's make this more dynamic. Go to your Rawkode operation. Does SpaceX ships? Does it if you if you does it have any kind of input? Like, can we can we on ships, can we define any kind of dynamic parameter? Let's see. Yes. It's got find and it's got limits, offsets, and sorts. So I guess we could

40:56 Making Operations Dynamic (Variables, Input Validation)

41:31 Let let let's just add a limit or something. Okay. So let's test this works. Let's do limit five. No. We we need to define a I I well, I just wanted to make sure it worked in this API first. Okay. Okay. Right. Yeah. Okay. So this is our new operation. Make it but not not hard code. Make it a variable. So you define a variable after query. Okay. You know GraphQL bit. Right? Yeah. Are you not the variable starts with the dollar. Yeah. I I I can't remember the exact syntax, but it seems to be yelling at you.

42:20 It is offset and then colon, and I guess it needs to be int. Oh, yeah. Okay. Cool. Yes. Is that correct? It's just claiming that it's a capital I. Capital I. Yep. Okay. And those are optional? Right. Okay. Copy this into your Rawkode operation. Okay. Save it. Now let's go to curl and run it again like before. Okay? And, like, go cursor up so we can type it again. And then add a current parameter offset, for example, or whatever it was. Did that work? May maybe we need to do, like, limit, I think. Yeah. Let's do one.

43:29 Yes. So now we've created a rest API that takes those parameters. Try to set limit equals true. That's a bad request because we have JSON schema validation on this endpoint that validates it must be a number. Okay. I wanna make sure I understand this correctly. Every time we define an operation, we're writing GraphQL as a way to spec whatever APIs are being stitched together by the API proxy. Behind the scenes, this is actually generating the TypeScript SDK or client based on all of the type inferences that can make against those different things, Which is why we have the ability

43:58 Customizing Operations

44:23 to say from here to understand what this actually returns. I'm How do I can I add the limit as a query parameter to Yeah? That that should be field. It's called, I think, input. Yep. And it's all typed as well. That is really cool. I like that because then I could just I I don't remember how to write code anymore. I don't know if I say that enough, but I rely on Versus code and language server protocols and type systems more now than ever. And I've been doing this for twenty years. Like, it just I

45:06 I now just fall back on it because it's just so easy, and it's usually smarter than I am, which I really appreciate. So yeah. But, you know, let let's say so now we have this operation. And let let's say the result that we're getting back, it is not making us happy. We we want to customize it. We want to do better. We should go fully custom because we want to manipulate the data before returning to the client. Right? Okay. Let's create a TypeScript function to do that. So if we go to our operations directory. Mhmm.

45:16 Creating Custom Operations with TypeScript Functions

45:47 Create a TypeScript file with a unique name we didn't use before, so not Rawkode again. And Jens. Yance. Okay. Awesome. And then you start typing create export default. Sorry. That's a convention export default. Create operation. What's a create operation? Just type create operation. Yeah. Import this and then dot query and then function with input and stuff. Yeah. Make an object, create a handler. It's an async func that takes yes. Copilot is kind of driving. Copilot is great. And return an object like hello or whatever you want. Okay. And save this. Uh-huh. Awesome. And go to your front end

46:57 code and call Jens as operation name. Now we're getting the the our inputs are invalid. I'm assuming because there's none. So Just remove. Yeah. Okay. So does that mean we can That's our front end now. Yeah. Call it. Let's call it. Yes. Okay. So before, we were like, okay. We're talking API dependencies. Now we want to build something custom. And next step is you put it together. So you go back to your Yen's function, and there you have the CTX. So make some room for a CTX dot internal client dot query queries and then Rawkode.

47:26 Calling Internal APIs from TypeScript Functions

48:02 And that's an async thing. Yeah. Limit to whatever you want. Okay. And put it into an object, like, const what you want, and then you can do some manipulation. It's yelling at me because it's the potential undefeigned nature, obviously. Ships is ships? What I'll do is add just a response data. What's that? Oh, it could be undefined. Alright. Well, TypeScript is pretty smart. So as long as we say, return blah, that frees this up. And we can map over all the ships and join. But I could just join. I could not. No. Because I need the name.

49:16 I think after ships, you need a question mark. But the map should work over and I the map should work on an empty list. Right? But it's not an empty list. It can be undefined. Oh, yeah. Let's try calling this. Alright. Let's change the limit. Cool. So using these completely TypeScript based handlers, we can call any of the other queries through this internal client, which gives us back the typed response. We can mutate that data however we want and then spread it straight back in. That's pretty cool. Go to your front end code. Uh-huh. And

49:58 Adding Input

50:18 add an input. Like ah, no. We we don't yet have an input. Right? Let's let's go back to the to the function. Let's go back to the function. Yes. Yeah. Add an input, and that's a Zot object. So besides import, create operation, after create operation, just add comma Zot. Mhmm. And then create an object. And here, we can we we could make a limit, like and make it a number. Right? Yeah. Z number. Okay. And then instead of passing five, pass CTX input limit. Yep. Go to your front end. And add the input object. Okay.

50:20 End-to-End Type Safety (Zod Integration)

51:20 Submit. Does our front end work? No. Because we changed the data structure. Oh. Although it's actually not complaining about the data structure. It's complaining about random other stuff. So maybe it does work. How do I get to the front end? It was Local host CK, I think. Yeah. It's working. Okay. And now something interesting that we where we took some inspiration from tRPC. If you go back to your function where we call it the the input for example, if you change number just out of like, it doesn't make sense, but change number to stream and go to your front end code

52:23 no. The front end code. Sorry. And go to the input. You will see it pops an arrow immediately, and that's because we're exposing or we infer the TypeScript types from the Zot object definition, and we export it with export type and import type into the front end behind the scenes. Like, you didn't see that. If you look into generated Next. Js, you will see it actually. But we have a direct connection between front end code and and back end code, and that gives you this immediate feedback loop if you're creating TypeScript functions. Yeah. That's one of those big selling points

53:11 about tRPC that people always rave about is the fact that you get this consistency across the types for back end and front end. And it is it's Yeah. Very cool. So what what you get here is a smooth transition between oh, I just create I I I just create a graph to operation. That's enough. Until you reach a point where you say, it needs to be customized. I need to call five APIs and combine them in a certain way, and I want to manipulate the data because it's not in the right shape we need for the front end.

53:49 And then you go the TypeScript route, and you can always choose, like, what is the way to go. But you see from the front end experience, like, front end client, it doesn't didn't change a bit. It is the same experience, and that's what we're trying to do. We try to make a very smooth transition between I'm just calling a service and it's fine. The way the data comes back is okay. Two, I need to build something custom. But from a client perspective, it's the same interface. Nothing new to learn, nothing to change. Yeah. It's it's really interesting because WunderGraph

54:25 Competition

54:27 is in this space where I can't really work out who it competes with because it does so much. Like, do you, you know, as a founder, right, do you see WunderGraph as competing with the likes of Hasura or with TRPC with with both with Take? Like, what where do you where do you position it? Where do you feel that this is? This is a WunderGraph question. WunderGraph is in the category where you collapse seven tools into one, and you're like Yeah. I you know? So I'm now, I don't know, more than ten years in in IT,

55:13 and I learned so many things about, this is what I said before, why I created WunderGraph. So many things I hate doing, because it's boring and repetitive. And WunderGraph is the result that gives you in the end the stack where you where you don't have to do the the mundane things again. Like, you know, the way we just transitioned between TypeScript and GraphQL, the same way you could now add an OpenID Connect provider like all zero, and then you have authentication. And what is special about WunderGraph here is we kind of, in some way, like obviously,

55:56 it's not the the main purpose, but we are similar to something like Firebase, but we don't dictate a specific back end. You can you can say, I have my GraphQL. I have my REST. I have my database. We don't tell you where those need to be and which provider. We also don't tell you what authentication provider to use. It could be Azure. It could be Clerk. With WunderGraph, you can glue it together in a coherent developer experience that feels like it is Firebase, but the components can be anything that you bring. And so we we're kind of like an anti vendor login

56:42 login tool. At the same time, it feels like we are a vendor lock in tool because it feels like it's one experience, but you can bring the components, you know, if that makes sense. Yeah. Definitely. So I'm trying to think of some use cases that I think are quite novel and interesting here. One of the things that always frustrates me about GraphQL is aggregate root functions, like trying to get counts while creating data. I think it's very difficult to kind of stitch those things together. I'm curious, can we can we try and do that with WunderGraph

57:29 and see what others like? What I mean is what I'd really love to be able to do and this might be so easy that you're just gonna go like, sure. But what if we query all the dragons, get in their names, but also return the number of active dragons as well as the number of total dragons. Like to me, if I were doing this with GraphQL, it would be a bit of a pain. I'm curious if we can make that a nice API with Wunder Graph. Does that make sense? Yeah. I get it. But I I would love to show off

58:04 Demonstrating Cross-API Joins

58:09 one feature of WunderGraph. Maybe we can do a cross API join. That sounds even more exciting. Let's do that. Okay. Can you go to the WunderGraph config TS? Want to check if we have the dependencies we need. Okay. We have countries. We have better. Okay. Let's create a new operation. We call it join. Alright. Is that a TypeScript or GraphQL operation? GraphQL. Okay. And let's start with countries. Countries and then countries. No. Just do countries country. Otherwise, I don't want to make too many API calls. Yeah. Country. ID, name, and capital. Alright. So don't think IDs are too much.

59:14 Yeah. ID is cool. And it takes a parameter, I think, the country code. Yeah. Code. Make that a variable. I think it's ID capital ID. No. No. No. The instead of string, it should be capital ID. Oh, sorry. Alright. Okay. Yeah. ID is a very weird scalar in GraphQL because it can be according to the specification, it can be a string or a number. Like, it's kind of like a union. You know, we we we're talking about input unions for seven hundred years already, and they still are not in the spec. But we already have an input union, which is ID.

1:00:07 It can be int or, yeah, number or string. Okay. So that's our starting point. Let's curl it. Or no. You installed Postman. Let's Postman it. Now it's time for Postman. Okay. Click import. I've never just put some before. Give me a moment. Where's import? Oh, there we go. Oh, yeah. There. And select our generated directory from our project in the examples thingy. What's it called? Dot oh, dot WunderGraph. Right? Yep. It's not finding it. Are you in the directory of the project? No. It's in the examples. Yeah. Yeah. Alright. Okay. Yeah. Yeah. Examples then types Next. Js TypeScript functions, I

1:01:31 think. Generate it. So the whole generated directory? No. Generate it. There should be some file a JSON file with Postman in the name. Like, I don't know, something postman collection. Directory, so maybe we need to do this. Oh, come on. How do we show dot files on this thing? Control shift dot. Control. Alright. No. I don't think it I'm gonna Google it. Mac OS finder tool dot files. Or is it command shift dot? Let me check. Maybe it just doesn't work in this little. Was let's drag it in. Yeah. You can drag it also. Who'd have thought Mac OS finder would be

1:02:53 our downfall? Yeah. It's okay. So dot fails work from here. Just not in that little thing. Okay. So generated and then we wanna post man JSON. Yeah. That's good. Cool. And then pop up WunderGraph queries. And what was is it to join? Okay. And now you can call. Ah, yeah. You need to click the button for code and put some code. Okay. We have London. That's the starting point. So that that's that's for the people who like to share an API they've created. So WunderGraph, by default, creates a Postman collection in the generated folder from all your operations. In that

1:03:50 way, you can send the Postman collection to your to your users, and now you can they can explore your your REST API you created. Nice. I like it. So now we're gonna add the weather to this. Right? Yeah. Now now we want weather for a capital. So after codes, you make a little space, and we need new variable, which is going to be no. After code in the in the variable definition. Yeah. We make a city variable, which is a string. And after the variable, we type an at at internal. No. Not internal operation, just at internal.

1:04:37 Yes. Okay. That makes that's something it's a it's a convention. But this means we now have a space to store something. And after capital in line four, you can now write at export right behind capital In line four after Capital. Not before, after. Sorry. Bet you went through it. Done the typing, though. Yeah. It's a it's a yes. Just follow Postman. Copilot. Copilot. Yes. So when we execute the field capital, we export the value into the variable. Oh, not capital, but city. Export it into city. Okay. And now we use another feature that is WunderGraph specific.

1:05:38 So make a new line after line four and type underscore join. Yes. And then, like, braces and stuff. And what it does is join embeds a second query type. Like, remove this on stuff. It's wrong. Like yeah. So this embeds a second query into the first. So now you can start with weather. Weather gets city by name, and then, yeah, just pick some fields. Weather, blah blah, summary, temperature. I think you need to select on summary. Description. Yep. Icon title. This is Yep. Wind. Okay. We get it. I have a query. Cool. Okay. Save this. I don't have to look

1:06:55 up any documentation for this API whatsoever. I was just all complete in my way through every moment. That that's that's fun. And by the way, the more you use the more you use Copilot for this, like, for me, I don't know why, but for me, it's auto completes weather and stuff automatically. Like, it somehow knows about these APIs already. Okay. So let's go back to Postman? Yes. And just call it. Yeah. That's it. We joined two APIs. Nice. It's almost like magic. Almost. Like, it's it's kinda like a join, but not tables, but across APIs.

1:07:21 Testing the API with Generated Postman Collection

1:07:49 Yeah. And it just reflects the structure of this this query here. So I'm assuming, like, the GraphQL approach, you can throw these things together pretty quickly. And if you want to change the shape of it, you just create the TypeScript function and call it that way. Because I'm assuming we could do the exact same in TypeScript with, let's see. So if I wanted to get the city I'm feeling too brave now. That's just gonna be my downfall. Country input codes. I'm not gonna worry about the variables. So that should fetch my city and then I could do weather.

1:08:40 And there is a question coming, but I'm trying to get through this first. City, which is going to be our city dot data capital name, or maybe that is the name. Yeah. Mhmm. And then my response could just be whatever shape of data I want. So we'll call this capital and temperature. It's complaining. It's it's ridiculous. City is probably requesting a string, not string, or undefined. Right? I mean, I guess I could just default this to the Something is wrong with weather and temperature. Oh. Ah, can see by name. You see, Copilot needs to learn a a

1:10:03 little more about what you're doing here. Okay. So now our Yen's API could take an input, but I've hard coded it to GP, which is then gonna go fetch the weather. And then I define the shape of the data that gets turned back to the client. So if we come to Jens I broke it. No. You need to put an input. You're ignoring it, but it's still in the in the JSON schema validation. See, this is very interesting. Like, that was just so easy to decide that I want to expose two bits of information to people when they give

1:10:48 me a country code because I want to tell them the name of the capital and the actual temperature. And I could just dictate that. Like now we have the system. You know, let me back up a bit. So I wanna make sure that I get the importance of this in my header graph. It's like, we have this divide. Right? And I'll use a product like asura as a demonstration here. Right? Really great product, but very operational centric. Like, you know, some team manages that. They connect it to a database to define the schema. Like, a front end developer is not going

1:10:58 Advantages of Code-Based Configuration

1:11:24 to come along, modify the Hasura metadata to expose the data that they want in the format that they want, etcetera. But WunderGraph changes that because we have this TypeScript API to everything, which is very familiar to both back end developers, full stack developers or front end developers. Where it can coexist in a model repository with a generated client let's say by say, is that the front end developer can come along and say, actually, I want an API endpoint that returns data as it looks like this. They stretch a few things together and they've got what they need and they can

1:11:53 do it all in the same pull request and update their client code at the same time. And that's an enabler that I just don't think these other products offer in this space. And I hope that that makes sense to people and it's not just waffle dribbling out my mouth, but it's just such a powerful feature. Yeah. You know, one more thing. Now go to the front end code and check what is the response shape gonna look like. Like, here, we call Jens. So it's the name is dragons and check what is the the response type of dragons. So if you

1:12:27 in line 15, if you type dragons or here yeah. Data. You see you have capital and and temperature. That's what we returned from our API. Mhmm. Nice. I could have a lot of fun with that. Yeah. Alright. Sorry. I just see everybody's comments trying to tell me how to show the the dot fails. Thank you, everybody. Yeah. You have a helpful community. Yeah. Alright. Abdul saying, and no need for a GUI like Hasura. Yeah. I mean, Azure you use the web interface to configure everything or you can use your YAML metadata. It's a bit awkward

1:13:15 and especially for me when I do want everything to be code. It's like my my default now is just gonna be not to ship Azure anywhere and just to create a WunderGraph API because then I have this dynamic ability to duplicate my queries if I want with different names, version them if I wanted to because we could do that as code and change the shape of things by writing these TypeScript handlers. Like, it's just very nifty. I think it alright. You know the the Sorry. I only go. Just just to comment on this. The problem with

1:13:48 user interfaces is if someone wants to replicate what we just did, you just type the code. You can you can follow the code. If we had to click buttons, you cannot store button clicks in Git. If you want to follow what we just did here, the combination, the the all this stuff, you can now put it in a Git repo, and everybody would understand how we change these operations, how we define the Yance operation. Like, everything is in Git. It is versioned automatically. If you click buttons, you first have to think about, okay, how can we do, like, a

1:14:32 revision or embed a revision system into the user interface so that people can understand what changes were made to the system last night because this morning, everything is breaking? Yep. So everything in WunderGraph, everything you change to your WunderGraph application, it's visible because you it's code. You put it in Git. There's there's no GUI because I don't want a GUI. You know, everything we just did, we we always kept typing, and it was efficient. And we have this is what I said in the beginning. TypeScript is the interface for developers. It's the perfect developer interface. We don't need

1:15:14 buttons or GUIs. We we need good TypeScript definitions so that we don't have to think about what is limit. Is it a number? The IDE tells you. You, you know, you can just type away. Also, GraphQL with its amazing auto completion, just type away. You know? Alright. We're getting pretty close to time, and I've been I've been showing things that I just thought were interesting. Is there anything else from these example repositories that you would like to show people before we finish up today? No. I think we're pretty much at the core. Like, you could now add

1:15:54 You could add more services like federation, stuff like that. In the end, the the DX would be very similar. Like, you know, you have use query here. You could also import use auth. And whatever auth provider you add, you can just call it. You don't have to add any other dependencies. No. I think we're we're ah, Ray just mentioned directives. Yeah. Okay. We we can talk about role based access if if you want. Like, okay. We we don't have enough time for adding authentication now. But if you go to one of the operations, like dragons,

1:16:20 Role-Based Access Control (RBAC) Directives

1:16:33 for example, And after dragons, you type at r back. Yes. And then open, like, open the function. Yes. And you could say require match all and make an array. And inside this array, admin. Yep. Save it and call this function, and you will see it will not work because we don't have role admin. Four zero one. Yeah. So you could now add an authentication provider, and we have a callback function like a hook where when someone authenticates, you can write the TypeScript function to give them roles, and you can define what roles exist in your realm.

1:17:32 And now you could say, okay. If my name is Rawkode or my email is something Rawkode whatever, I give myself the role admin, and then you would be allowed to actually use this this operation. But Yeah. Must admit that's possible in in a TypeScript too. Type you can write CTX user, and you can say roles. And Or includes. Yes. Something, I guess. How do I return, like, a four zero one then? Yeah. That's the missing feature I'm currently working on. Alright. Like, we released functions Tuesday this week. Oh, wow. And Okay. So that's pretty fresh off the okay.

1:18:33 Yeah. Yeah. It it's it's pretty fresh, and we need to add a way of returning unauthorized. But yeah. Oh, I've got if it does include admin. Okay. So so that should give me an error. Yeah. I think it will actually time out because we're we're not yet properly handling those errors. You you you caught us on the on the alpha stage here. Hey. You gave me TypeScript functions, and I I wanna start using them for everything now. So I'm gonna I'll get a feature request in for the ability to augment this Alright. That's awesome. Let me put us back into

1:19:18 WunderGraph Roadmap (Cloud, Machines, Events)

1:19:18 to big face mode. So what I would say is if you have any questions and you're watching, you've got a couple of minutes to drop them in to the chat. Well, Jens and I have a quick conversation. So just first, thank you. This is a really cool project. I've got so many different cases that I want. Literally, you know, I reached out because I was experimenting with using this. Have real things that I want to do with it. And I just thought, you know what, this is cool. So thank you for spending time with me

1:19:47 today and showing us this. And why don't you give us a little bit of a flavor on where you're going with WunderGraph? Like, what does the next three months or six months look like? What are your priorities? What's coming down the line for people that are curious? Yes. So in the next couple of weeks, we launch the so our cloud is currently in alpha stage. We launch our cloud to to beta, which means from like, you now have a repo with the dot WunderGraph folder. And in in WunderGraph cloud, you select this repo from your

1:20:27 Git repo, and then everything gets deployed automatically in whatever location you want. You get analytics. You get edge caching. You get, like, what you would expect from an API deployment thing. And what's on the road map is, like, we want to bring collaboration so we can work with the team. We want to closely integrate with services like Vercel. So your front end on Vercel, your back end on WunderGraph. And another from super important thing for me is when you integrate APIs, what is kind of like apparent is it doesn't always work. Like, let's say you have an operation.

1:21:13 It needs to call into three services to to to complete the workflow, like get some data from Stripe, put some data in your database, and then call another service to to send an email and and whatnot. And this can fail sometimes. What we are also bringing to WunderGraph is something quite similar to temporal. So I call this feature WunderGraph machines, which will be resilient state machines, essentially. So background workers, but not background workers as you think, like, much more elegant, kind of like a React component, but it's a state machine. And you can retry things, and you can

1:22:02 design long running operations and workflows and and crons. And we will also be adding an event system, so like a pops up system where you can, for example, send an event to a WunderGraph machine, and it can react to that because it's a state machine. And you can subscribe to events by a state machine, which gives you a whole new way of designing applications. And all this, again, TypeScript interface, very elegant. You can call it from your functions, etcetera. And the the the real purpose here is to you know, most people, when we talk about APIs, we

1:22:42 talk about, okay. Let's create some cruds things, and that's that's really the simple stuff. But what the developer experience, I want to create is resilient, long running state machines where if a user signs up with your SaaS application, you can actually create a state machine for this user, and you can send events to this state machine whenever you want, and this can transition the state machine into different states. Like, for example, if you want to to create something like, you can have a state machine for your organization. And if someone wants to join this organization,

1:23:24 you can send it an event. So in a a state machine or a WunderGraph machine, it will have, like, a storage. And it's what's also very important is it's going to be serverless. So you don't have to think about where does it run. Does it actually run? Is it sleeping or or whatnot? Because it can sleep, and it will cost you nothing if it sleeps. And the whole thing is to rethink APIs and and workflows because sometimes, you know, when we do a deployment in WunderGraph, what we do is we go to fly.io. That's our the provider where we run our

1:24:02 stuff on, and we do a bunch of API calls. Like, we create an app an an application. They call this application. Then you create a fly machine. You have to build an image. You have to deploy that image, and this takes for the first run about two minutes and subsequent builds around, like, twenty seconds. And this is a very long running operation. And similar to temporal, we want to allow you to build in a very, like, elegant way, kind of like React components, but without returning HTML, just return state. We want to allow you to build resilient

1:24:44 state machines so that you you can define workflows. You can define crumbs. You can, yeah, just define state in your opera in your application in a whole new way, and it's going to be fun. Like, you know, it's it's such a pain in the ass if you want to build something like WunderGraph today, and you have to integrate with partners like Fly, you have to. It is so hard to build resilient functions. Like, you cannot just call Fly and everything flies because sometimes it doesn't. How do you retry? How do you and, of course, I can have temporal, but now

1:25:27 I need someone who understands temporal and deploys it. Or do I use the cloud, and how do I embed it into my thing? And what I really just want to do is, you know, I call my from my front end, I can call the function. And from my function, I can call a WunderGraph machine, and that's everything I need. And so we really try to to unpack the hard things into super simple solutions that everybody can understand. And I think even a front end developer with some experience will be able to build resilient workflows and long running operations

1:26:03 with WunderGraph machines. So that's what's going to come in the next month. And the next month? Wow. Or months. Yeah. Months. Alright. We'll definitely have to get something else scheduled then to do a follow-up. I would love to. That would be amazing. I have one question in the comments, and then I'll let you go because I know that's also getting quite late for you over there. But Abdul is asking, what other data sources are on your road map for WunderGraph? Yes. So currently, I would say something that is very interesting for us is gRPC and async API

1:26:24 Roadmap: Additional Data Source Connectors (gRPC, Kafka)

1:26:45 or more specifically Kafka. So super interesting. By the way, we also want to expose gRPC from WunderGraph. So recently, we thought about, like you know, we have those those JSON RPC operations, which we currently like, we have our own spec, how we do JSON RPC, and we can create a Postman collection, it would actually be quite simple for us to also add a gRPC endpoint, which means everybody who can generate a gRPC client in Python, Ruby, Java, whatever, can call your WunderGraph API. So you get a hell lot more options for people to call your API. I think

1:27:31 that's amazing. And regarding origins, yeah, I think Kafka and and message brokers like RabbitMQ, super important that you can go, like, async. And also gRPC just as an internal system. I think that's that's very important. By the way, one one thing I forgot to mention for the road map is we are also going to be focusing a lot on WunderGraph help in the future. You know, when we started talking it, I I spoke about API dependencies and the API package manager. And one one core feature of WunderGraph that we wanna focus more in the future

1:27:51 Roadmap: WunderGraph Hub (API Sharing)

1:28:16 is actually sharing APIs. Like, when you do introspect GraphQL and introspect something else, it means that you need to be able to introspect those. But what if someone could just share an NPM package with you, and that's your import, and it will be type safe out of the box? So what we're building is like an NPM for APIs where I can build a collection of my internal APIs, publish them to the hub, and the rest of my team or another company, they can then import those APIs and add them to their retrographic. That's that makes

1:28:55 using and reusing APIs a lot or or sharing a a lot easier, and we we want to to definitely also focus on on that end. Yeah. Just give people a way of sharing APIs. You know, sharing is caring. Awesome. Well, thank you for sharing that road map with us as well. And it's great to see I mean, there's a lot of really interesting stuff there that you're trying to tackle. The state machine temporal thing is something again that resonates. I think we play with all the same technologies. That's that's what our current team I'm seeing here is that we have

1:29:14 Conclusion and Final Remarks

1:29:29 very similar interests. I host my own temporal cluster on a Kubernetes cluster. And it's hard. And but I want the semantics because temporal has this concept of activities where you have this guarantee that things could be retried if they fail and and really strict error handling. And I do want an easier API for that. Like, I don't want to host my own temporal. So consider me user number one for when you have something there with the the state. You know, we we just defined a TypeScript function. Right? And I believe creating a resilient workflow should be as simple as creating

1:30:05 another TypeScript functions. And with WunderGraph Cloud, you don't deploy anything, and you you don't even switch context. You just create, like, a I don't know, export default, create machine something, and it will be resilient. And that's just it, like, yeah, don't worry about stuff. Get you you know, like, for your business purpose, how much does it actually matter? And is it not a waste of time? And we know the answer is yes, that you run your own Kubernetes cluster and temporal. Like, you know, it can break. You have to understand temporal. Maybe they there's something, like,

1:30:46 you need to patch it. Like, I guess it's a great exercise for you to run it on your own. And I don't know. Like, running Kubernetes on your own is, like, such a pain in the ass. Like, everything can go wrong. And if you're building you know, this is the thing you've you only learn if you're a startup founder. You have so much pressure. You really want to outsource everything that has nothing to do with your business. So for us, I would never allow anybody to run a Kubernetes cluster if we if we are not past, like, series a or something and

1:31:24 we have so much money that we really don't care. You know? I mean, teaching people Kubernetes is pretty much where 90% of my income comes from helping people operate Kubernetes. So I I really do need to be good at it. So Okay. Yeah. That in in that case, oh, obviously. Sure. It as a teacher, it makes sense. But temporal, though, I don't I don't have to be running my own temporal cluster, and I prefer not to. But I am I I've loosed the pricing of temporal cloud and like fuck that. Like, there's no way I'm giving them that money when I

1:31:54 can fight it myself. So alright. Again, thank you so much for spending time with me. Really cool project. We'll definitely reach out in a month when you have the state machine stuff ready. I'm gonna hold you to that date now. I'll set it up a flyer somewhere and we'll get Yes. Scheduled. But have a wonderful evening. Go spend some time with your kids if it's not their bedtime yet, and I will speak to you again soon. Thank you, man. Well, super cool. Have a great day. Bye.