GraphQL.

You might have heard of it by now, and, if you have, you've heard about how to it's great

for performance, backwards compatibility, and great for those hard to get out stains!

Probably!

There's seemingly nothing it can't do.

But have you wondered how?

How can GraphQL have these supposed superpowers?

I think the key to this lays in its basic building blocks.

In this talk, we will start off by taking a look at the schema definition language,

RSL, and the resolvers, and understand how they work together to execute a query.

Then I will show ways to use these features to graph all the things before finally entering

the "don't try this at home" portion of the talk.

First, g, the ' day, how is it going?

We work on building tooling services and platforms to enable at Red Bubble.

I'm the maintainer of Lis Sass and notes Sass.

So let's jump right into it.

The schema is the skeleton of GraphQL.

It's what gives it its shape.

Everything else builds on top of or happens because of the schema.

It is defined using the schema definition language.

We are we have an example schema.

We're using "type" to define conference.

Our conference type is a name field which we set as a string.

String is one of the skeletypes, in graph, and others like ints, floats, and booleans

and the other suspects.

We have a speakers' field which has an array of the speaker type.

It's not a built-in type, so we define it ourselves.

Our speaker has a name and a favourite emoji.

This gives me licence to use member throughout the talk!

We have some fields with exclamation marks and others don't.

It means a field is omitted but still valid.

IDs are convenient for querying and mutating data.

Speaking of querying and mutating data, we have the query types called root types.

There are others too but we're not going to talk about them today.

On our query type, we have a conference field that returns any conferences we know about.

We also have a speaker's field that has a required emoji argument and returns some speakers.

We have a mutation type.

It has a speak field, that takes a speaker ID and a Conference ID.

Something to note, it's common to refer to fields on query mutation types.

You see return-type mutation looks like the return type of a query field.

A field on a mutation could return things like booleans but as richer types as part

of the expressiveness of GraphQL.

There is some detail as to how these are defined that we won't go into today.

The important thing to take away from this is the field in the query type to ask for

information whereas fields and mutation type typically change things.

Lastly, the resulting data from mutation can be expected to have the changes already applied.

The schemas are the skeletons of GraphQL and at their beating heart.

They bring life to GraphQL.

With the amazing things that GraphQL can do, you would think they would be pretty complicated,

but it's the simplicity of resolvers that is the key to their flexibility.

It's just a function.

It takes a couple of arguments.

We're going to talk about these three today, but there are others.

You can define a resolver or any or all fields on your schema, including fields in the query

type, the speak field, and fields on any type like the emoji field on the speaker type.

Inside a resolver, you can do anything it could do in any other JavaScript function.

The only requirement is that it returns of value in the shape that matches the type of

the field that it is responsible for.

Here we have a map of resolvers.

It has a query object representing the query type.

And a query object, there is a speaker's resolver.

A speaker's query has an emoji argument.

We can access that argument by the name on the arc's argument on its resolver.

We know from our schema that the query should returning the or an array of speaker types.

Here it's returning an array of objects which have an integer ID field and a name and an

emoji string field which means they match the expected shape of the query and all is

well.

Remember, the conference field doesn't have an exclamation mark so it's entirely optional

here.

Our speaker mutation - here we have a speaker mutation loading data from the context by

the conference ID argument.

Conference is a bit special.

It makes it useful for storing things like configuration or services like database connections.

After it is loaded, the speaker ID argument is appended to the conference object, the

- finally does a query for the conferences that the speaker is attending.

So that was a lot.

But it is just a groundwork for what is coming up next.

We're going to take a look at practical use of resolvers to feel how they work together

and give you the versatility of GraphQL.

The simplest resolver is one that returns an object.

Earlier, we saw a resolver and all good because it returned a resolver that matched the shape

of the speaker type before how does GraphQL match the speaker shape?

Is there some kind of internal validation engine or some form of intro expect on their

return type or AI?

GraphQL can do these magical things.

Why not build AI in there?

No doubt there is a way to return these types.

If you're like me, you're thinking about how you would have done it yourself.

I've shown you how it happens.

Every field from GraphQL gets a default resolver.

The default resolver is straightforward.

For any field, it takes the object, the parent object and tries to be the access a field

as a function call, or an object property on the parent.

Importantly, this happens recursively, so, if a field returns a type, the field's return

type is a custom type, then all the fields on that type have their resolvers called.

This is what happens in our case.

The schema for our speaker's query returns return type to a null or an array of speaker

type.

GraphQL takes the speaker value.

If it is null, it's returned.

If it is an array, the value is iterated over and a resolver default is called for each

speaker field.

The parent armed for the resolver is the object at the current loop of the array.

If a resolver for a field returns the wrong time, GraphQL throws an error.

Also, if the return type of the initial speaker's query isn't null or an array, we also get

an error.

The default resolver is a great example of how we use building blocks to solve tricky

problems like validation.

So, a common use case for GraphQL is putting it in front of existing APIs.

This really its bread and butter and what gave it momentum to start off with.

Even here, there are interesting possibilities.

Here, I've updated our speaker query to make an HTTP request instead of returning a hard-coded

API.

The schema could have different types.

In this case, you iterate over the JSON and transform it to the phenotype you expect.

Once again, we've added the conference resolver to the speaker type.

There are a couple of interesting things happening here.

Firstly, using both jQuery and fetch.

Because, why wouldn't you?

You have the entire power of JavaScript and MPM at our resolvers, so we might as well

use it all.

We are iterating over the array of speakers, and for each of those speakers, the conference

resolver has called from an entirely different API.

Here, GraphQL's essentially aggregating across multiple APIs in order to resolve a single

query.

The remaining queries are resolved using a default resolver.

You can have a resolver with any or all fields.

You can resolve all fields by its own API and users wouldn't be any the wiser.

I'm not saying you should do this but you could if you wanted to.

GraphQL got a lot of attention early on because of how well it worked as a facade on top of

these fragmented APIs which often had incompatible methods of authentication, different transport

types or content types.

We can expose a single interface over - you have, APIs, without having to rewrite any

of them.

It wasn't long before people start rescinding these ideas, sometimes cutting out the APIs

altogether and going straight to the database.

Some truly innovative people have gone as far as defining the schemas themselves in

a different language.

Here, we are resolving a speaker query by making a -gate query.

We are pulling the database operation - we set this up earlier.

Because you have the full power of JavaScript to get a disposal here, you can do all the

things you would do in an attractional RM, like read or write instances, whatever the

requirements of that field might be.

If you can use a database, there's no reason you can't use any other kind of of data store.

Here, we are mixing and matching between relation al databases, elastic searches, at the field

resolver level.

Being able to make these choices at the field resolver levels allows us to fit best-fit

solutions for the requirements of an individual field and changes of requirements over time

as our systems change.

By no means saying this is unique to GraphQL, simply aiming to illustrate the ease as which

these capabilities are achieved between - within the play between schemas and resolvers within

GraphQL.

This is actually my favourite use case.

I said earlier that the platform team is a bubble, we focus on enabling everyone, not

just engineers.

The way we do this is let people bring their own tools and adapt our systems to work with

them.

Enter spreadsheets.

Who doesn't love a good spreadsheet in I know I do, our copy writers do, our data scientists

do.

They're practically ubiquitous and this makes them a powerful tool for enabling and encouraging

contributions.

Spreadsheets are fantastic for GraphQL because they are already structured.

They come with their own schemas in the form of columns and rows.

Here our speaker's query is loading it from disk, filtering the speakers to knows matching

the emoji we passed them as a query alter.

Now, anyone in our organisation can drag and drop a new spreadsheet on the GitHub UI.

This kicks off our pipelines, and if the test passes, this is live for everyone to see,

no engineer was required for this process.

I mentioned at Red Bubble, we have a lot of this GraphQL distributed and a lot of configuration

services to back this up.

These configurations services are different to other services in that they fetch configuration

on deploy and fetch low locally.

They're not meant to be used in request.

They may get over-the-wire updates as their lifetime goes on.

We like the approach for - but it covers the complexities.

Is is is the configuration stored in memory or on disk?

What happens when we receive an update?

How do we validate the new configuration?

We tried a few ways of managing and exposing configuration in our services and as you might

expected, we eventually landed on GraphQL.

Loading configuration files in resolver is pretty straightforward using the FS promises

API.

If we're unable to load the configuration for any reason, the server fails to boot.

This works really well in many cloud environments because currently running it deploys will

keep running until new versions can come up, so we don't lose any downtime.

Next up internally, we created a configuration object by querying for that GraphQL configuration.

If some important data is missing or if the data is otherwise unsuitable, the query fails

and the service failed fails to boot again.

Here, GraphQL's acting as an internal API abstracting over the node files APIs and abstracting

over the complexities of dealing with validity and freshness.

So some of you may have the inned in a previous slide, it was a chicken-and-egg scenario,

how to load configuration and put it in context if we are loading configuration inside a resolver?

This is where we do something nifty.

We create multiple GraphQL servers with their own schemas and resolvers.

One server handles incoming requests and reloads configuration by querying the second GraphQL

server.

That's right.

You can even use GraphQL to abstract over GraphQLs running on the same machine.

In fact, just about any API that is simply reads and writes can be represented as GraphQL

queries and mutations.

This is a real - this got me thinking - a light build up bulb moment for me.

What if our JavaScript APIs were GraphQL?

What if the browsers had a GraphQL interface?

This is my friends when things go off the rails.

Welcome to the don't try this portion at home.

Don't try this at home portion of the talk.

I hope by now I've been able to convince you that enough about any read or write interface