Why UI developers love GraphQL

Why UI developers love
GraphQL
Coursera, 9.20.16

A special place in the stack
Right between frontend and backend devs

Backend devs implement the API
GraphQL 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 workflow
GraphQL 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 tooling
Realizing 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 tools
GraphQL.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 clients
Using 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 paths
What’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 flow
Now 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
Redux
actions

More tools
Today:
- 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!

Why UI developers love GraphQL

More Related Content

What's hot (20)

Similar to Why UI developers love GraphQL (20)

Recently uploaded (20)

Why UI developers love GraphQL