Michael Mifsud

Transcript

Thank you. 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 can be like plastered over with graphical representation. This got me thinking: the browser has read and write APIs.

Surely these could have some graphical interfaces. As it turns out, there's nothing about GraphQL that inherently limits you in server environments.

As long as you have a schema and resolver map, most implementations are happily run in the browser. Why? I think there are a couple of good reasons for this. We live in a world of heavy browser feature fragmentation, and even when those features exist, like the rolled out in a progressive manner, with API fragmentation in those features. There's the complexities of dealing with progressive enhance the and degradation because it's fun.

Admittedly, I did if for the fun, but there's something valuable in the idea of the interface across all our web languages. Let's look at some examples. We've looked at how we use resolvers to interact with data stores, but the browser has a bunch of its own data stores. We have the web storage APIs in local storage and session storage, web SQL databases, and cookies. With a bit of creativity, you can stuff any kind of data inside a URL.

There's a handful of libraries that do this for us acting as an interface across a buffer of these storage engines with using a mix of feature detection or polyfills. And so abstracting over data source is something that GraphQL is already good at. It's a really great fit for the scenario.

We are, we've taken the spreadsheet consolidate from earlier, but reading a file off disk we're using it as an abstraction over various browser storage APIs. Libraries will progressively enhance or degrade, depending on which APIs are available in the current environment. More importantly, the user APIs don't get to juggle all the different APIs themselves or learn a whole new third-party API. They're just looking at the schema for the types required and executing queries and mutations as they already know how to on server. Just like on the server, a browser has equally capable of making network requests to APIs.

Just like on the server, we can call it working APIs within the resolvers. Just like - we can gratefully degrade depending on what is available in the operating environment. And that, my friends, is running GraphQL in the browser. I think that's pretty cool.

So I thought I would end it here. Like, in many ways, browser JS isn't different from the server side JS. It's not surprising they're able to use GraphQL as an abstraction layer over finicky APIs. There's something unique to the browser. Does GraphQL still hold up in this new world? For example, our good old buddy, the DOM.

DOM libraries are nothing new. Some started our JavaScript journeys with DOJO. Even new, like, in React - here is an example of what a schema might look like for document query selector.

All the dollar-sign functions in jQuery. And this is what the resolvers might look like. We have a document query to get to our document object and the document type has APIs we care about and fields. The resolvers for those fields just call methods on the parent, the parent being document in this case. And I think things - things pretty much work as expected.

By now, you should not be surprised by anything on the slide. It's like previous examples we've seen before. The question you might have is why? Why even do this? And I get it: I was up front. These aren't necessarily good ideas.

They're just ideas, but honestly, slides like this I think is why. Every time I forget to await my fetch only to have JavaScript yell at me that I can't use top-level awaits is why. Every time I forget Node list aren't actually arrays is why. Every time I decide whether to have to decide to use a callback or a promise interface is why. All the reasons you might use jQuery today because it's easier is why.

Something about these slides really speaks to me. But I have to concede, building and maintaining a schema like this for the entirety of the DOM is kind of absurd. I get shivers thinking about what it would take to maintain.

So maybe some enterprising folks could generate schemas and resolvers by scraping things like MDN or W3C specs or get crazy with web IDL, or maybe if we don't have the schema. I know I spent you 20 minutes saying they're amazing and the skeleton of GraphQL. That's all true, but also I'm really lazy, like super lazy. Did you see that schema? It's massive, and it's not getting any smaller any time. So if we don't have schemas, we don't need resolvers, either.

I know, the beating heart of GraphQL, life blood, blah, blah, blah ... if I squint my eyes and tilt my head and use imagination, this looks like the resolver we had in our DOM APIs. So what if we define our own default resolver? A single resolver that was general enough to handle any field for any DOM API, if it follows a general pattern of fields being properties or functions on their parents, then we don't really need the schema. Like the DOM is the schema, like MDM becomes our schema.

I thought it was a nifty idea and gave it a shot. So I have some demos coming up. I think this stuff is cool. I've been told it's probably just me! If you think this stuff is kind of cool, how about giving it a clap so I know to continue.

[Applause]. All right. So, in the interests of tile, I have demos prepared earlier.

As I mentioned, we could abstract over things like network requests. So here we are making our request to some random API that someone kindly allowed cause on for me. - calls on for me. You can see here, we are essentially querying for our window object, run the object calling fetch.

In fetch, we're passing an array of arguments that line up to the argument forward of the fetch API. We are saying fetch this URL and then causing the JSON method on that response.

Under the covers, you may await this, but you don't have to care about it. It's done for you. And here we can see the output, just for the saying that I'm not lying. And you can get the result here by calling the path on which we made the query, so our result is window reflect JSON.

You may think we've already showed how resolvers can make requests. This is different, it's not resolvers making the network request, the query itself is the network request. We're resolving how to make requests. It's a bit unique, I think. So that is all well and good.

What about the DOM? I promised the DOM. So here, we're emulating what I talked about earlier, we are taking - querying the document, querying the query selector role and giving it an parliament with the P tags. On the resulting P tags, we're pulling properties off.

I think of this like a map. Like, what we've saved here, because you don't have to know what this returns. Is it an array, not an array? How do we cast an array? Is it going to yell at me? All those areas you probably run into like I have. And we can see the output here. We can see the properties coming out.

That's not going to impress you. Let's try this one out! So here, we're doing the same thing, except we are using GraphQL aliases. We are essentially saying passing a document in, saying this is the root purely for the sake of indentation and readability but also for the sake that we can show we can operate on the resolve to something else. Passing in a document, doing three queries of the DOM and assigning those results to variables.

We are saying our good boys are querying for all the Dojo emojis. There are some dogs and not dogs here. We're also querying for the non-Dojos, and for the yummy Dojo. These though you the results of the variables, but really bringing this home, we can actually pass this variable back into another query as the context, and here, we are doing the mutation, calling set attribute on our first good est boy, and we are giving it a style and increasing the font size.

If we scroll up - oh, I changed the name - if we scroll up! Giant hot dog! [Applause]. As you may have guessed, this is the hungry boy. We can query the DOM, we can mutate the DOM.

What else can we do? We can also do animations on the DOM using web animation API. Here, we are getting our hungry boy once again, and we're using the web animation API by calling animate on the resulting thing and giving it the object of the web animation specs. We are spinning it and scaling it up and down. We can change these. This is all live.

I'm not lying to you. This is, like, so here we have had to do is look at MDN, find the API, and it's the same query interface. We didn't care how it returned or how it worked. If we want to reuse the animation? How do we copy it around and use it? We can use the GraphQL fragments.

We are querying two different nodes in our yummy node. We are giving a spin and a bounce animation. These are defined down here asking from fragments on the element type before we have one that bounces and one that spins, and then named as such. If we uncomment this - woah, ... .

Animations as variables. That's the best I got. I'm sorry! [Applause].

I know some of you are thinking: DOM, who uses the DOM? I'm more about the jQuery life. For you, we have this. We are passing our jQuery as the root context and can call jQuery as northerly. We're doing our request for the item and calling animate function. We're animating properties if the way that you would in jQuery.

These can be used together. There's no limit to the hilarity that can ensue with enough animations. Let's give this one more spin before I wrap up.

And there we go. GraphQL on the DOM in the browser. [Applause]. In closing, I started by saying GraphQL superpower be and shaped everything else like a - this makes GraphQL infinitely versatile.

With a little creativity, we can GraphQL all the things and move towards a universal query language before the web. Thank you. [Applause].