How to GraphQL, and why you should

(upbeat instrumental music) - I'm not Tim, Tim will be up in a second.

I am James.

I'm super excited to be here to talk to you about GraphQL.

A little bit of background I work on the opensource side of Meteor, Apollo.

We're kind of calling ourselves more Apollo these days, at least I am because that's what I work on the most. And so work on our opensource libraries and frameworks and kind of the community and how we build the stuff. And hopefully it's emerging, hopefully next year it'll still be here.

I think it will but hopefully today I can convince you of why you should start using it if you're not already. So I want to talk a little bit about just building applications.

And as we get started you can raise hands or hum or whatever you want to to kind of like give me an idea of what's going on here. But who has actually heard of GraphQL before this talk? This is great.

Who's using it? Also great.

What about React? Using View, Angular? Other JavaScript frameworks? No JavaScript framework at all? Alright.

(audience laughing) My favourite, I like it.

So I'm gonna talk about GraphQL but I want to talk about it through the lens of HTML.

We've had a lot of great talks, this is different from the normal conferences that talk about GraphQL because it's emerging and really prominent in the JavaScript world so there typically a really JavaScript heavy conferences. So rarely do you get the CSS is awesome and HTML is awesome talks ahead of time, which I love so this is me saying like, HTML's great, you should use it.

But luckily we've had amazing talks today that says like, HTML is great, use it, it's awesome. So you have a little bit of background there. But when we talk about building UI which is like a lot of what this conference has been about and how to build applications one of the things that I really like to kind of anchor people around is the idea of what is that primitive that you use to build your application? And at least for us on the web it turns out that HTML has actually been a really great primitive towards how we build things. It's kind of a universal language that we can all kind of centre around.

There's things that you can build on top of it. But ultimately it's really good at doing what it does which is describing hierarchies of views, like this, it works really, really well there. And like although HTML's very functional once you want to start adding a lot more like interactivity into your applications and bringing things beyond just what an HTML 5 or that kind of spec is capable of then you kind of have to get into the weeds of JavaScript, whether that's a good thing or a bad thing, you know the verdict's still out.

So maybe you start with some nice like Jquery if you don't want to just like write it plain and in the beginning it works pretty great. You can add a nice on-click handler, kind of start to build it up.

But then as you build more complex applications it gets really hard to start maintaining this and you get into like spaghetti code and all that kind of stuff.

And then maybe you use something like Backbone and it's like a little bit more evolved trying to give you some models and support for it. But even that doesn't really feel right.

And I promise those come back to GraphQL.

So really what you want to be able to do with your HTML is you want to be able to start to control your UI and that's what we're trying to build is we're trying to bring the UX side of what we've done with HTML with the UI and bring some control and some action to it. And that's really great, you know I'm gonna be talking about React some in this talk as one way to do that but it turns out there's some stuff that you kinda need when you want to control your UI. You need like life-cycle events when it mounts, you need event handlers and kind of all the stuff around it.

So these component architectures that we've been talking about work really, really great on top of the HTML primitive.

You can build really powerful applications, you can share components.

Give that kind of isolation, share you code base up to you know 800,000 lines and that kind of stuff.

So like we've got the UI side of that at least for the most part figured out.

And React kind of, I don't know if you want to call it famously, but really popular, made this popular this idea that UI is just data and then you want to translate into UI.

That's the state, that's the function that is React. Right it's like given state turn that into UI. And that's really good and it turns out that you actually still need more than just like the UI thing and that's related in these life cycle stuff and you build out these really complex UIs but then there's the whole other half of the equation, right which is the data side of it.

And this something that often doesn't get talked about when we talk about building UIs and there's a lot of hidden complexity that goes into that. It's things like local-state management or shared distributed state.

Using things like Redux or MobX or other kind of like front-end state management frameworks. You have remote data, you have live data, so there's a tonne of work that needs to come into your application all on the data side.

And that informs your UI, it informs your design system and how that data transfers and what your UI should look like.

So there's a whole bunch of stuff into it that ultimately what we're missing it feels like is that primitive for data so we can start to build these really nice abstractions and tooling everything on top of it.

So if we had a really good primitive for data maybe we could do a lot more.

So how do this relate to GraphQL? And why should you use GraphQL? So GraphQL is really about describing your data. It is designed to be a primitive for how you design the kind of data that you want to get back.

So just like HTML is the primitive for how you describe your UI, I like to talk about GraphQL as the primitive for how you describe your data.

It is meant to be a shared language between different teams.

So just like HTML is a good shared knowledge point between design teams and engineering teams as they start to implement it.

GraphQL is meant to be a shared resource between like front-end teams and back-end teams. So who quote un quote, owns the data? And who consumes it, right.

So it's about declaring these requirements of data and a really descriptive way to do that.

So what does that actually look like? So on the left here is a GraphQL query.

And then on the right is the data you would get back for it. And I'm tempted to go into a little bit more information around actually like this Conference query and assigning a schema for it but what you get here is a really clear picture of this is the data that I want to get back and then here's the shape that it comes back in. And you notice there's no extra fields here so even the speakers has a lot more information that would be in the database or at a REST endpoint because I didn't ask for anything else I only get back exactly what I asked for.

So you can start to build a lot more efficient transports, and I'll talk about that in a few minutes, but ultimately again it's about describing just what you need and then trusting that that's exactly what you're gonna get back.

So there's two sides of the GraphQL language, if you will. There is the operations or often called queries and then there's the schema.

So the operations is a really powerful query language. So this isn't something like SQL, this is a way to describe shapes of data that you want to get back from your end point. So this isn't necessary like exactly like execution patterns or anything like that it's just, I want this kind of data to come back from my endpoint.

And again you get exactly what you want, no more, no less.

And there's even some really powerful things like variables and the ability to skip and include within these queries.

So they can become like they have attributes just like HTML and it really is about a really clear picture of exactly what this data is gonna become.

And then you have the schema and the idea of the schema is that this is a central source of truth for all of your applications.

So unlike a database schema which is designed around the best way to store and access data, it's specifically designed for that type of data. A GraphQL schema is a way to model your product's data model.

So this isn't like this type of data is better in Mongo, this type of data is better in SQL, this part is just on flat files, that kind of stuff.

A GraphQL schema is how your end users should be using your product and how your front-end teams actually think about the shape of that data. So ultimately it's a really freeing thing in that it should be kind of owned almost by the product teams because a GraphQL schema is designed to empower product teams to be able to build amazing things. You get some really great stuff with the schema out of the box with GraphQL.

It has what's called introspection built into it, so any GraphQL schema out there you can build these really rich tooling that have an always up-to-date view of what kind of data can be accessed.

You get live type ahead, inline documentation and all this kind of stuff that if you ever like maintain your own swagger endpoint or something like that, all that's built in and out of the box with GraphQL.

And it's designed for really rich tooling, there's also a layer of validation for queries that come in all based off of how the schema works. So it's always up-to-date and it's there to empower your front-end teams to be able to build things faster. Then I'd like to talk about it's really about efficient fetching.

So this video that's running in the background right now it is, and not to pick on GitHub, but this is GitHub's REST API and this is a video where we are requesting some information about repositories.

And this is the data that we get back.

And this is a minute-long video of scrolling through at this rate.

So there's a lot of stuff that's coming back here because all of it is really useful if you're building something on top of GitHub. The problem is it's not all always useful so if you're trying to build a client app and you want to like be able to get some data like the owner of a repository all of this stuff is still gonna come back. There's just really not a good way that you can effectively do that and there's some ways with REST, things like O-data or different query parameters and that that you can kind of build out to do it but the problem is that they're not really designed to like truly limit down the way that these kind of things work.

They're these long query parameters, kind of hard to read, it doesn't really give you this good way to go out and watch it or start to go out and make that request.

GraphQL is designed from day one to make those requests really efficient.

The other side of that is that GraphQL as a query language, as a graph query language, which is a really scary thing to say because then you bring in all these like graph theories and now you have to know graph theories to use GraphQL and you definitely don't.

It's just, trust me, we're trying to make it easy, but it's just query and we'll show you that in a few minutes.

But because it's a graph of your data when you're writing out a query you're no longer limited to a single resource. It's a single like URL for all of your data. So it's like /GraphQL is the common pattern so instead of RESTAPIv1/user/id1, it's just /GraphQL.

And then you send your query to it.

The benefit there is you can build out whatever query your front-end app needs so if I want speakers and the title of their event and the venue that they're staying at all to form one piece of UI this isn't a waterfall request that has to happen on the clients, I don't have to manage getting back the initial conference information, then requesting the speakers and then requesting the information about the speaker's talk.

I can do all of that in a single request just by declaring that on my query.

So not only do you get less data because you don't get all this extra stuff but you actually get exactly what you need in the extent that you can go multiple requests deep in a single request.

So it's really about taking your individual UI component that is dependent on this kind of data and being able to make a request and just fill that, kind of out-of-the-box. So moving that complexity out of the clients and into the server that's really targeted for your product designers or your product developers. And Tim will give you a little bit more information about how this actually works in practise and how we work as a company for dog-fooding GraphQL and then I'll kind of come back and tell you a little bit about Apollo and kind of how it's our vision for GraphQL. So Tim.

- Thanks James.

So does anyone still want to use REST after seeing that video? I'm pretty happy not to be using REST.

So I'm the Frontend Tech Lead for the Apollo Product Team.

So we kind of have this sort of left-brain, right-brain kind of company where we have an opensource side which James is a strong player over there and the product side.

So what we're doing is taking the things that those guys come up with, you know they're in a little bit of an R&D mode, they're talking to people in the community, looking at GitHub issues and feature requests and the ideas coming out of everywhere and turning those into like actual libraries. But now we have to take those libraries and like actually put them into practise and build something with them.

So luckily we also have a commercial product which we use to actually generate revenue so we can keep the company going.

So what we're doing is trying to build our commercial product using a team of people that are pretty well distributed around the world. This has come up a few times in the conference so it's kind of school to see some of these themes coming back.

But I think it ties into GraphQL in a sense right, it's about being able to work remotely, to distribute knowledge in an easier way so. You know we've got obviously like most teams a range of skills sets, interns, juniors, seniors, you know you probably have front-end teams and back-end teams.

And all these people need to communicate together. GraphQL is just this really fantastic rendezvous point for coming together.

You know every once in a while you could be speaking different languages, Kotlin or Go and they don't all speak JavaScript so you know.

You might also have someone that doesn't understand your language whatsoever on your team.

This is Daisy, our office dog, so just bringing back the dog thread today. Yeah, so like I said we're the Product Team. This is just to describe kind of how we work together. So Open Source Team really pushing things our way saying, hey try this out.

And we're putting into practise with some pretty data intensive web apps.

So what we're able to do, once we've got this library, and it's like wow this is really cool.

We get to play with this and actually build something with it.

You know sometimes it works great and we're just like yes, like do more of this stuff and tell everyone.

And then sometimes it's like ah, this API's a little bit thorny, it's maybe not ready for primetime.

You know we love this concept but it's not quite there in that sense so really able to test out our own ideas in that sense as we're actually building things.

So let's see to get a little bit more into, of course in combination with the developer community and the customers that we have, really think about our company as just a giant laboratory for GraphQL.

And we encourage you guys to all of course contribute ideas as well.

So this a little bit of a workshop idea.

Just kind of going through the idea of modelling some data.

This is really what GraphQL, where you start out with GraphQL.

You have a look at your databases and the things that are happening on your back-end, the kind of data that gets presented in your user interfaces and you say okay, we've got to make a schema for this.

How do we do that and I love that Mandy referenced the schema website earlier which is very similar in concept to the idea of a GraphQL schema.

It's a model for your data.

So when you're trying to do this there's a few questions you could ask yourself. You know the saying, well what are the properties that I care about? What are the properties that this particular UI needs to be able to render itself? How can I break these things apart and have it make sense? You might also think about what kind of thing is this? So is this a number, is it a string? Is it a URL, is it an enumeration of a few different types of things that it might be? You want to think about how will this be used by developers? So this is an API you're building right? When you write a schema you're building an API which comes with all of those costs and benefits. You now have a thing that you've committed to supporting so people need to know how to use your API and it needs to make sense on a certain level right? It needs to be somewhat intuitive.

And of course you have to name things, (laughing) and obviously we all know naming is hard.

One of the cool things about GraphQL is that even if you get it wrong you can deprecate fields, you can move beyond what you did last time and there's a sort of a pathway that GraphQL describes about how you can do this overtime, so you're not thinking about you know RESTendpoint/v1 or RESTendpoint/v2. You're thinking about your schema as it evolves overtime to have some fields that maybe get deprecated because they're no longer performant and you've figured out a new way to model your data that is better.

So you can really build all that stuff in to your whole workflow.

So one of the ways that we can think about getting into a GraphQL schema is through the type system.

So this is what's called the GraphQL Schema Definition Language or SDL for short.

So the schema definition language allows you to describe the types of things that are in your schema.

So there's obviously there's a thing called a type, and there's a bunch of things underneath the type called fields.

So fields can be as we were saying before, you know they also come with the type of thing that they are.

So a title is a string.

Speakers has an S at the end so that might give you a hint that this is actually not one speaker, but more than one speaker.

So you know you use these little bracket notations to describe that this is going to return you a list of speakers.

So, here we are.

Going a little bit deeper into the relationships between types.

So as you can see a Speaker also has a bunch of fields attached to it.

A Talk has a bunch of fields attached to it. As well as Conference, ideally comes with a Venue, a place that we can hang out.

So that also comes with the fields that are attached to it. And we can see a few of the primitive types here already in SDL and I hope this isn't like terribly intimidating to anyone.

Like we're looking at things we see all the time, strings, and inc's and flips and certain numbers that maybe have decimal points in them. So the amazing thing about working with SDL is you can start to define your own types and you can make it your own.

You can figure out how your system is supposed to work on the back-end and how it's supposed to be presented on the front-end and put those ideas all together and come up with a schema for it all.

So I guess when I think about why we started feeling really excited about GraphQL 'cause it actually was initially an experiment inside of our own company.

We were trying to figure out how do you make a super query work in the browser and on the back end at the same time and synchronise all the data in between? It turns out it's really hard.

(laughing) So we discovered GraphQL and Facebook brought it out to the open and we were just like this is the idea and started building all these cool things with GraphQL and started using it in our apps and saying oh my God, we gotta do more of this. So some of the things that you get when you buy into GraphQL, obviously the structure which we've talked about, the schema.

The simplicity, I hope that's been somewhat apparent and the idea is really just talking about making a query that looks pretty simple, you know it's just a nested JSON kind of structure and then you get back the data in the exact same shape.

You've got flexibility, so what this means is really allowing the client to have more power over what they ask for right. So you're not just stuck with whatever's in the REST endpoint.

You've got efficiency which is this idea you know around only fetching the data you need.

Another one of sort of the very first pitches you get when you talk about GraphQL is this idea of an end plus one query, so you might say, I've got a list of things to render in my UI and for each item in the list I also need to grab a bunch of details so okay how do I break this down? I've got one REST endpoint that gives me the list of things but it doesn't have all the details and I have to make an extra API call for each item in the list to get the details that I really need and so now you end up with instead of one request to do that you've made 11 say for a list of 10 items.

Security is an interesting one, it's not necessarily easy to do in GraphQL, but what I think, how I think about security in GraphQL is that it gives you, let's say you were to just give all your clients in the browser the ability to write SQL queries. That you just send to the database, they run some stuff and then you send back the data. If you think about that idea that sounds great as long all of your data is fully accessible to everyone and there's no authentication between, right. But you know you actually now have this primitive that allows you to say, well the client has some flexibility, but they don't have all the flexibility.

I still need to be able to say, okay in that cascade I can decide at what level they have access and at some point in that tree that we've requested they might not have access anymore, or they might not have access to certain parameters if they pass parameters this way or that way they might have access to certain things.

So I do think GraphQL is a really fantastic way to think about security as well.

So I'm stealing a little bit of John's branding here but I think GraphQL kind of feels like it's part of a bigger movement that we're all kind of in together. A lot of the stuff that's happening this week here at Web Direction feels like it's all kind of connected. So some of the things that we're talking about here is like investing in our tools right.

So we're talking about you know measuring performance. We're talking about typescript, we're talking about flow types and linters and a lot of the stuff that comes from, a lot of it comes from static types, but there's a whole lot of other things that we're doing that feel like we're kind of I don't know, growing up a little bit, software engineering for the web.

Another idea here that GraphQL really fits in well with is this idea of modularization.

Components have been a big thing today so I don't probably need to spend much more time on that. This idea of automation, this is really exciting for me to where you can feel like your not just writing code that you're not sure what's gonna happen to it when it goes in the wild, we have a pretty intense culture now of doing continuous integration.

I guess we could do a show of hands how many people are using continuous integration on some level to release their products? So I mean this means like, yeah every time you push some code it's getting tested, and you're getting feedback about all the things that you could possibly automate and there's a lot of cool things.

When you buy into GraphQL there's even more cool things. So another thing to mention is snapshot testing. So with GraphQL you know it starts to get complicated when you're trying to do data mocking, but one of the fantastic ideas is I think maybe come out of JEST and some of the other tools that we're using for UI snapshot testing is that you can connect your mocks to your UI components and take a snapshot of it and if it doesn't look the same as it did last time then you can fail the test.

So we can do a lot of great regression stuff with that kind of technique.

And another thing that I think is happening, I guess you could say partly because of Node JS and partly because JavaScript is eating software which is eating the world is that this sort of line between teams is blurring a little bit so you know as front-end developers we might think of ourselves not so much as just front-end developers but as full-stack developers, whatever we can be writing code on the Node JS side and we can be adding the implementation details for say like a GraphQL back-end that allows us to have even more control, not only do we get to control the ideas and what's in the schema but we could get in there and build things and make them better and change things.

So I guess I'm just wrapping all these things together in this feeling of like well what is it like to have a GraphQL mindset? And I really think like when you buy into the idea of GraphQL you're kind of buying into a lot of these ideas as well. So back to the idea of blurring the lines between teams. You know you might have a mobile or web app team who's thinking about what is the data I need? How is it supposed to be structured and maybe I might, if I'm a really savvy front-end developer, I might be thinking about the performance of where the data's coming from.

If you're a back-end developer you're thinking about okay, how am I supposed to expose this set of databases or microservices or whatever to the world? And how do I secure it and how do I keep that current overtime? GraphQL also talks to a little bit of this idea around business analytics.

So if you make a schema that cuts across your whole organisation you're now able to ask really interesting questions that you couldn't ask before where you just make a GraphQL query and say, oh I want to connect you know what's happening over here on this app with this database and this product and make an interesting query that you couldn't have had access to before. And of course the operation schema always wants to know is anything on fire? So if you put a GraphQL API gateway in your system you have a really great place to start to do monitoring and that's what that's about.

So a lot of this comes back to designing a schema. I really think that you guys should definitely be designing your schemas together, front-end teams and back-end teams working together. I guess at the end of the day just make sure that the front-end team has the loudest voice in the room. Let's see here, so we've got a little bit more back to the structure of GraphQL here.

So we're talking about the tools that we get once we've bought into this idea of static types.

So this is a tool that is going to be really soon. This is a Visual Studio Code plugin.

That allows you to start typing your GraphQL queries as you're writing your UI components and you're writing your GraphQL queries together how amazing is it to just be able to start typing away and saying this is all the data that I have access to as I'm building my UI components, just right there, right in your editor.

Let's see here, so we're also being able to do code generation. So if you make a query that it comes with a bunch of text then you can quickly generate typescript mappings to that. You can now have a pretty fantastic development setup where all the data on your back-end is just auto-complete, an auto-complete away.

Let's see here, there's native documentation as James mentioned earlier. And let's see here, we're talking about the API gateway is the perfect place to find bottlenecks for optimizations.

So if you have people coming to your API to ask for this or that or the other data which could be coming from microservices or different databases, it starts to become a great place to look to find bottlenecks to where things are maybe not working, not working well, you can actually start to measure errors there and a lot of performance metrics. This is just another slide to drive home the idea of like you're getting to this point know of being able to co-locate the data that you're requesting with the UI component that you're building so you know at the top there is a GraphQL query. We're asking for a Dog and we're passing a parameter and saying, I want to get this dog by the breed.

Then we have right here this little query component, if you guys are familiar with REACT this should look pretty familiar.

But what this is is actually a render prop component, this is part of the Apollo opensource tools. But it actually runs this query on the back-end and gives you back the data and returns you some properties. So you know if this query is still loading, you know if you've got an error back or if it's finished you've got some data.

And with your data you can actually do something. And of course building components, I think we all know kind of the benefits of this, being able to do things in a reasonable way, in a declarative way and you know being able to modularize your code base so that it really scales.

So this is just an example of, this is React Storybook.

I don't know if anyone here has used React Storybook, but this is just an example of one of the workflows that we use when we're developing our components.

So this is an example of a trace, we call it a trace view.

Which is a component inside of our GraphQL product and what it does is just gives you a sense of timing for different fields inside of your GraphQL system. And the way we designed this is not in the application, we designed this in Storybook.

This is a wrapper around all of your component libraries that you have so that you're able to create scenarios that you might have in your app but they're really hard to create in your app, you can create them, you can specify the mock data that goes to them and really test everything in isolation.

So this is a really awesome way to develop. I mean I think I've gotten pretty sold on the idea of components just on this feeling alone of being able to say okay, how do I get this crazy state that I could never get like or I'll have to create this long integration test to be able to make it happen.

Now I can just say like oh, here's a bunch of mock data, pass it to the component and see how it renders.

And of course you can connect your snapshot tests to this and if it changes how it renders then you know you've got a problem.

So yeah, really what we're getting back to is being able to build higher quality code, you know doing these build-time checks and in addition to just being able to check against your performance metrics we're also being able to check are you going to break users if you change your schema? So here's some ideas around where we have a GitHub integration.

So this is right now a thing you can use.

When you instrument your code base with the Apollo CLI you can integrate this with GitHub.

So you can say okay, if I change my schema in this particular way, and my clients are relying on it the old way, something is gonna break, right.

When you deploy this server code you've now broken I don't know, some percentage of users in your app.

So this can protect you from those kind of scenarios. This is another thing, this is a schema history.

So now you can go back and have an actually change log overtime.

You can turn this into a automatic change log that you can publish to your API users, your other developers or whatever.

But yeah, so basically be able to describe all the changes that happen to your schema overtime in a consistent and automatic way.

So you don't have to do anything to get this you just publish the schema and it all gets figured out behind you, behind the scenes for you.

So in summary this is just all about having this kind of mindset, I think it doesn't really take much of a stretch. A lot of us are already doing these things, maybe not with GraphQL, but in other ways.

So it all kind of feels like it connects and links back to itself.

So hopefully that is as exciting for you guys as it is for me.

I'm gonna hand it back to James.

- Thank you, Tim.

Alright, so that's a little bit about GraphQL and kind of how it can work within your company or for your team to kind of see how you can enable better workflows around development both from a technical, automation prospect but also just how you actually communicate around data.

Like one of the ultimate problems that we face when we're trying to build products isn't necessarily what tech stack we're choosing, 'cause again our users don't care about that. But it's actually just how do we communicate internally when we're trying to build things.

And that language can be really problematic and GraphQL ironically actually provides a technical solution almost to that language problem where if you can unify around this schema and kind of discuss around the schema then there's a common language that all these teams can start to use.

So hopefully you're excited about like what GraphQL can actually do, but just like HTML is a really strong primitive, GraphQL is a really strong primitive but it still is kind of missing some of the things that you would actually need to use it, right? Like it's a cool spec, and yeah I could theoretically write some queries, but then there's a whole bunch of stuff on top of that like where do I actually make those queries from? So I'll need some kind of client app to run on my web app or my native app and then I'm gonna actually need some way to serve up those GraphQL requests, right.

So I'll need some kind of GraphQL server, and then I really need a way to kind of bring all this stuff together and to have this integrated in my workflow and understand what's happening.

Because who would really love to just like open up all their data to any query by anybody ever? That seems like a really safe thing to do right? Everyone's like, yeah, that's pretty good.

And it'd be really easy to figure out how slow things are going if you could only just see that something was going to /GraphQL, right, super easy to monitor, yeah, not really right.

So at Apollo what we try and focus on is taking the base power of GraphQL and actually putting it to the test of building in an application.

So that kind of laboratory that Tim painted a picture of that feels sometimes more like a kids painting room, we're trying to like make art together as opposed to like a laboratory.

It's not nearly that scientific, it's a lot of like, did this work? Nah, not really.

But luckily I think what we've come up to a kind of a proven system that actually takes what GraphQL is really good at and kind of fills in the gaps to make it easy to implement.

One of these other things that we are really critical about is this belief that you should not have to re-implement your entire application to use GraphQL.

You should be able to go home today and ideally within an hour build on top of your existing REST endpoints and put GraphQL in your app for a single feature like in less than an hour. It's very designed to be incrementally adoptable. So how do we do that? Well one way is with Apollo client.

So Apollo client is a JavaScript GraphQL Client. It is a library that helps you to make GraphQL requests, to manage things like loading state and error state. To have a client-side cache and a lot of other things that I kind of touch on. But ultimately what you look at here is I have my component.

It's got like a nice image tag in here, if we've got some loading data I want to do something. If there's an error I want to do something. So you already have this idea of this like presentation component, right we talked about that earlier today.

Where given some inputs to some props, give me back some UI.

And a lot of times in most applications, at least right now, the actual request for that data really tends to live somewhere kind of far away from this component that you're rendering because it's managed in this overall state management solution, something like Redux that has it's like, you've written out loading state and dispatches and error handling and all that kind of stuff in there and then you just connect it into your component. That's actually kind of really hard to build and to scale because I'm looking at at least two different files every time that I want to do something.

And I may not have written that data fetch, I may not actually know what comes back from that REST API, so as I design this component and my interface for my users to use I don't really have a good sense of what I'm gonna be able to do there.

The benefit of Apollo client is really wanted to bring those things as close together as possible.

So when we talk about like a single-file component, like something like View does we try to bring that same idea where this is the data that my component needs and this is how I'm gonna use it.

And they're right there together, Apollo Client's designed to make it that easy where you describe your data and then you give it into your UI and that's the application that you want to build. So when we talk about building isolated components we really can build concrete apps, as we were talking about earlier or concrete feature value in isolation, put them in Storybook or however you want to do it and they can live on their own and they manage both the data side and the UI side together.

It's more than just like make a request and get the data back in.

As you get into building client applications there's a lot of stuff that needs to happen, just like with a UI component, there's a lot of things that need to happen to make that really valuable.

So you need things like mutation, where you can like update data, but with mutation you also want to optimistically update your UI.

So when you send that chat message you don't want to have to wait for it to go back to the server and then come back and then update your UI and show that that has like jumped in then eventually sent, you want to be able to optimistically update the UI and show that's gonna work.

And Apollo has all this stuff built in that you need for powerful data systems.

And on top of that we really have a big focus on tooling. So we have our own set of client-side developer tools where you can live query your GraphQL endpoint. You can see all the data accessible to you, all within Chrome, so you're never leaving that kind of development experience.

Tim showed it's now all possible within something like Visual Studio Code where you can even run that query there.

You can see what data your client has used with this queries list and the store.

And there's this really powerful tooling that comes along with it.

And for a server we have Apollo server.

So as a schema first server, with all the batteries included.

So what in the world does that mean? Well, we talked about one of the benefits of GraphQL being the actual GraphQL schema so we have designed Apollo Server entirely around this idea that I have a schema written in a language that I understand.

It's SDL, it's not in this weird like JavaScript object system that I have to combine together.

It's just strings that I can like reference and understand. And then I have a way to resolve that data and that's all you need to do to build a GraphQL server. And then you just run it and this has things like a really rich IDE experience, called GraphQL Playground that allows you to run queries and save them and share them with your teammates and pass in header information authentication. It's got schema generation, things called Datasources we'll get into in a second. Subscriptions built in, integrated caching, file uploads.

Kind of everything that you need to run a full application is kind of built into the box of Apollo Server. We have this idea of data sources which says that ultimately you've got some data somewhere, this is whether it's your REST API, or SQL backend or something like that.

And Apollo Server ships with these things called Datasources that allow you to build in and implement that into your GraphQL system really easily.

They come in with built-in caching, integrated tooling, things like performance tracking and all that kind of stuff.

And then the way that we kind of unify all of this tooling together is with a product we call Apollo Engine.

So Apollo Engine is designed to help you to monitor everything that comes into your GraphQL application.

So just like Tim talked about this UI component, in practise this actually shows up when you look at a trace for an operation.

So anytime that a client sends a request to your GraphQL Server you can see how well it's performing down to the individual fields and how long each individual field took to resolve that. So this isn't just how long did user/1 take? But it's how long did user/1/firstname take in that lookup? Because this could come from a number of different data sources all together. And as you build the schema and grow and change it if you have full knowledge of how every single client is accessing your data, how long it takes them to make those requests, how often they make it, and like when the last time they started using it you can actually really freely evolve your schema. And you can kind of change your API really fluidly. It's like imagine if you had a Semver tester to make sure that no one in the world was using an API that you had supported.

Well with GraphQL you can actually get that. And every time that you go and change your schema you can check to see if it's ever been used or if it's currently in use and you can not break those clients.

You can this full documentation system where you can see everything that's happening within your schema.

How many requests, those are being accessed? How long they're taking, it's this really, really rich view and that's propagated through all of your tooling. It's in your editor, it's in your browser, it's in your like Chrome extension, that understanding of your data kind of extends to be everywhere.

So if you're interested more about GraphQL we're having a conference in San Francisco in November called GraphQL Summit.

This will be our, I think our third year running and there's gonna be a lot of talks there about a number of different ways that you can implement it. How it's working in production teams like Airbnb and GitHub are giving a talk about how they're using GraphQL in production to serve their like heaviest needs of their most active users.

So I hope you enjoyed it.

Thank you, that's me.

And that's Tim, so we had a blast.

(laughing) (audience applauding) (upbeat instrumental music)