.Net Foundation On .NET, 7 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction To GraphQL

Description

In this episode, Brandon comes on to give us an introduction to GraphQL. He talks to us about its origin, its benefits, and he even walks us through the GitHub GraphQL API.

Learn more: https://codetraveler.io/DotNetGraphQL

[01:02] - What is GraphQL?
[06:05] - How does GraphQL compare to OData?
[08:00] - Exporing the GitHub GraphQL APIs with GraphiQL
[11:52] - Making client requests
[14:18] - Recap

GraphQL for .NET
https://github.com/graphql-dotnet/graphql-dotnet

Hot Chocolate: A GraphQL Server for .NET
https://hotchocolate.io/

ASP.NET Core docs
https://docs.microsoft.com/aspnet/core/?view=aspnetcore-3.1&WT.mc_id=dotnet-c9-cephilli

Get your questions answered on the Microsoft Q&A for .NET - http://aka.ms/dotnet-qa
Learn .NET with free self-guided learning from Microsoft Learn: http://aka.ms/learndotnet

#AspNet #Dotnet #GraphQL #WebDev

A

You've probably heard about graph QL if you're wondering what it is, why it benefits developers and how powerful it is. You'll want to check out this on dotnet episode.

A

Hello and welcome to another episode of on net. My name is Jeremy lick Ness and today we have a special series that we're gonna dive into exploring graph QL I'm here with Brandon Minich Brandon. Welcome, thanks for having me Jeremy tell us a little bit about what you do with Microsoft thanks.

B

I work at Microsoft as a developer advocate. My background is actually in mobile with xamarin. That's actually how I came to Microsoft via the same react position, but I've recently learned about this new cool technology called graph QL that is literally made for us mobile app developers that I wanted to share with the dotnet community. Today, ok,.

A

Well, let's dive into it. Tell us about graph. Ql sounds.

B

Good so we'll start out with an introduction, and so what? What is graph QL, where did it come from? It was actually invented by Facebook back in 2012, back in 2012 Facebook released their first app to the iOS and Android app stores and when they did that they found that the app was making a lot of API requests.

B

And if you remember back, then the Facebook app had some pretty bad reviews for being being slow for using a lot of battery life or using a lot of your CPU, and that's because it was loading all of this data when the app launched.

B

So if we look at this example here, this is an example from my Facebook feed and we can see that every time the Facebook app launches it pulls that information about my friends, recent stories and videos, they've posted and along with that, it's their their avatar, their image, the date and time any status, updates, they've posted and then the notifications tab next to it also loads when the app launches- and that has to get even more data about what my friends have been up to. Recent events.

B

Friend, requests, and so you can see that this is just tons and tons of data and if we think about this in the world of rest, api's well, the Facebook app would be calling all of these different rest api's and what they found at Facebook was the app was making dozens, if not hundreds of REST API requests every time the app launched. Because not only do you have to call the API to get the user ID. So you'll get the information about me as a user.

B

You'll then make another request to get information about friends, suggestions, but that might only return the IDS for the friends and that.

A

Has been your going for each friend to make another round trip and yeah.

B

You had this cascading effect where you had to make all these round trips and that's why the app took so long to load and ended up using so much of your battery life, because we're just cranking through CPU cycles and our cellular data. So the smart folks at Facebook said: there's got to be a better way and what they did. They came up with graph QL that condenses all of those api's into one okay,.

A

B

Right as they as somebody who's used rest before you're, probably thinking now like well wait.

A

A minute yeah: how do we do that? Do we overload a query string with 15 different variables, or what is the approach to being able to collapse that into a single call, good.

B

Question so so, with that one API endpoint, you can retrieve any data from the server and the way that works is we have a graph QL query language where we tell the API exactly what we want, and that is what the API returns back.

B

So, okay, this solves the both problems, so it solves a problem of what was called over fetching where maybe an API returns a bunch of data, but we only need two or three fields right: we throw away the rest away, so this will only give us the data we ask for and if we look at this query here, we're actually nesting objects. So, for example, I'm looking for information about a specific user, so I pass in the user, ID I say tell me that user's name.

B

The upcoming events count tell me that user is friend suggestions, but just the first one, and for that friend give me that person's name and mutual friend scout and the response that comes back. This is a JSON response, so it's the same JSON we know and love from our REST API, but with graph QL. It's exactly the data that we asked for so we can see for the user, the name my name is Brandon Minich at for upcoming events. I have one friend suggestion here, just like I asked for and no like it's for Seth.

A

Or is it alright, we have.

B

18, mutual friends, and so even though we're nesting objects that would be multiple round trips with a typical REST API with graph QL. We can do it all in one trip to the back end.

A

So it sounds like you've taking what would be a bunch of different individually orchestrated requests. You've put instead of the onus on the client to say, I want this and then I want this and then I want this and I'm gonna. Combine it you're, just taking that and pushing it over to the server and saying you deal with this, but give me back exactly what I want and the server probably has a better job of doing that, because it's closer to where the data is.

B

Yeah and and one of things, I love as a mobile app developer is it it gives me all the power if you think about with rest, if I wanted to get different data, or maybe I wanted to change, the shape of the data that came back I would have to create a new API endpoint right, but in reality that means I have to submit a ticket to my back-end team.

B

They create the API endpoint and then, in a couple weeks, when they get to it on the next sprint, then I can add that to my mobile app. But what I love about crack ùl is. It gives me the powers on the client-side to request any data I want and as long as we've exposed that on the graph QL endpoint I can return it and use it in my app so.

A

There is a piece of this and I know in a future series we'll get into the backend side, but there is going to be some sort of configuration on the server to be able to support these graph QL requests. Before. We jump into that, though. I just recently did a series on technology. That's been around for a while called OData. Yes,.

B

Which sounds like similar.

A

Things and maybe a different way, can you talk a little bit about how graph qo compares or contrasts with Oh data yeah.

B

Well, let's first take a look at this query here on the left, because it looks like JSON at first glance, but if you squint your eyes and look really close, it actually isn't you'll notice. It's missing the quotation marks, it doesn't have the colons, and so this is a this. Is the graph query language, but to answer your question, the biggest difference between graph QL and OData is OData is a filter with OData. We have our REST API it'll return back data and we can filter what comes back. Oh so with OData.

B

It will, let's say we're requesting data from users, so we'll hit the API endpoint. The API will still do everything. Maybe it has to hit two or three databases: aggregate all that information together and then before the data comes back, is when oh data filters it so the API still gonna do all that work, we're just minimizing what comes back so we're fixing the over fetching Brown, okay, which is great, but one of the cool things with grack UL. It's smart enough to know.

B

Jeremy only wants these specific fields and all of those exist in one database. So I don't need to make multiple database requests. I'm just gonna make the one database request and pull out that data, so it can.

A

B

Your back-end logic, okay,.

A

B

Good, so I tell you what let's, let's actually jump into the github graph QL API and learn how to explore it for the first time. Okay. So what I've done here? I've just navigated to github graph, QL API, my browser and we are live so I'm signed in with my username and the first thing I want to show you is this documentation Explorer here? So this Doc's Explorer comes with this graphical user interface as GUI called graphical and graph cue. Our graphical radical is a free open-source library that comes with your graph, QL API.

B

So in the next series, where we show how to create our first graph, QL backend, we'll see graphical in there as well and I, didn't have to write any code for it. It just.

A

Got the first part of that? Okay, it's right so.

B

With graphical we get this documentation Explorer and on the Left we can actually start to create queries. So the way this documentation Explorer works is in graph QL. We have to define all of the types and all the different fields that the API will return all right, so graphical, smart enough to crawl through our API and present all that data here so kind of similar to a swagger. But we literally had to write zero code so.

A

I can intellisense for an API. Basically, that's a.

B

Great way of thinking of it, because there actually is even intellisense over here right in the in the query Explorer. So what we see here, we have two brew types and they are a query and mutation, and these are the root types for every graph, QL endpoint, and so a query is your: if we're thinking about crud create would be your reads: we're not changing anything on the server we're just root returning data. Okay, a mutation is the opposite. So that's your update at erase your deletes right. So what we'll do here?

B

Well, we'll create our first query, because this is live data, so I don't want to change anything on my github account and the way this syntax works. On the left hand side. This is literally going to be what we pasted into our graph QL query that we're forming, and then we can. Click on this query object to see all the different types of fields. We can query for. Okay,.

A

B

Know we're in github and we see things that we'd expect like you can search for licenses or the github marketplace. There's things like the we could search for a specific repository, but let's scroll down because there's one for user, so for user, it tells me I, can query for a user, but I have to pass in a specific string, which is the user's login.

B

So for me my github username is BR Minich and then we're still not done yet because, like we talked about earlier with graph QL, we can only get back the data we asked for so.

A

You asked for a user, but what about that user right.

B

What what about the user, and so you can see it's actually yelling at me. We got a red squiggle here in in the browser and then, if I try to run it I'll get errors. So yeah, let's check out what is available in this user object, and so you know I see things here like we can return my user bio company name, there's things like the created at time, State, and so now that we've specified the data we want.

B

We get back exactly that nice, and so we can add more to this like there is there's followers there. So I could say show me how many people are following my my github account and if we added in that data comes back and if we take it away, it goes away.

B

So this is cool, but you know we're just in a browser here like how do we take this query and do it from say a real client-side, API call sure, and so I want to show that real, quick here in postman, so postman is just my favorite tool for making API calls and we're doing it here on my computer, where I've gone ahead and entered in the github graph, QL, API endpoint, and what I've done I've set this to be a post request.

B

Okay, now this is kind of weird because we're talking graph QL, not rest, but it turns out that every graph QL request is a post request. Okay, so if you know how to make a post request using HTTP client in c-sharp, it's the same way, you make a graph QL request.

B

So what we do now we have a post and in the body in our JSON body, there's just one parameter or one field called query, and then the string we pass in is this query that we just figured out so I'll go ahead and copy and paste this in we'll get rid of some of this white space. So.

A

It's a JSON like schema. The schema is not JSON. It's graph, qo, query language, but you're, passing it as a property on a JSON document and opposed to a REST API. That's.

B

Right, okay, so suddenly it all starts to feel familiar. You can start thinking about how you call post async and let's see if we click, send it yells at me, because we need to tell it to keep these quotes around my name. So if I click send again there we go there, we go and so there's exactly the information we asked for and again. If we we didn't care about what data I created, my github account we get rid of that and we've reshaped the data all from the client side, nice.

A

So what I'm saying from this is two things that me about it. One is the ability to have that full control from the client, but the second is that discovery process. The fact that it exposes what's available that seems like as a client developer, is a tool that makes it so much easier when.

B

You're writing.

A

A new feature: how do I get to that feature? Well, I, can explore and drill in and figure.

B

That out, that's right, because your documentation is never out of date. The live API will show you in the documentation, Explorer exactly what's available nice, so I know I threw a lot at you. So just just a quick review so get our graph QL api's just have the one endpoint right. So there's one an API endpoint. It can return any data that you ask for graph. Ql api's are self documenting, so with graphical it will explore our schema and expose that in the docs graph. Ql requests are just post requests.

B

So if you know how to make a post request and c-sharp use an HTTP client, it's the same thing. We're just leveraging rests post, HTTP method and the graph QL request body is just JSON. So, like you said it's just one field query, and then we can paste in that graph. Ql query that we figured out using using the browser and the graph QL response is just JSON. So when we get the response back, it's the same JSON we know and love.

B

We D serialize it into our c-sharp model and do whatever we need to do it do with it in our or.

A

If we're not C sharp, we can load it directly into a spa. Client angular react view whatever that is absolutely and just process. It sounds good.

B

Yeah, and so all of these resources I've put together this website for us today that you can go find more information. If you want to learn more about graph QL, you can head to this website, we've got links to teach you more. We've got links to sample apps that we'll be showing off in just a minute in our next episodes, where we create our first graph, QL back-end or where we connect our mobile app to it all in c-sharp, and it's all available for you here on line sounds.

A

Great well, that was an introduction to graph QL. As he mentioned, we're gonna dive a little bit deeper into. How do we set up the graph QL back-end and then how do we consume it from the client? So stay tuned keep a lookout for that. That's been your on dotnet episode.

A

Hi I'm Jeremy lick nice you've watched another episode of on dotnet. Thank you for joining us, be sure to LIKE and subscribe so that you don't miss a show and if you're interested in more shows check out the link right here. Thanks.