[MUSIC]
>> Why don't we start talking about GraphQL?
For anybody who's tuned in before,
they probably know that I'm very
much all about just starting with the basic question.
Let's start with the basic question.
What is GraphQL?
>> GraphQL, in a nutshell,
is a interface to data for frontends.
That's basically the easiest way I would state it.
It's a specification for a query language for APIs.
If you're familiar with,
for example, REST or WCF,
it follows a similar pattern in that you
have a request that you package up,
you send that request,
you get a payload back,
but it specifies how you shape that payload.
It also specifies how you mutate data.
Just like REST, you have post and put versus get,
so there's ways that you specify that in GraphQL.
But what really makes it shine is that it
allows a single frontend to multiple backend interfaces.
In other words, I can use
a single endpoint to query different data sources,
combine those data sources and do some interesting things like
even real-time subscription-based whatsoever,
like for observation of data streams.
There's a lot of flexibility,
and since we're showing some bullet points I put together,
I love this quote from one of the co-creators of GraphQL,
a data-fetching API powerful enough to describe all of Facebook.
They really, literally, wanted to be able to have
an endpoint that could do everything that you do on Facebook,
and it turns out that it works out
really well for other scenarios.
I'm just going to give this high-level of overview
because I want to jump into code and explain things through code.
But one of the cool things about a GraphQL request,
which we'll see what that looks like in a little bit,
is that it operates on this concept of resolvers.
In this example, at the top you see userID name,
user preferences, storage, whatever,
so I may ask for all these pieces,
they may exist in different databases and backends,
and even behind legacy APIs.
But with GraphQL, what I can do is take that,
write a resolver for each piece fragment of data,
and have that go off, and do its thing,
and then basically glue that response together and send it back,
which is a pretty cool piece
of functionality or capability, if you will.
>> That looks cool. I'm curious here real
quick because you mentioned REST,
and for anybody who's not familiar,
REST of course stands for representational state transfer,
which of course is completely meaningless.
Honestly, it's the only reason I ever remember what it stands for.
But REST, of course, it's a syntax.
It's an agreed upon structure for how it
is that we're going to interact with a web server.
When I do get,
what I'm saying is give me some data.
When I do post, what I'm saying is I want to create data.
When I do put, what I'm saying is I want to update data, etc.
Now, with REST, that's, to a certain extent,
where it stops, and
anybody who wants to get a really
pedantic is probably going to go,
"That's not really it."
Okay, fine. But in a lot of ways,
it doesn't give that whole structure
on being able to query data and so forth.
It's, again, over simplification here.
It's about this framework where I'm going to say get,
that's going to get data, I'm going to do post,
and that's going to create data.
But it sounds like with GraphQL,
it's able to go then beyond that,
that it's not just a "get is
going to give me data," but it's going to give me
some agreed upon mechanism with which
I can then query and filter and sort that
data like I might with a SQL query or am
I going too far with this?
>> No, you're very much on base.
So it's an agreed upon contract that does a couple of things.
One is you can ask any GraphQL endpoint,
what capabilities do you have?
What can I do? What can I ask for? You're able to do that.
It's like open API or Swagger and REST rolled into one.
The other thing though is you can shape the data response.
You can say I'm only interested in these two items.
Now, if you do that with REST,
there's creative ways that you have to do that,
like specify it as a payload on the request,
or you might have to go back to your backend developer,
if you're a frontend developer, and say,
"Hey, look, I really only need name.
I don't need 15 fields for this.
Can you provide another endpoint or a parameter for that?"
GraphQL has that built-in.
You always shape the data.
What I'm going to show you is that
that can go all the way down the stack.
It's not just shaping data before it serves it.
It's even down to the database level which is quite powerful.
>> You hit the point that I was trying to make,
and of course, you did it much more eloquently than I did.
But when you make that REST query,
again, it's that contract.
So when I call some REST endpoint and,
let's say, I do a get by ID.
What that's typically going to give me is the full object.
I don't have any real control over that unless there's
another endpoint that's now only going to give me part of that.
What you're saying with GraphQL is that now I can say,
"Hey, I want this by ID,
but I only want the name and the address field,
but I don't need all of the other fields to come along with that.
So that's something you can do in GraphQL.
That's obviously not something then that you can do in REST.
>> Correct.
>> Okay. That's that's very cool.
My headphones don't want to stay in place. Stay. There we go.
>> That's okay. Hearing is only half of the conversation.
>> It's apparently an important part though.
>> All right.
>> The other part that I want to ask you about is,
you mentioned that the client is then able to say,
"Hey, this is what I want," and then you also
mentioned that there's the ability to ask,
"Hey, what are you capable of?"
I want to talk just real quickly then about a little bit of
security and control then on the server side of things.
Does the server then have the ability to go,
"I don't want you to be able to filter based on name,
or I don't want you to maybe do a like statement,
to use a SQL type of scenario."
One of the things performance-wise that you often want to avoid is
doing like and then start with
a percent because then it has to go through all the records.
>> Right.
>> So one of the things that you might want
to be able to do from a servers go,
"Hey, you're not allowed to do that."
Are those the types of things you're allowed to
limit and filter with GraphQL?
>> You are. What's interesting about it is GraphQL specifies
how you formulate the request and how you formulate the response.
It doesn't really have an opinion on what happens on the server.
So I can use an authentication convention,
and then when I have someone's identity,
then it's really up to me to
respond to that request however I want.
Now, that's where GraphQL frameworks
implementations libraries come into play
because most of those will provide.
You're going to see an example in my demo that it's a
very much opt-in model that I don't
let someone filter the universe unless I choose
to opt in to let someone filter the universe,
or if I want to say based on a role,
you have access only to
a certain tenant or a certain segment of information.
All of that's possible,
and that's where you start to look
at different clients because they have
different dials and levers for configuring that, so to speak.
>> Okay. All right. Cool.
All of that now makes more sense in my head,
and hopefully, it makes sense in
everybody who's watching in their heads as well.