How adopting GraphQL will make your organization better / faster / stronger

GraphQL is being adopted throughout the industry, and for good reason. In this talk, we’ll explore some of the use-cases and success stories of top companies as they’ve made the move to GraphQL. We’ll also offer guidance as to how to move through the phases of adoption at your company.

Peggy Rayzis

Peggy’s team is responsible for making teams successful with GraphQL.

One thing that is sure is that GraphQL is here to stay. Adoption is growing and big names are trusting it in production, across industries. It’s not because it’s the new and shiny, it’s because it solves actual problems.

When building apps we have a huge challenge designing and building the data layer. We have tons of data to manage, and tons of clients to serve.

What is GraphQL? A specification for communicating about data. It’s unopinionated and very flexible.

(client: describe the data they need) ⟷ (GraphQL) ⟷ (Services: describe the data they have)

  1. With GraphQL you always start with your schema. It describes the data you have, essentially a set of types/interfaces (strongly typed, looks very like Typescript or Flow).
  2. Next you move on to writing queries, which describe the data you want. Get requests and listening to events.
  3. Resolvers are functions that transform queries into data.

For an example of this in practice, look up the GraphQL playground.

The thing that starts to really stand out about GraphQL is that you only get the content you request – request payloads are much smaller than traditional endpoints which usually send a great deal more information than the request really needed.

You always receive exactly what you ask for, nothing more or less. This is particularly valuable for people using mobiles. (Example where a REST endpoint is 35k, but the GraphQL equivalent was 1.3k)

You can use REST selectors to accomplish the same thing, but if you are doing a lot of work to make REST work like GraphQL… maybe just use GraphQL where you get it out of the box? Also you don’t have to rewrite all your REST APIs to start using GraphQL – they complement each other. You can layer GraphQL over your existing REST APIs and that’s a really good migration path for teams that need to change over incrementally.

Apollo is a platform for doing this layering. It’s a specific way to implement GraphQL. They provide client and server packages (open source) which help teams follow best practices. They support all the tools you care about.

Apollo Client allows declarative data fetching, it’s framework agnostic – you just put your query into an ES6 template literal. Apollo Server sits between your data and your client layers; and connects to Apollo Engine, their cloud service which registers your schema. (This service has some paid features for usage analytics etc.)

Apollo’s VSCode plugin will be giving realtime metrics on query performance at author time! This helps address the concern many teams have about the potential performance impacts when non-data developers start hitting the data layer.

BETTER It’s simpler! Simpler to write, easier to get rid of when you don’t need it.

FASTER GraphQL lets you ship code faster by writing less code. State management is hard and has a lot of code to write and keep track of. Apollo handles lots of concerns like caching (both local and remote); and generally just lets you delete a lot of code. Apollo cache becomes the single source of truth.

STRONGER GraphQL makes your teams stronger by helping product teams collaborate more effectively… with schema-driven development. Once you agree on a schema, you have a contract both the frontend and backend can use. Frontend can be built against schema-compliant mock data; while the backend team works on providing the production data layer. Apollo CLI also gives schema validation checks that help you evaluate the impact of changes before you merge; and deprecate fields gracefully as your API evolves over time.

What about the pitfalls? GraphQL is not a silver bullet.

Its extreme flexibility makes it easy to do the wrong thing, eg. n+1 problems where a query hits the same data source multiple times. Apollo Server handles this by adding data sources that be cached.

Another issue is security – because queries can have unlimited depth and complexity, which is bad when devs do it and REALLY bad if a bad actor is doing it. Apollo operation registry can lock the system down to allowed queries – that limits what anyone can do if they get in.

How do you get started with GraphQL? Demo time!

(full walk through of building an app with GraphQL)