>> Welcome, and thank you for joining me for
this special series Intro to GraphQL Part 2.
My name is Brandon Minnick,
I'm a Developer Advocate at Microsoft.
If you haven't already, make sure to check out Part
1 in this series where we introduced the concept of GraphQL.
In Part 2, we're going to explore
an existing GraphQL API endpoint.
Specifically, we'll be looking at GitHub's API.
So in my browser,
I've navigated to GitHubs GraphQL API and we have
a Graphical User Interface called
Graphical that we can use to explore the API.
Now, one of the really neat things about
GraphQL is that it's self-documenting.
Here on the right, we have
this documentation explorer and this is going to allow
me to learn everything I can do with this GraphQL API endpoint.
Now, I see here query and mutation.
These are the two root types for GraphQL.
Query is the equivalent to a GIT request in rest.
Query is going to just return back data,
it's not going to change anything server-side.
Mutation is the opposite.
This is the equivalent to create an update, a delete.
This is where we'll be changing data server-side.
So let's explore a query that we can put together today.
When I click on "Query", it shows me
all the different options that I have
for the GitHub GraphQL API and it's all the things we expect.
Like I can query for organizations,
I can query for repositories.
What I'd like to do today is query for a user.
So here on the left,
I'm going to type query and I'm going to
query for a user and you can see we get some IntelliSense,
which is really nice and it tells me
that I need to specify the user's login.
I'll put in my GitHub user account, brminnick.
Now, I'm getting some red squiggles which is telling me
that user must have a selection of subfields.
Did you mean user open curly bracket?
I did because if you remember from Part 1,
GraphQL requests only returned back
the fields that we specify and in this case,
I haven't specified any fields yet.
So let's see what fields are contained in user.
So user, I can see the users bio,
so I can type in bio.
I can type in let's say it looks like company.
We can see things like createdAt,
the date that my GitHub account was created.
Now, when I click "Go",
this performs the GraphQL requests and returns
this JSON response of exactly the data that I requested.
So now I can see my GitHub bio Xamarin app developer,
company Microsoft, and that I created my GitHub account in 2015.
Now, what you might notice
is that we have JSON data on the right in our response,
but the query on the left isn't actually JSON.
So how do we use this from the client side?
Well, let's do that in my
favorite client-side application, Postman.
So in postman here I've entered in
the GitHub GraphQL API endpoint and I've selected post.
Now you might be thinking, wait a minute,
post is a rest API thing and we're talking GraphQL.
Well, it turns out every GraphQL request is just a post request.
So if you're already familiar with how to make post requests,
you know how to do a GraphQL request.
The only difference is in the body.
So every GraphQL requests just takes
in one field and that field is query and
query is a string and the string that we
enter is exactly the query that we figured out here in Graphical.
So if I copy this,
I can paste it here,
and let's go ahead and get rid of some of
those carriage returns and the whitespace.
There we go. When I click "Send", look at that.
We get back the JSON response from the GraphQL API.
We get back my bio, company, createdAt.
What's really cool about this is as a mobile app developer,
I want to make sure that I'm using as
little of your cellular data as possible.
I want to make sure that I'm using as
little of your battery as I have to.
So what I love about GraphQL is I only have to make
one API request and let's say I didn't need the createdAt field.
Well with rest, I would have to go and I would have to create
a new rest API endpoint just so
I can get back a different shape of data.
But with GraphQL, I can just remove createdAt and send that,
and now, I get back only the information that I need.
Or maybe I want more information,
maybe I want to know how many people
follow my GitHub account
and I want to get the total count of followers.
Well, I add that in and now I can
get back the total count of followers.
So I don't need to create a new API endpoint every time,
I just can format the query and change the shape of
the data to match exactly what I need for my app.
Now, something else I don't want to look
at real quick is let's look at the size of this payload.
It's about 1.27 kilobytes.
Now, the GitHub rest APIs are still available.
So let's compare this against what we would
do for GitHubs rest API.
So the first thing we would need to do,
I would need to send a get request
to github.com/users/brminnick and then
this is where I can get information about the company and the bio,
and it also tells me the followers URL.
So that means I have to make now a second request
to slash followers.
Remember, I only want to know the total count of followers,
but when I click "Send",
it's going to return back all of
the information about everybody following my GitHub account.
All that information that I don't need because I just wanted
the number and look at the size of this payload, 27 kilobytes.
This is an order of magnitude bigger than
the GraphQL requests that we created just a moment ago.
So with GraphQL, we can make our requests faster, smaller,
more efficient, and we don't need
to create unique rest API endpoints every time,
making our development process much, much faster.
I'm so glad you could join me today.
If you're interested in learning more about GraphQL,
check out the links below. Thanks.