logo
Menu
The .NET on AWS Show, Featuring Michael Staib!

The .NET on AWS Show, Featuring Michael Staib!

In this episode we are joined by Microsoft MVP and founder of ChiliCream, Michael Staib

Brandon Minnick
Amazon Employee
Published Feb 27, 2024
Last Modified Mar 15, 2024

Listen to the Audio Podcast

Audio Podcast Image Link
Audio Podcast

Watch the Live Stream

Loading...

Transcript

Brandon Minnick 1:06
Hello, everybody, and welcome back to another episode of dotnet on AWS. I'm your host, Brandon Minnick, and with with me, as always is my amazing co host. Francoise, Francoise, how's your week?
Francois Bouteruche 1:21
It starts very, very well. So happy to join you today. It will be a busy week because it's this week. It's area Summit, London. So I will be at the AWS summit London. So you can find me at the AWS developer booths at this summit. So if you're in the UK this week, come on, and let's have a chat.
Brandon Minnick 1:47
Yeah, that's right. So for anybody who hasn't heard of an AWS summit before, what what is this? What is this summit thing?
Francois Bouteruche 1:54
Oh, so Summit is kind of areas conference where you can go, you can go there you can you have they start with a keynote from one of our leader. And then you have different tracks where you can select, pick and choose your breakout session you want to attend to learn more about AWS. So it's one day all about AWS to learn more. And you will also have the expo area where you can meet our butter or meet us at the AWS developer lounge. You can also try workshops, you have a game day. So a lot of a lot of content, a lot of experience so that you can learn more about AWS. So one day full of AWS for builder.
Brandon Minnick 2:49
Cool. Love it. Yeah, I've only been to one so far. I've went to the one in Sydney a couple of months ago. And they had a big like almost computer workshop station setup where you could just learn and do things on AWS their real time is are we going to have that in London to
motivate us Francoise there is
Francois Bouteruche 3:30
no issue. So yeah. Okay, I think we're good. No, we're good to go. So yeah, yes, we will have workshop we will have a workshop.
Brandon Minnick 3:45
Cool. Yeah, come swing by the AWS summit in London this week. Learn all the things about AWS meet all the folks working on AWS and we have our dotnet booth there as well Francois. No,
Francois Bouteruche 4:02
no dotnet boots but I'm there we have our you know, the application we are working on together Brandon we will have their efforts this amazing applications that Hello has to chat with developers to get what their their preferred language the most important question of of this application what language and yeah, I love this question because from from one place to another, it is not yet always with them and through so we came up with a different No, I can see that yet. from one place to another. We got we got different answers. So sometimes seizure up sometimes. It's TypeScript, sometimes it's Python. So love to see how people in different country have different preference.
Brandon Minnick 4:56
Love it for hopefully, we'll see Hey there. I've got a couple of announcements this week as well. So if if you haven't met me before I, I am a mobile app developer. So I've been doing iOS and Android apps, and C sharp, going all the way back to Xamarin. Back in the day, and now it's using dotnet, Molly, and today is the Big Apple Developer Conference. It's called worldwide developer conference, that if you make iOS apps, if you even just use iOS apps, even if even if you don't write any code for him, you're gonna love it. This is where Apple comes out every year. And they basically give us all the previews of the next version of iOS. So I think, what are we on iOS 15. Now 16, I forget. But today, Apple's gonna introduce the next version of iOS show share with 16. Right 16. So we're going to see a sneak peek of 17. And then this is also when they release all the developer beta preview libraries so we can start playing around with them. And there's all sorts of rumors floating around because you know, apples really secret about all this stuff. They don't tell anybody what they're working on, which is kind of cool, but also kind of annoying, but we might see Apple's allegedly working on these augmented reality virtual reality goggles. So like their competitor to the Oculus that might debut today, I've been hearing interesting things about Apple opening up the watcher iOS ecosystem to developers, so we can make more widgets for the watch. But we'll see, it's, it's always my favorite time of year, I like to block off the mornings. It's 10am Pacific. So that's where I'll be tuning in. But let's, uh, let's get back to dotnet. Let's get back to AWS, because we have a really, really special guest today. He's one of my favorite people, because he makes the most amazing dotnet library. If you ever, if you ever used graph, QL and dotnet. And you're not using his libraries called hot chocolate or strawberry shake, then you're probably doing it wrong. But without further ado, let's bring him on the show. Michael Staib, welcome to the show.
Michael Staib 7:17
Hi, guys.
Brandon Minnick 7:21
Michael, I mentioned I mentioned your amazing dotnet developer, one of the smartest in my opinion. But for folks who haven't met you yet, who are you? What do you do?
Michael Staib 7:31
Yeah, I'm Michael Stipe. I'm nowadays a graph. COTC. So I'm working on the Graph. QL spec itself. And I originally created the hot chocolate Graph QL library, which is a Graph QL server implementation, which is, I would say, one of the two most public frameworks in the dotnet ecosystem for for Graph QL, right?
Brandon Minnick 7:59
Absolutely. I've got the link, I'll share it on screen in just a second. That's incredible. So we always like starting out with anytime we bring somebody on the show, because we found everybody has different backgrounds. Everybody started out as a developer in different ways. So like, how did you get into dotnet? When was your first time coding in C Sharp?
Michael Staib 8:25
So I actually started in Java, like I think a lot of people back then. I also remember still back then that Microsoft had a Java virtual machine. So Microsoft had its own JVM. And because they got into trouble with sun, they started working on something. I don't know how they even called it back then. But I think it was called comma, comma x or something or something like that. And I started looking into the first betters that came out of then Visual Studio dotnet 2002. I think I just remember it because back then Microsoft would send you CDs with the software on to try it out, like beta versions on a CD. That also shows me how old I am. Right?
Brandon Minnick 9:18
Who uses CDs anymore?
Francois Bouteruche 9:20
Yeah. I remember that time. I remember that time.
Michael Staib 9:29
Yeah, so that's how I actually started then to tinker with dotnet. And, but then there was a lot missing like if you if you came from a Java background, but it was so intriguing and yeah, I got stuck with it. Last year, it was so much new space that you could dabble into. And yeah, that's how that's how I started with dotnet.
Brandon Minnick 9:56
Cool. Yeah, I similar story, my first one Language was was Java as well. And, and you know, learning C sharp was very familiar coming from Java. You know, there's just, there's a couple things like, I don't know if Java has added them in since but back then at least there was no getters and setters or properties in Java. So, you know, a couple things learning C sharp, where, especially nowadays, there's a dozen different ways to do the same thing. And so, coming to the C sharp world, like what, what is this? Like? Why wouldn't you just make a public method called get is busy? Like, why do I have a property like, this isn't making sense? And then you start using properties, and you're like, oh, wait, I was ever making methods. Java is so weird. But yeah, I always love that. Because it certainly started out with the reputation of like, this is just Microsoft's version of Java. But then, unfortunately, for Java, it got caught up in Oracle and legal disputes. And it just kind of got put on a shelf for a little bit, while C sharp, kind of kept improving and kept pushing out new releases. And so nowadays, very, very different languages, you know, will still it's inspire each other and borrow features for each other. But yeah, it couldn't be more different nowadays.
Michael Staib 11:19
Yeah, but that's also what like, keeps me in dotnet is like how fast Microsoft is now iterating on this stuff, right? We have every year new version, then the language is much faster iterated on, like the features that you get in C Sharp, you get them much faster, like generics and stuff like that. It took Java a lot longer to get this in. And nowadays, I have to say with with records coming and stuff like this, we have records already, but like how features come in. That is that is really amazing. I think if if Microsoft stuck with dotnet framework, I would have gone, I probably would do Kotlin, or rust. Thankfully, they started with dotnet core. And since then, it's really like a really enjoyable platform, I would say.
Brandon Minnick 12:16
I agree. I agree. So, Michael, what we brought you here today to show off all the cool things you're working on. Where should we start?
Michael Staib 12:28
Yeah, so I'm still working on my hot chocolate graph cuesa. That was just getting a lot of attention. So apart from that, I'm at the moment working on quite more abstract topics like a project that we call a hot chocolate fusion. I'm not sure yet what logo we will put in and what fusion we say and maybe touch of it and marshmallow fusion, I don't know. It's all about graphical and microservices saw, being able to distribute graphs into sub graphs, and letting people built sub graphs and Graph QL decentralized. So that's that topic that I spent at the moment the most time in. And for grapher. Newcomers, this is totally over the top. Start with the simple stuff. Start with the monolith. And then when you have really a problem in scaling people, like having too many developers that work really on this monitor is that then it's time to go for these topics. Yeah, but that's, that's my current, my current main working area. But apart from that we have tons of other stuff, we can have a look at like banana cake pop, and we have lots of funny names, you know?
Brandon Minnick 13:59
Yeah. Or if we zoom out for any of the users out there who have maybe never used Graph QL or never even heard of Graph QL. What what is graph? QL?
Michael Staib 14:10
So that is a question I answer, like on a daily basis. It's basically how I start every conference talk. Yeah, so what is Graph QL? But why did we even come up with something new that challenges things like rest of I wouldn't not even say challenge. But why did we even need an alternative to rest? So Facebook back in 2012, or even before when they started with mobile applications? They had a problem of efficiency with fetching data between the mobile applications and the back ends. Like when people nowadays think about Graph QL but they often think is that it was created in the new node ecosystem, and has a lot to do with JavaScript JavaScript for folks. That is Java. That is Graph QL. But this is very far from the truth. Actually, the first Graph QL server was written in hack. Who knows? of you guys? Hackers?
Brandon Minnick 15:17
Yeah. Okay. I don't know.
Michael Staib 15:22
It's Facebook's version of PHP. It's a compilable. PHP version. And, yeah, it's quite tech. And that's where how they wrote the first Graph QL server. And actually, like, when you see graph is so beloved by front end engineers, it was actually developed by backend engineer. So mostly, like liberon, did a lot of front end stuff. But Nick Schrock, the original guy who came up with the idea, he actually was a backend engineer, like a traditional back end engineer. So why did they come up with Graph QL is to make data fetching between client and back end more efficient. And also, like, I would say, bring up better relationship between front end and back end engineers. Because it's not anymore, this back end engineer that tells you what to what to fetch. It's basically the back end engineer now telling you, here's a word, pick whatever you want, and I will fulfill your needs. And that is a predicament shift. So
Brandon Minnick 16:35
that's, that's why I love it. Yeah. As the guy who makes mobile apps. Yeah, kinda like you said, usually are historically with rest API's. The back end and back end engineers kind of have all the power when it comes to developing and sharing data. Because unless there's a REST API specifically for what you need, you can't get it. And as somebody who was on the client side, making the mobile apps, that was always very frustrating, because you either had to kind of jam a square peg through a round hole where you're calling this API, and it's given you 10 times more data than you need, and it takes forever, but it gives you that those two fields you actually need. Or you have to go to your REST API team and say, Okay, I need a new API, it's gonna look like this. And here's the shape of the data I need. And then you open up that ticket and you wait a couple of weeks, and then you wait a couple more weeks, and then maybe they get around to it. Whereas, yeah, with Graph QL, it's totally the opposite. Because the client side me, the mobile app developer, I can request any shape of data, I want you just on the back end, tell me what data is available.
Francois Bouteruche 17:50
Yeah, and I can. Yeah, go ahead. Rebecca, the engineer, I can bring the the other side of the perspective. I was, okay, you want me yet another API or you want me to change the API, but I've already that many clients consuming my API. And if I change the API, it will be a mess, because I need to figure out if I will, won't break something. So that's also why when I've discovered Graph QL, I love graphical because it solves this kind of issue, okay. Just pick what you want. And when you get it.
Michael Staib 18:29
It's also think about this, like this, this is one thing. People always say, Yeah, okay, then, if this guy needs to know another field, I will just put it in and back end engineers will do that after a couple of iterations. Maybe that gives you what you want. But think about removing something that's even the more complex case, that actually was the case that Facebook had. So they had all these API's, these rest API's for their web application. But then the mobile application has a much smaller viewport, and they needed less information. And now to tell people remove this bit of information we no longer needed or we don't need it for this case. What is the impact of removing that from a request? Or even if you don't need it in any of your applications anymore? And you say, Okay, let's remove this part from our, from our back end. That's a very, very difficult thing to do, right? Because you don't know what you really break by removing things. And risk graph where you don't have this problem. Because if you have this new application part or this new component or whatever, you just don't request that field and then this will be there. But I mean, grasp is a lot more than just a very intelligent as Passfield generator. It's actually a very strong type system. that is behind that and lets you also write front end components in a completely different way. But yeah, maybe I show how they how you set up a Graph QL server and how you query it, and then people get more into what Graph QL is. Sure if you show my screen. Okay, that is the wrong screen. I'm sharing my let me do that. Again. She has screen window. Done. It's this guy. Okay, much pad. That's that looks much better. Okay, so this is an empty project so far. And let's, let's build a simple graph class. And the first thing we need to have for Graph QL. So because graphical is transport agnostic, is basically just create a web server. And let's see what version we are using here from dotnet. Up Okay,
Brandon Minnick 21:14
we're done at a preview. All right,
Michael Staib 21:16
that should suffice. Now I've just I just need to know if I'm, I'm famous at combining the wrong versions, the wrong preview versus everything breaks, but let's try it. Okay.
Brandon Minnick 21:32
The first year I have it, download the very first preview and I haven't even tried out dotnet eight yet. But normally, I've got preview on preview to preview three preview for installed and yeah, they all get mad at each other on your box.
Michael Staib 21:50
Yeah, that's a developer's life. Right. Okay, to create a new new web server dotnet, new web is all we need. If we do that, we get an empty project here. And that's basically a Hello World. It's not even a REST API. Right? If I run that, it will just say hello, hello world. Not even an API. And Brenton, I think I have to change my screen again. Because I'm sharing a window instead of Ah, okay. You know, I shouldn't know how to how that works.
Brandon Minnick 22:41
Yeah, I get it there. Anytime I live stream out in the internet. I always like I'm gonna share the window instead of the screen, because you never know what's gonna pop up.
---
Brandon Minnick 26:23
get into kind of translate what's going on. If we've, if we've only worked in rest, it's almost like we've just created a get API that'll return Hello world, or Hello, and then whatever value we pass into it. Does that is that kind of close? Yeah,
Michael Staib 26:42
it's kind of close. But it's better. Because it's a wrapper. Now, so if I'm, if I'm here on the route, you can see I get four four, because GraphQL, by default serves on the graph query route that is written down in the graphical transport specification. It's not a must, you can put it on the on the route. But it's good practice to put it on the graph paper route. So we do it by default. So when we open that you can see we are greeted by banana cake pop. It's our Graph QL IDE. And it allows us to explore the Graph QL API itself, and also store documents that we create for graph, graph, and so on. So I can click here on Create document. And that opens up a new document where I can explore the API. And there are three important things I have here the operations, that is what I can write, read the source code, if you will. And then I have here the schema reference. And that's where we dive into because we want to see what our server actually is capable of. And what we can see here is that we have a class called query. That's the class that we created here. And we also have here the exact method that we wrote, hello, world. And this Hello World has here an argument name, which also has a default. And it also returns here a string. So this is a one to one match, actually, of my C sharp method. And that's why it's actually so powerful to create a graph cursor, because you basically create C sharp, and then we infer it to Graph QL. And this is quite the annotation based approach. And it's actually the original approach Facebook use with a hack service, because they basically had business layer, figured out for Facebook. And they wanted to give clients the power to pick and choose from that business layer. What do you what they needed for certain components in their mobile application. And that's basically the the base capability of Graph QL, you write your business layer, then we infer to Graph QL. And you can use it over the wire. And that gives you so much more power, because graphical has constructs like interface, like unions, enums, or the type constructs that you have in C Sharp and more, because we don't even have unions in C Sharp yet. But okay, let's go
Brandon Minnick 29:30
real quick. I want to draw some parallels again, for if you've never seen Graph QL before, like, what, what is even going on here, because there's so much power in what you've just done, and what we're showing off on the screen. Yeah. Because so for me if I was exploring a REST API, first, I would have to go find its documentation. So hopefully, the developers who created that REST API have kept their docs up to date, or they use a tool like got, oh gosh, what's the popular one that kind of writes the docs for you? Swagger and swagger? Yeah, that's like it starts with S. Yeah. So are we can use swagger and it kind of uses the x c sharp XML to keep your Doc's up to date for you. But what we're looking at here is Michael didn't didn't write any docs. He just wrote some code, he just created a, what we call a resolver. And Graph QL, which is kind of like you're kind of like an API endpoint and rest. And then we got all this for free. So what's what's really cool with Graph QL, because it is all it's, everything's very defined on the server, like Mike mentioned, there's this strong type interface, where, as backend engineers, we, we describe exactly what we serve to the clients. Well, tools like banana cake pop that we're looking at here, are smart enough to go okay, well, the engineers have already described everything and all the data that you can request, and that you can do on the server. So what if we just crawl that information, and then just surface it here. So what we're getting is basically, the Graph QL server provides your documentation for free. Now we can, we can be better developers, like there's ways to there's a, I use the doc description annotation in C Sharp, or we could add a description to the API. And here it says, no description, in Veneti kickback. But we can provide a little bit more help. But what's really cool is without having to write any documentation, the end user, the client would see this all for free, they would be able to come here and see that we have a Graph QL API where we can call this Hello World, and we can get back a string. And we didn't have to do any of that. And the other thing I love here, which is super, super powerful. And hot chocolate, is the only library I'm aware of that does this for us is as C sharp developers, we just write some C sharp code, like Michael just created the class called query created a method called Hello world, we could put a property in here if we wanted to, in basically, hot chocolate figures out how to convert that into Graph QL. For us, like there's a whole Graph QL specification that this has to align to. And but how chocolates doing here is like, Oh, well, you created a public string, Hello World, I see that this is returning a non nullable string. So I'll create a Graph QL endpoint here that also returns a non nullable string. And I see that you are passing in a string, but you've also provided like it's an optional parameter that we call or how it is how we call it in C Sharp. And, again, hot chocolate just kind of inferred that. And the reason I love this, I wanted to highlight this is it saves you so much code. There's other graphical libraries out there and dotnet that work great. I've built apps using them completely satisfied, no bugs, no problems, but it's very much those libraries are so much more verbose because they make you essentially define the Graph QL specification in C Sharp, whereas what I love about hot chocolate, is it kind of flips that around and says, Hey, you just write the C sharp, and then we'll figure it out from there, like you don't really have to know, this graph. QL has resolvers and you don't really have to know how Graph QL works under the hood, if you just know how to write Graph QL. And you can describe how you want to surface this data, then we'll take care of the rest. So just a couple lines of code like Michael showing off here, like, yeah, it's a sample app, and there's only 20 lines of code. But if I compare this to sample apps I've made for other dotnet Graph QL libraries. We're talking hundreds of lines of code just for the same simple sample. So super, super powerful stuff here.
Francois Bouteruche 34:12
Miko would you be offended if I called out Chokolate WCF of Graph QL because you know, when I was using WCF, and I was writing piece of code and every soaps substitute for me, and I didn't have to care about it. So I know it's quite old school but the the heaviness to use autoclave to generate a Graph QL API it's to me and quite old guy. It slipped it looks like the same benefits. Write your code and we will take care of the all the blueberry About of the of the protocol. Yeah.
Michael Staib 35:04
Yeah, that's right. So that's also a main aspect we want to, like, when I get when I wrote this library, it was not like, I want to write a graph career. So it was actually, like, I was a contractor back in that time. And the team lead said to me figure out what Graph QL is we want to use Graph QL. We have no clue what Graph QL is, but it sounds cool. Let's do it. And like, as a contractor, this is a good, good thing like, okay, let's figure this Mr. And it was very difficult to do graphical back end that time, because nobody had actually good libraries for that. And I had to use this library, the graph code dotnet, at the time to start building out a prototype. And it was so clumsy that I went and said, Okay, we can do it better. Give me two weeks. And suffice it to say it can take two weeks. I came back half a year later and said, Okay, now we have something crappy that starts to work. But But, essentially, because I had to build projects with that, I always have, like, the defects in mind that I want to take away boilerplate from you. And that's why many people not for chocolate.
Brandon Minnick 36:36
Absolutely, no, I love that point. Just, if, if you're a developer making developer tools, it's super, super important to use them. Because then you find out where all the sharp edges are, where the developer experience could be better. Or I was putting together a demo, I make a library called the dotnet Maori community toolkit and was putting together a little demo the other day. And as I started using my own API, and it's like, wait a minute, Where's, where's this one? I expect this to be here as a developer, and then was disappointed in myself as the library developer, that I hadn't implemented it. But yeah, it's really until you use your own libraries, use your own tools, do you really start to find those because it's easy to put something out in the world and be like, This is great. Everybody should use it. But then make sure you use it as well. Quick, quick aside, but
 
Michael Staib 37:33
we'll go yeah, that but that's, that's a really good point. Like, that's a really good point. And that's that you feel that like when you Facebook's stuff, they didn't build graph gradable graph when they built, they built Graph QL for the need that they had for the mobile application. That's why it's a good solution. Same as for React, they built react to build Facebook's web application. And that's why many people started thinking wreck this really good thing because they figured out so many problems. Okay, let's head on. So I have here my Operations tab and actually can make that bigger. So I did my last conference a week ago, actually, we all were there, right? In Oslo. But I somehow forgot all my things that I usually do in presentations, like make everything big. Okay, so I want to from the schema reference, by the way back to my Operations tab, and let's write a Graph QL query. So a graphical query, we call this a shorthand syntax. And this is basically a query I'm writing here. And the cool thing is that because I have a schema, I also have here IntelliSense. And then I can just pick whatever I want, and have from my schema here, and push the Run button here. And then I get here the result. So the main thing for Graph QL is when you're from when you look at it from a front end perspective, like I asked you for HelloWorld. There are other things that I could ask for like at the moment, just system fears, I could also ask for the type name I'm executing on right now get query here. But thing is, I never get more, and I never get less. So that's guaranteed by the Graph QL execution engine. That means I write here something and the Graph QL server gives me that data and the exact same structure. Like if you look at this part, it's the same exact structure than what I asked for. And that means graphical is very predictable for the front end engineer. And it even protects me from mistakes the Server Developer does, like with things like Open API, we have no runtime that evaluates if the schema you looked at from which you generate, it actually matches to the execution that you're executing against. So you can generate with open API client against something. And then it gets updated over time, and then it doesn't run anymore. That's not possible with graph graphs. I mean, you can also get a mistake, but it's very predictable in this thing that it will tell you. Basically, your definition does no longer match to what we say on the server. Okay, the second thing here is I executed HelloWorld. And I get back what I expect, hello word that this is default. But I also could pass things in because I provided to default. That's why I don't have to provide actually an argument. But I could, I could provide a name and say, Hello, Brenton. And then we get back. Hello, Brandon. Right. This is really like invoking a method on C sharp, and it's basically also patched through like that. But that's a very flat data structure, not very impressive. Let's maybe add a bit more complexity to that. So that's my typical example. I always do books and authors. But it's even even our GitHub copy Lord knows it. So I have, you know, a class book. And you can see it has a title, that's actually that's a class, let's make it for record. Let's make it a book record better for demos. Awesome. And then actually, let's add another structure here, which is our author. And that has a name. I don't care about the books at the moment. And let's actually put the, this guy here. So how do we expose such deeper structures in graph graph, and it's basically the same thing, I can go here to my credit class. And we can explore the expose that and I could expose it here as book get book. And then we just get up CO pilots really amazing.
Okay, so basically, Richard here my book, and also fit in some, I don't know, random book. And let's just restart our graph, QL server. And rerun that my old query still works, I only get this back, right, because I only asked for that. But now I could go here into my schema reference. And you can see that still the old schema, I can refresh that. And then you can see, here's the new schema. And that returns book. By the way, here's a column view. And that is better if you have a deeper graph, because I can go in my route type here, and then drill slowly into my book. And then see it also has an author that has a name, I can see the invocation structure. And that is also amazing because I only specified query as one thing for Graph QL. And it basically inspected everything that is reachable from that point where we start and expose me this API. And we can also as easily just query it right, we can dive into book title. If I only want the title, I only get the title. If I want to dive deeper into things, wrap the author, the author name, then you basically get that there's one thing actually, Brandon said in the beginning, when we looked at the documentation here, let's go back here, and there's no description. And we also infer that so if I were good developer and said basically, we want to do some generation of a document file, that's basically so now we compiling these XML documentation for files in C Sharp, then we could just write here some docs for it like it's doing it this guy, this is hello world. Okay, and that should suffice to run that and hope it works. It should As you can see, now this has documentation. Right. And it's very natural for sharp developers, because I didn't do anything special for Graph QL. It's just the standard mechanism to expose documentation. I could use Graph QL, specifics. Things say, Okay, I want to have here this graphical documentation. But in most cases, we want to use what we have in C Sharp. And yeah, I don't want to learn this third thing, at least in the beginning.
Brandon Minnick 45:34
That's cool. I didn't even know you could do that. I've always used the attribute things called like, Graph QL. Description.
Michael Staib 45:41
Yes. As I said, that is like if you want to have a specific thing that where the documentation for C sharp might be a different thing that you want to expose of the web, then you can use these specific Graph QL documentation text. But if you've anywhere just write one documentation, we can just look forward. See, even
Francois Bouteruche 46:09
a there is another. Yeah. Yeah, Mike. There is another cool feature, at least from me, I've discovered with graph curl is this subscription operation? Yeah. Okay, can you tell us a bit more about the subscription or operation?
Michael Staib 46:29
Sure, let's, right. Okay, let's let's first read mutation. Because subscriptions often are triggered by mutations don't have to be I'll show you two kinds of subscriptions. Let's read maybe, with simple a simple mutation first. So this is our query class. Can our Salem and actually yeah, piled on here, let's let's let's be at one class. So when fine. So first, let's introduce imitation here. And
Brandon Minnick 47:07
in what's the difference between a mutation and a query,
Michael Staib 47:10
I explained this in a second. So mutation is so in graphical we have. It's written down in specification, we have two things, the query, which is my side effect free. So if I call a query, then I shouldn't expect the side effects. Side effects are things where something changes on the server, like I call, maybe Hello word. And something would persist in the database that is a side effect this persisting in the database, it should be like an immutable model on which I read. Sounds abstract, but basically, it should just be a select on the database or fetch on a REST API that is behind that, or whatever. So typically, the get in rest, where as the mutation is causing side effects, so we want to write something to the database, if we go here with a book example. And introduced maybe a small repository. That's this our books repository.
And maybe we have here a method let's you can see, I'm totally coming up with right now. So let's say we have a list or dictionary, let's let's put in a dictionary. And we have here a string as a key. And let's take GUI ID as every good dotnet developer does. And we have a bug here. So this is in memory, I know. But this is our books, this is our backing store. And maybe we have a little fetch function here, which gives us a number of book and returns just the values from our from our dictionary. Okay, now we have another thing that is actually our mutation or that thing that we use in our repository to mutate this collection. In this case, we would maybe have here a void that says Add book for instance, and that basically adds our book here. And maybe we just put in a new idea here. Okay. And these are typically setups that you maybe have already in your business logic, right? You have these repositories or services or whatever, or you just use Entity Framework and and iterate against Entity Framework, which really does no metaphor to us. So if we look from the query part, we would have here an enumerable.
And maybe call it get books. And then we want to have here our books repository. So since Graph QL is resolver centric, we have something that we call the resolver level dependency injection, that basically means we would take the books repository and inject it into our resolver. Because these resolvers are potentially executed in parallel, and also scoped so to say, so I could say, this is a books report. And then I could call from my books report that get books here. So now we have professionalized, he actually, so we have a proper repository here. But maybe you ask yourself, How do I know that this is coming from the DI. So there are two ways in hot chocolate, we could either annotate this with the service attribute, or we could declare in hot chocolate that we have a global service, or books repository. And then now we know that this type everywhere where it's injected into our methods here, is actually a service that we can resolve from the DI. So let's go to mutations. Because in the mutation case, we could create something like a books mutation, where we now insert this book's type here as a new thing. And then we would add it here, basically, to our repository. So this would write it to the repository. And we're happy with that. And let's try that maybe out. And then we do a subscription to it, which basically would be something like on books, edit, or on books created. So this is a mutation, I edited here. The other thing we have to add is actually the service. We just put in the singleton here. And let's run that I hope everybody can follow.
Brandon Minnick 52:31
That's really cool that it'll do what you call handler level dependency injection,
Michael Staib 52:40
yeah. resolver level resolver level dependency injection. So we basically holy cow. Yeah, the thing is, you don't want to initialize all services that you might never use in your execution, because you don't know what you're getting asked for. So by putting that on the resolver level, we basically know what to create for you for this specific execution context. And that's very efficient. So in this case, we have your books, that's what we created. And if I want to iterate over the books, you can see we have no books as of now. So I could create a new tab here, this guy, and then we could write a mutation. So there's one thing I said in the beginning, this is a shorthand syntax, shorthand syntax, because actually, you would call it you would, in a proper client, you would call it like this query, this is the operation on which we want to execute this. Right? It's the same thing. So that gives us the same result. And actually, we would also give it proper operation name. So we would call it maybe get books. This way, one other thing I could pass in here that are variables or arguments. And then this actually looks like a method, like you're creating a method that the server should execute, or an operation in grafica. We call that an operation. And then it makes much more sense. It's not just like this projection set you have here or selections. It's actually a fully qualified thing that you have here, where you say, this is a method to do this for my UI component. Okay, let's take that away again. And let's write the mutation. Actually, we can write the mutation in the same document. Let's do it down here. And say, create book or that book. And then we get here at book because that is a mutation. I don't get it up here in the query. And then you can see what I get back here is actually the book because I returned the book. Typically, we do that in graph square, so you could read If you could do the mutation, write the new book, and then we fetch all the dynamic data like a new ID that is generated and stuff like that. So I'm just fetching the title. And then we pass in the book. And into our book we pass here. And you can see we have the same structure again. I can pass in the, I don't know. Brenton, did you read books or something? Yeah.
Brandon Minnick 55:27
No, I've been asked to write books. But software moves too fast. I've, I've had too many friends write books, where as soon as they're published, the books are out of date. And they spent 10 months of their life working on it. So maybe someday, but it probably wouldn't be on software, if I wrote about
Michael Staib 55:49
how to get rich. So these titles always said, you know,
Brandon Minnick 55:57
if I knew that I would be writing books.
Michael Staib 56:01
Maybe that gets you rich, I don't. Okay, so you can see I have an object structure where I write it basically, my book. And I did that in line. And the what I said initially is, actually we have your arguments in graph square, where we could say, actually, this is the book, that is what you want to pass in from your client. And then we would declare that as a variable. So this actually gets here $1 sign, and then we would call it, this is the book input that we pass into here. And then actually, we wouldn't construct graph query strings. And we would use variables here. And then we would pass in the dynamic data as a JSON graph. So actually here,
Brandon Minnick 57:01
same JSON we know and love.
Michael Staib 57:03
Yeah. And then we have the title, which is Maui is great. Okay, optimised is it's just me doing too much, and forgetting how Jason works. Okay, and I need commerce. Okay. Yeah, the thing is grafica, you don't need commerce, they are optional. They actually whitespace is something you could write like, I can write Intergraph good thing, like 1000s of comments. And the first thing that a graphical passer will do is just leave them. So our whitespace is in graph square, you can use them to create ASCII art or whatever. We just do nothing with them. You can see it still executes. Maui is great. And if we now execute our query, you can see here's our query. So this is mutation. So changing data, whatever, and reading data. So now we get to Francois question that he has discovered subscriptions.
Brandon Minnick 58:20
And he saw 20 seconds back, and we're gonna get kicked off the air in just a minute. Oh, yeah.
Michael Staib 58:25
Let's let's do subscriptions in super quick thing. So in order to do subscriptions, we basically have a class. I don't know if I can do it in this. But there's documentation, tons of documentation, and you can read all about that. And somebody. Yeah,
Francois Bouteruche 58:50
and I don't care. You deliver a lot of good workshop. Concerns to teach people out. Yes.
Michael Staib 58:59
Yeah. What's one of my conference talks? And then you went?
Brandon Minnick 59:05
Yeah. Oh, my God, it's been so great having you on the show today, we'll have to, we'll have to bring you back. So you can show us how to do subscriptions. And we can talk about how we can then publish all this awesome code to AWS using lambdas or Elastic Beanstalk? So much good stuff here. Thank you so much for joining us today. For the people out there, where can they find you? Where can they follow you on the internet.
Michael Staib 59:30
So Twitter is a good option. You can see my name tag, that's my Twitter tag. Also, like, I'm on GitHub, like GitHub, actually creamiest organization, you can go there you can find all the projects were working on. And that's typically the best places to get into touch with me.
Brandon Minnick 59:49
Fantastic. Well, thanks again so much for joining us today. And stay make sure you stay tuned, go ahead and subscribe to the AWS Twitch channel. But we have an awesome episode of build on generative AI coming up for you right now we'll see you next time
 

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Comments