Why UI developers love GraphQL

Why UI developers love GraphQLCoursera, 9.20.16

A special place in the stackRight between frontend and backend devs

Backend devs implement the APIGraphQL is an API technology, so it must make sense to backend people:

- Describe data with strong types- Potential for more efficient responses because of explicit fields- Easy to refactor backend to microservices

What do you get as a frontend dev?

Speed up your UI development workflowGraphQL enables next-generation tools that let you think less about data fetching.

Think about what data you need, and it’s there.

How do you query a GraphQL API?// REST

fetch(`api.server.com/posts/1`).then(...)

// GraphQL - no special tools needed!

fetch(`api.server.com/graphql?

query={ post(id: 1) { title, content } }`).then(...)

Benefits over REST, without special client tools- Know exactly which fields we are going to get- Documentation and data exploration built in (something you usually only

get with BaaS!)- Nested data fetching is trivial

Basic toolingRealizing the query is more than just a string.

Getting at the query structure

- Tag the query to designate that it’s GraphQL- Use a simple regex or AST traversal to find

all of the queries- Alternative: put in .graphql files

Now the GraphQL query is far more than a “magic string” -- it’s a semantic unit of data fetching

const query = gql` query HumanQuery { human(id: "1000") { name height(unit: FOOT) } }`;

Static query validation and analysis

Without running the UI:

- Typos in fields- Wrong arguments- Deprecated fields- Identify field usage

apollostack/eslint-plugin-graphql

In-editor autocomplete

- Today: in IntelliJ- Tomorrow: everywhere

with the upcoming GraphQL language service

jimkyndemeyer/js-graphql-intellij-plugin

It’s super easy to build new toolsGraphQL.js: Facebook’s GraphQL tools platform, includes parsing, validation, traversal, etc: graphql/graphql-js

GraphQL AST: Super nice to work with, matches up with the spec 1:1, you can use AST explorer: astexplorer.net

Introspection: Every GraphQL server is required to provide info in a standard format that works with all tools: graphql.org/learn/introspection/

Caching clientsUsing the query structure on the client at runtime.

Relay

How might we cache REST?1. Use URL as cache key

fetchOrLoadFromCache(`/posts/1`)

2. Write custom normalizer for Redux: decompose responses into objects, store them in separate fields. Might need to handle different endpoints manually, depending on your API design.

Caching GraphQL: Easier or harder?Using URLs or queries isn’t great:

fetchOrLoadFromCache(`/graphql?query={...}`)

But we gain much more potential: A fancy query structure that tells us exactly what fields we’re looking for.

Example: Overlapping queries

query bigQuery { post(id: 1) { title, content author { name, age } }}

query smallQuery { post(id: 1) { title, content }}

Easy to prefetch data and get subsets of previous queries.

Formalize as pathsWhat’s the atom of GraphQL data? A leaf field.

post(id: 1) -> title // bigQuery, smallQuery

post(id: 1) -> content // bigQuery, smallQuery

post(id: 1) -> author -> name // bigQuery

post(id: 1) -> author -> age // bigQuery

Lets us easily reason about the data we have fetched, replaces the URLs from REST. This is how Apollo Client works out of the box.

Cache consistency

query Sidebar { postFeed { title }}

query Post { post(id: 1) { title content }}

How do we make the title field for the post refer to one location in the cache?

Cache consistency

postFeed[0] -> title -> 'Original title'post(id: 1) -> title -> 'New title'

How do we make the title field for the post refer to one location in the cache?

Defining cache IDs for the client

Could be server-side like Relay or client-side like Apollo

(obj) => obj.__typename + ':' + obj.id

Paths with IDs

Now we can easily keep our cache consistent!

postFeed[0] -> (id: 1)post(id: 1) -> (id: 1)

(id: 1) -> title -> 'New title'

Data flowNow that we have a cache, let’s use it!

Updating the store updates the UI

Smart clients execute the queries when the store changes, keeping your UI consistent

query Sidebar { postFeed { title }}

Full data loading path

Smart clients execute the queries when the store changes, keeping your UI consistent

query Sidebar { postFeed { title }}

Fetcher

query Sidebar { postFeed { title }}

Normalizer

Updates can come from anywhere

It’s like automated Flux, which takes advantage of the GraphQL query structure

query Sidebar { postFeed { title }}

Other queries

Mutation results

Subscription results

Reduxactions

More toolsToday:

- Static code generation and native clients: apollo-ios- Pub/sub GraphQL subscriptions: graphql-subscriptions

Tomorrow:

- Client-side data- Cache expiration- Building your own bespoke clients

Let’s build the future together!