– Great. Thank you, everyone, for coming I’m so excited to be a part of this first-ever GraphQL conference We never thought, back when we were starting to get in to GraphQL, that this would be happening so soon So, thank you all for being here Our topic’s called Navigating Your Transition to GraphQL And, basically, it’s about what we’ve learned from talking to a whole ton of people about them using GraphQL and what we’ve learned from our own apps And an approach that we’re discovering and calling GraphQL-First So, to start with, who are we? So, we’re the Apollo team We’re excited to build and maintain tools for the GraphQL community, so you might have heard about Optics already or Apollo client or some of these things we’re going to talk about later today We’re super excited, specifically about the developer experience enabled by GraphQL We think that, not only is it a great and efficient way of getting data in your application, but the most important thing is how it allows you to scale your development team and build apps faster than you ever could before We’ve gone from zero to GraphQL in two different apps One was incrementally, an application that we built before GraphQL existed and we migrated some of our data loading to GraphQL on that Then we also built an app from scratch, using GraphQL, with a really different exciting workflow that we’ve been coming up with So, we’ll hear about that We also like to build apps and features and open source projects that enable a better GraphQL workflow I’ll tell you a little bit about that in the presentation So, let’s look back a little bit at how we got here in the GraphQL communities So in 2012, GraphQL was initially released at Facebook, used in the native iOS application We’ll hear about that later In July 2015, it was announced and open sourced at ReactEurope, and that was really cool And less than or, a little bit more than a year later, in September, just recently, it was announced to be production ready and we got a great new website and great new documentation and the awesome announcement from GitHub about the public API So where do we go from there, in the future? What is there more to be done in the GraphQL community after all of these awesome events? We think the answer is even better tools, better best practices that everyone can agree on, and a more efficient workflow for building your applications So, we’ve been hearing about how a lot of people build their apps and we’ve started condensing this in to what we call a GraphQL-First Development workflow This doesn’t necessarily mean first chronologically, because you might have an existing app with an existing backend, but this means first as in the first thing you think about is your GraphQL schema Like our presentation, we’re going to start talking about how you might design a GraphQL schema for your API and some of the decisions you have to make there How you can use the GraphQL schema you come up with as a contract to design your UI and your backend in parallel And then, later, how you can take advantage of some of the advanced features of GraphQL to run in production and get more insights in to how you’re backend’s working So, let’s start with designing your schema How many of you guys have seen a diagram that looks like this before? There you go, so if you think back to when you were building your apps with maybe a PHP and MySQL or something like that, the first thing you would do is you would sit down and draw a bunch of boxes with arrows between them, foreign keys, rows, relationships It’s really a great time, I think The problem is that (laughs) this database schema is not always as relevant in today’s world because the frontend developers are no longer interacting with the database directly, they’re interacting with it through some sort of API which might not have the same fields And applications are getting more complex Not all of those fields are in the same database Some of them might be in MongoDB or they might be in an external API somewhere So that’s why you need a new way to do diagrams like this that are relevant to the modern age And that’s where the GraphQL schema comes in It’s really cool that GraphQL includes a totally backend-ignostic and language-ignostic way to describe your schema So you can sit down, I’ve seen our services team having meetings where they have text like this up on the projector and they’re discussing what is going to be the communication between their frontend and their backend? And it’s great, because you can even declare relationships between objects that are in different backends and different data sources or databases And, you can start doing this design, even if you have an existing backend already You can get the API you’ve always wanted, sit down and think “well, here’s what I have “in my rest API or my database “Well, what fields do I really want?” And if you do it right, you’ll end up with a situation that looks like this Where you have all your consumers on one side, your mobile app, your external API, consumers represented by this cloud server thing and some desktop apps maybe But, you have all these different clients that are being developed and then you have all these different backends that you’re talking to like your Rails Monolith that you’re trying to get rid of, or your Salesforce external API or (laughs) people understand Or maybe some databases that you’re working with But the idea is that you can develop each side in isolation without having to worry about where the data’s coming from and the backend people can safely optimize their app

without breaking anything on the frontend And so now, Danielle will tell you how we took advantage of this schema-first approach to design in some of our own production apps – Yeah, great, and so in his introduction, Sashko mentioned that we’ve gone from zero GraphQL to some GraphQL in two production apps And the first one that I want to tell you guys the story of is how we did that inner-app Galaxy So our app, Galaxy, which you’re looking at a screen shot of right here, is a hosting platform for meteor apps And so what you see right here is you can deploy an app to meteor and then you can log in to our Galaxy console and monitor the containers that are being used to run that app and so here you can see a list of containers Each row there is representing a container that’s working to towards running www.meteor.com When we originally built Galaxy, it was built 100% on meteor and react and so when we implemented this page, it was extremely data UI intensive because for each of those charts, they are live-updating with data from Amazon DynamoDB and from MongoDB coming together at the same time When we started getting excited about GraphQL, we saw this as the perfect opportunity to incrementally adopt it in to our own app And we saw it sort of an opportunity to redesign the data layer, specifically for this page, which was one of the pages that users had the most performance issues with And so, we were able to, you can imagine, if you have like 20 containers like www.meteor.com does, and each one has three graphs that are live-updating, you can imagine that combining all of those queries and all of the individual connections to be together was a huge performance upgrade for us And also on the frontend, as a frontend developer as I am, it was much easier to interact with the GraphQL API than it was, we were able to significantly simplify the code that we had in our own frontend And so here, I just have a quick system diagram of what our Galaxy app architecture looks like We have our client which talks to our Galaxy Server, which gets data from Elastic Search, MondgoDB, and Amazon DynamoDB and we were able to instrument our server to combine MongoDB and DynamoDB data together and so all our client had to do was request it We didnt have to get those things separately from the client is a really big performance upgrade for us And the second app that I want to tell you guys about is Optics Our CEO this morning, Jeff, he told you a little bit about Optics in his keynote It’s basically a performance monitoring tool for GraphQL But the story I want to tell here is that we got to build this app from zero to 100% production ready, solely using GraphQL So this is the first app that we got to design with GraphQL from the beginning And using the GraphQL-First Approach, that Sashko mentions, the very first step that we did to do this was we had to find the Schema Contract and because GraphQL’s schema is so strongly typed, that enabled great things for our development including it helped us parallelize our development But one of the interesting things that we came across when designing this schema contract and taking that as the first step is we came across the question of who really owns the schema? Like, who do you, when we designed our schema, we brought our frontend and our backend team together and we sat in a room for a long time and we went over a lot of different iterations of our schema But we had this conflict that we had to resolve internally of does the schema get owned by the backend developers or does the schema get owned by the frontend developers? Because if you’re a backend developer and you’re designing a generic API, you want your API to be able to service all sorts of different features, all sorts of different apps with all sorts of different features that you might not know yet And you don’t want to overfit your schema and API design to fit only a specific set of features and the previous talk just talked a little bit about that actually But if you’re a frontend developer, like I am, you want to be able to just query your schema for exactly what your components need and take those values and render them initially, so you want all your computed values to live on the server You don’t want to have to ever repeat computed value computations on separate clients that you might have And so, this is a question that you’re going to have to address if you do a schema-first design as well Where we fell on this spectrum is somewhere in the middle, a little bit skewed towards frontend schema design because our schema was designed specifically for Optics but our backend engineers constantly advocated for those previous things So, somewhere in the middle Once you’ve finished designing your schema and you’ve created this contract between the frontend and the backend, you’re gonna wanna stream-line your workflow and you can really take advantage of the GraphQL abstraction layer here to decouple your development So, you might be used to seeing a development process

that looks something like this Where initial product designs are, initial product ideas are created, product specs and then they’re handed off to designers who then go and create wire frames and mock ups which are then handed to the engineers Everything happens in a series And in reality, you end up wanting to do this quicker So you get something that looks a little bit like this where everyone’s trying to work together but, it’s all a mess And what you really want is something like this where every team can work together in parallel happily And what we found was that because of the strongly typed schema contract, we were able to actually basically achieve this while working on Optics because our backend had a spec to work to as soon as we finished our initial schema design and our frontend knew exactly what data to expect And so, as a frontend engineer, I have more perspective on the frontend side, but if you are going to start building enough in parallel where you don’t have a backend yet the first thing you need to do is mock some data before you can even start building any components And if you’re used to building restful applications, or if your application’s restful and you’ve had to mock data for it, usually what that’s ended up being is you mock your data per-endpoint But what ends up happening is if you change any line in your database, you then need to go and rewrite all of the different mocks that you’ve created for the different queries or endpoints You have to go and rewrite all the different mocks that you’ve created for all the different endpoints that might use that field in the database And what we think is really cool about GraphQL mocking is it doesn’t happen on a per-endpoint standpoint, but rather it happens on a per-resolver basis And so if you decide to change something about how your schema works, like you decide to change the fields to remove it to add something, it’s really simple, all you have to do is update one resolver while you’re mocking your data It turns out to be much more easy And so, at MDG when we were building Optics, we did component-first development What that means is you start from the smallest components and you use mocking tools and component building tools to create components one at a time and then eventually build up to larger layouts And this is how we developed Optics So, transition, Optics (laughs) And briefly, I just wanted to show you, we developed each component individually so this is actually all data we were able to mock using tools that our open source team made and we brought these all together to create our final product at the end, at the flip of a switch And our experience with using this GraphQL-First approach well, I just wanted to tell you a few good things out of it We were painlessly adapted to schema changes We were able to connect our backend to our frontend in less than two days after developing them separately for weeks And we were able to develop the entire Optics app, production-ready, in less than three months Which we think is very impressive And I will hand it back to Sashko to talk about the open source tools that enabled us to do so – Yeah, so, like I said, it took us a while to connect all the pieces, but what we realized what we’re really doing is building tools to enable this GraphQL-First workflow Aptly named, one of the first tools we developed was called graphql-tools This is an open source package you can get on GitHub on PM It lets you use that wonderful GraphQL schema language we talked about and use it to actually implement your GraphQL server You can see there’s a very short code snippet here But these several lines of code are the only thing you need to do to actually create a working GraphQL schema using the graphql-tools package So, you see here, we just define a couple of objects for our backend, we use the GraphQL schema language to do the type definitions and then the only thing that’s left to fill in are the resolvers In this case, one resolver to return our array of data And this makeExecutableSchma function that’s exported by graphql-tools is the thing that puts it all together in to a working GraphQL schema that you didn’t have to write any of those, sometimes large GraphQL js objects that you can import from that package I just want to mention, to start with, that none of this stuff would have been possible without all the awesome open source community we’ve been working with There’ve been a whole bunch of great people contributing to these packages, finding out new ways to use them and we’ll get to that a little bit later The other really cool feature of graphql-tools, as you just heard about, is mocking If you can implement a GraphQL server by just using the schema language, well, what if you could just skip the whole implementation part entirely and just have a fake backend? At a most basic level, mock functions feature of graphql-tools enables you to do this because GraphQL is strongly typed, and you know which type each field is returning, you basically have to write very little code to actually mock that data So this is a really simple case where you just call addMockFunctionsToSchema with no extra options and you can see it just returns “Hello World” for every string in your query Which makes sense for a start, but you can then incrementally customize it and go to our docs and check it out to return different types of data

for different types in your backend schema We thought that was a really cool thing and we used that for both of our apps while we were developing component-first and mocking out the back end I wanted to focus on some other ways that people have came up with to use this package So, Nick Nance, who is over here right in front of me is a, he gave a great talk at one of our San Francisco meet ups about how to use this schema-first approach of having the GraphQL schema materialize as a string lets you easily load that schema without running any code It lets you easily detect breaking changes and review changes to that schema like you’ve heard in previous talks as well So that was really cool And it was really awesome to see people in the community, like I mentioned, come together to develop new features for that mocking For example, in this case, something that would automatically select one of the available types from a union or interface for that mock So we’re excited to see where this stuff goes in the future Okay, so now that you’ve implemented your backend, you’ve implemented a schema and you maybe mocked some stuff out, you need to actually connect that data to your UI and get that out of the backend GraphQL queries are the wonderful feature in GraphQL that we all know and love that lets you do that Which is the second thing after the schema Just going in to a really short amount of background on the GraphQL clients, were different approaches to GraphQL clients The simplest thing you can do with GraphQL is you can just send a regular HTDP fetch get request So, very simple, very easy to understand But the problem is, as your UI gets larger, you might run in to some consistency issues You might end up loading data more often than you actually need to So you might want a client that does some caching While it takes a little bit of effort to learn how to use that client, it’s not as simple as just sending a request, it’s then really easy to update your UI after you do some mutations or use GraphQL subscriptions You can manage all of you data in one place and track the data flow very easily like you’re used to with Redux for example And you can get great developer tools that are integrated with these clients to help you understand what is going on in your app I wanted to go in to, on the Apollo team, what was important for us when working on a client that would enable ourselves and everyone else to take this GraphQL-First approach in development Some of the things that we identified that were really important to us were that it was compatible with a whole host of technologies Like we said, it’s really important to us that people can start converting their existing API to GraphQL incrementally like what we had to do And that means that you don’t always get to make all of the decisions for your client or server-side architecture And so, it’s important, like if you’re using Redux and you’re using that to manage all your client-side data, well, actually, I’m curious: how many of you today are using Redux in some of your apps? Wow, yeah, that’s maybe like a third of the people here, which is exciting But if you’re using something like Redux, you don’t want to throw that all away and lose all the benefits just because you’re trying to use GraphQL And same for the backend Some backends have different ways of doing stuff like pagination or identifying objects and so we wanted to make sure that your client didn’t require you to use a certain approach to a schema And the last thing was really needed to make sure that we could enable a component-first design approach, not just for designing components but then for incorporating it into your UI So that you could start with just one component on your page or two and incrementally move your entire app to GraphQL so that you could get all those benefits So, this is just about making it easy to get started with GraphQL and use it with your app, whether it’s new or incremental And the other thing is, as you heard in great detail from Joe Savona in his talk earlier today, it’s very important to be able to have your queries be static Then what do static queries really mean? I have this diagram that I’m really proud of here Basically, the idea is, you should be able to take all of your data requirements of your application and without actually running your application code, you need to be able to pull them apart So that, regardless of what module system you’re using, what version of JavaScript you might be using, you can identify all the queries in your UI super easily and then you can predict what queries will be sent to the server You can analyze all the data requirements and validate them at build time and you can notify the server about what queries it should expect to receive via this mechanism of persisted queries that’ve been talked about a lot So that your server only accepts the queries that your client is intending to send Which can also help with stuff like performance, security, et cetera So, that was really important to us The other really cool thing you get when you’re focusing on how to get the most advantage out of GraphQL queries is we can combined the strongly typed nature of the GraphQL schema and the great structure of GraphQL queries to get code generation for the result types in your app So you also heard about this a little bit in other presentations but today we have a package called Apollo-iOS which has a really great integration with Xcode, for example So you can have your GraphQL query open on one side of your Xcode window and you can have your SWIFT code open on the other side You can make a change to your GraphQL fragment and then immediately after rebuild, start typing and get auto-completion on the other side in SWIFT It’s really cool because even though you’re not typing your query in actual SWIFT language, the developer tools make it so that we can share this GraphQL query language everywhere while still getting the same advantages of native tooling

for that particular environment There’s great people in the community already working on TypeScript and Flow code generation for query results So that’s really cool If you go to the apollo-codegen repository listed here, you’ll see Robin Ricard working on it, who’s a really great guy contributing tons of stuff But, we hope to eventually have support for all kinds of languages like Java for example or Objective C, so please check that out And so, building on all this stuff that I’ve been talking about today and all the best practices that you guys have heard about with GraphQL clients, we’re really excited that we released a new version of Apollo Client yesterday We’re working really hard to get something that we thought really embodied all of these concepts So you can go to the website and check out all the features in detail There’s code snippets on there about how easy it is to get started with this and then do more powerful stuff with it at dev.apollodata.com It took over a hundred contributors, many months to get to this point in Apollo Client development Whether that’s working on documentation or integrations for various UI frameworks or building better caching and we’re excited to keep working on that And so, what is Apollo Client all about? Well, it’s about all the things I just talked about It’s about being 100% compatible with GraphQL So if you can type it in to GraphiQL, you can type it in to your UI code It’s about having all the features that you expect from a data management system Like queries, mutations, fragment code location, pagination and everything else It’s about being really friendly to developer tools Built with static queries so that you can analyze your data requirements ahead of time, but also something like Redux dev tools so you can see how your data is changing on your client in your Chrome window It’s compatible with basically every popular view layer out there and the community’s building more integrations all the time And it’s something that can grow with the needs of your app, so as you discover new requirements for your GraphQL client or server or something like that, you can always make Apollo Client work with it because it has tons of different extension points that let you build a GraphQL client that you want And the really cool thing is we’ve gotten to the point where you understand a lot of these different best practices for GraphQL and how you can connect that to your UI and so we can move in to the future And two features I’m really excited about in 0.5 are GraphQL subscriptions which are the first step towards having real-time data in GraphQL apps And we’re really excited to work with people like the author of Sangria to get subscription loan server The people at Scafold and Graphcool to get subscriptions into our backend as a service implementations So that you can connect to a GraphQL server and expect that the subscriptions will just work rather than having it be something that feels more like an experiment And the other cool thing that personally I’m really excited about is this thing we’re calling Custom Resolvers which let you extend your schema on the client by writing resolver functions directly into your UI code that will let you do stuff like tell your cache that it might be able to find some data in a different place than where expected Or maybe do a computed fields on the client, or something of that nature Like you might have heard, there might be a tension between what your server side fields are and what you actually want on the clients So you should be able to implement that on top of the schema So, just to wrap up some conclusions, I think it’s a good idea to, in a production app, use a caching GraphQL client that give you some UI consistency and lets you avoid loading data you already have Think it’s very important to think about incremental adoption and compatibility because you might have to work with existing apps that you build before GraphQL or maybe your technology choices might change in the future And it’s super critical to have something that supports static queries that you can analyze to have better performance, developer tools and server insights So, now that you’ve designed your schema, mocked your data, built your UI with a component-first approach using all these GraphQL queries, the next step is finding out what benefits can we get from GraphQL while running in production And so, back to Danielle for that – Yeah, uh, so, can I see a quick show of hands of who has a performance, sorry, a production product that you instrumented with a performance monitoring tool? Yeah, so, I had hoped that that is most people with production products So performance monitoring is extremely important with any production product because you need to be able to maintain reliability You need to be able to monitor when you deploy a large change, deploy a large change Or when your customer number grows and scales And if you’ve instrumented any performance monitoring tools in a restful app you might have, you might be used to measuring things such as how many times does this rest endpoint get called by which clients? Or how long does my client have to wait to get some response from this rest endpoint and to get the JSON block back? Or potentially, even, how does my server CPU load change over time, maybe per time of day or you can monitor this during specific deploys Like there’s a whole bunch of things that you’re probably used to using, used to measuring with any performance monitoring tool Well, one of our favorite things about GraphQL is that

because it’s so much more transparent as a data layer than things that existed before, it actually enables you to ask a bunch of questions that you’ve never been able to ask before And one of these questions is, for example, exactly which fields in which queries are being requested? And so with this, you can ask questions such as, do I have unused fields maybe that my server’s giving that my client’s aren’t taking? Or what exactly are my clients asking for? Like, maybe I can make this field’s more performant because I know they’re more popular? Another thing you can do is you can measure field resolver performance which you weren’t able to do before and so questions you can ask here are to have performance hot spots at the field level And we actually did measure these things in Galaxy, that was one of the first things we did In the next slide, I’ll show you that A cool demo of how we managed to make Galaxy performance better by doing this Another thing you can do is you can detect breaking schema changes and so you can detect build failures and stuff, for example, because you define this schema, so maybe you change something in your schema and you push it and you have a Travis CI integration that automatically detects build failures because it knows that you have clients on the frontend who are making queries that will no longer work Or you can detect backend changes, um, sorry Yes, it knows that you have clients on the frontend that might try to make a query that no longer works There’s a whole plethora of questions that you can ask This is just the tip of the iceberg And so I wanted to give you guys and example of how we instrumented some performance monitoring in Galaxy So, don’t worry too much about the tiny text here Basically, what you’re looking at is a field resolver trace view And so what you’re seeing here is the resolver timing for a specific query that we were making in Galaxy It’s actually the query that fed that data-intensive containers page the first time we tried to switch to GraphQL And for every repeated pattern here, you can basically see that we were making queries in series And we looked at this, and the first thing we thought was “man, that’s really inefficient.” (laughs) Let’s parallelize that And so that’s exactly what we did and so you can see the repeated patterns again but now they’re all happening in parallel And we were able to improve the performance of this query from 500 milliseconds to 300 milliseconds simply because we instrumented a monitoring tool And so that’s the whole idea behind Optics, the product that was announced this morning, is that you can do such things and answer such questions with GraphQL that you weren’t able to answer before Or that you’re not able to answer with existing performance monitoring tools If you guys are interested in learning any more about Optics we have a great page up now, apollodata.com/optics And just to give you a quick overview of the things it does, it can show you execution traces, it can show you latency duration for different fields in your schema and it can also show you how much field usage each field in your schema gets And there are many, many more things to come So, I’ll hand it back to Sashko to conclude – Yep, so, calling back to that slide we had with the three columns This is basically all the steps that we’ve identified so far in our GraphQL-First journey First step was coming together, design our schema with some of the different trade-offs between frontend and backend concerns The next step was implementing our UI and our backend in parallel and there were definitely a lot of things we learned about implementing components when GraphQL and how to use mocking there And then the last step was asking questions about our server that we could never ask before with a rest API but now that we had all this understanding at the field-level of a GraphQL query, we got all these new answers And that’s our presentation So we hope that you guys learned a lot from our experience and again, huge thanks to the open source community without whom like all of this great GraphQL stuff wouldn’t be possible All of these tools that we’re working on, collaborating with people I think it’s going to be really really awesome and get even better in to next year And if you know anybody who wants to work on GraphQL technology full time, we’re hiring right now We desperately need more people to add more of these features we like to products like Optics and tools like Apollo client So, thank you very much (audience clapping)