Overview of GraphQL & Clients

Overview of 
GraphQL & Clients
! # @zetavg 
fb.me/pokaichang72

My Background
⬢ Building stuﬀ as a web developer from
2012
⬢ Shallow experiences covered from
design, mobile, front-end and backend
develop to cloud deployments (AWS)
⬢ Fan of GraphQL/Relay of its beauty of
API design since 2015
⬢ Working at with Ruby,
JavaScript (React.js) and playing Elixir
⬢ Former tech lead at Colorgy
! # @zetavg 
fb.me/pokaichang72

⬡ Complain about RESTful Introduce GraphQL
⬡ Just enough GraphQL to get started
⬡ GraphQL client library overview
⬡ Intro to Relay
⬡ Demo: GraphQL & Relay on Rails 
https://github.com/zetavg/RailsRelayTodoMVC
Outline

The evolution of API
⬢ RESTful: Easy to use, easy to develop
⬡ Directly based on Wide World Web
⬡ URI as resource name (noun), HTTP method as
action (verb)
⬡ We need documents: Swagger...
⬡ ...and type deﬁnitions: JSON Schema
⬡ ...and data relations: JSON API
⬡ Combine them all: API Blueprint, RAML

The evolution of API
⬢ But for the front-end, especially SPA or mobile apps:
⬡ Querying complex data eﬃciently is still hard
⬡ We may come up with lots of endpoint versions
⬡ Or messy features on diﬀerent endpoints
⬡ On purpose specs are hard to follow, without an clear
interface, APIs tends to be hard to reuse and maintain
⬡ Writing code to fetch and store data is annoying
⬡ Caching is hard cause there's no explicit schema
⬡ Co-working may be messy cause there's no schema

/api/v1/posts.json
/api/v2/posts.json
/api/v3/posts.json
/api/v4/posts.json
/api/v65535/posts.json
⋯⋯

/api/posts.json
/api/posts.json?include=author
/api/posts.json?include=author,comments
/api/posts.json?cover=true&include=author,comments
/api/posts.json?cover=true&include=author,comments_

GraphQL
⬢ A new query language
⬢ Brief History:
⬡ 2012 － Used for Facebook mobile app
⬡ 2015 － Publicly released
⬡ 2017 － Now: GraphQL & Relay re-licensed under  
　　　　MIT
⬢ Normally uses a single endpoint URL ( POST /graphql )

All your application data  
can be represented as a graph

$
{
"name": "Pokai Chang",
"bio":"Yet another geek.",
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌],
"repos": [◌, ◌] 
}
$
{
"name": "Ja
"bio":"..."
"followers"
"repos": [◌
}
$
{
"name": "Pusheen",
"bio":"Nyan nyan nyan~",
"followers": [◌],
"repos": [◌] 
}
!
{
"name": "Thing Compiler",
"description": "...",
"stargazers": [◌, ◌, ◌] 
}
!
{
"name": "Hello World",
"stargazers": [◌, ◌] 
}
!
{
"name": "Handy Ut
"description": ".
"stargazers": [◌]
}
!
{
"name": "Awes
"description"
"stargazers":
}
!
{
"name": "Todo",
"stargazers": [◌] 
}
!
{ }
{
"viewer": ◌ 
}

A subset of the graph  
is used to show an UI

$
{
}
$
{
"name": "Pusheen",
"followers": [◌],
"repos": [◌] 
}
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌]
"repos": [◌, ◌] 
}
!
{
"n
"d
"s
}
!
{
"name": "Todo",
}
!
{
}
!
{
"name": "Thing Compile
"stargazers": [◌, ◌, ◌
}
!
{
"name"
"descr
"starg
}
{ }
{
"viewer": ◌ 
}
$
{
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}
$ dd
dd
dd
dd

!
{
}
!
{
}
!
{
"name"
"descr
"starg
}
!
{
"n
"d
"s
}
!
{
"name": "Todo",
}
{ }
{
"viewer": ◌ 
}
$
{
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌]
"repos": [◌, ◌] 
}
$
{
}
$
{
"name": "Pusheen",
"followers": [◌],
"repos": [◌] 
}
$
$
$
$
$
$

!
{
"name"
"descr
"starg
}
!
{
}
$
{
"name": "Pusheen",
"followers": [◌],
"repos": [◌] 
}
!
{
"n
"d
"s
}
!
{
"name": "Todo",
}
!
{
}
{ }
{
"viewer": ◌ 
}
$ $ $
$ $ $
$ $ $
$ $
/
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌]
"repos": [◌, ◌] 
}
$
{
}
$
{
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}

$
{
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌],
"repos": [◌, ◌] 
}
$
{
"name": "Ja
"bio":"..."
"followers"
"repos": [◌
}
$
{
"name": "Pusheen",
"followers": [◌],
"repos": [◌] 
}
!
{
}
!
{
}
!
{
"name": "Handy Ut
"description": ".
"stargazers": [◌]
}
!
{
"name": "Awes
"description"
"stargazers":
}
!
{
"name": "Todo",
}
!
{ }
{
"viewer": ◌ 
}
GraphQL

Basic Query
⬢ Starts with selecting ﬁelds on the query root
⬢ WYSIWYG
{
"data": {
"viewer": {
"name": "Pokai Chang"
}
}
}
query {
viewer {
name
}
}

Basic Query
⬢ Querying nested ﬁelds
{
"data": {
"viewer": {
"birthday": {
"month": 7,
"day": 2
}
}
}
}
query {
viewer {
name
birthday {
month
day
}
}
}

Types
⬢ Get the type of a object using the __typename
meta ﬁeld
{
"data": {
"viewer": {
"__typename": "User",
"birthday": {
"__typename": "Date"
}
}
}
}
query {
viewer {
__typename
birthday {
__typename
}
}
}

Type defs as docs
# GraphQL query language 
 
query {
viewer {
name
birthday {
month
day
}
following {
name
}
}
}
# GraphQL schema language 
 
type Query {
viewer: User
}
type User {
name: String! 
birthday: Date 
followers: [User]
following: [User]
}
type Date {
year: Integer
month: Integer
day: Integer
}

Non-Null & Lists
# GraphQL schema language 
 
type Query {
viewer: User
}
type User {
name: String! 
birthday: Date 
followers: [User]
following: [User]
}
type Date {
year: Integer
month: Integer
day: Integer
}
[<thing>] means an array of <thing> objects
! means that the ﬁeld is non-nullable

Arguments
⬢ Arguments can be deﬁned on ﬁelds
query {
user(id: 1) {
name
}
}

Arguments
⬢ Nested ﬁelds also can have arguments
query {
user(id: 1) {
name
repo(name: "awesome-graphql") {
name
description
}
}
}

Variables
⬢ A way to dynamically change arguments for ﬁelds
query ($userId: Int!, $repoName:String!) {
user(id: $userId) {
name
repo(name: $repoName) {
name
description
}
}
}
{ 
"userId": 1,
"repoName": "awesome-graphql"
}
+

Fragment
fragment profileFields on User {
name
bio
avatarUrl
}
query {
viewer {
...profileFields
}
user(id: 1) {
...profileFields
}
}
Pre-deﬁne a set of ﬁelds 
on a type or interface
as meaningful fragment

Interfaces
⬢ An abstract type that includes a set of ﬁelds that a
type must deﬁne to implement
⬢ Can be used for fragments
interface Actor {
id: ID!
name: String!
avatarUrl: String!
}
type User implements Actor {
id: ID!
name: String!
avatarUrl: String!
...
}
type Bot implements Actor {
id: ID!
# Sample Query
fragment actorFields on Actor {
name
bio
avatarUrl
}
query {
feed {
actor {
...actorFields
} 
verb

Mutate Data w/ Mutations
⬢ Mutation queries lives under mutation instead of 
query , and are ways how we can change the data
⬢ We can put the input data in arguments, changed
nodes will be returned in the selectable payload
⬢ It’s a convention like RESTful GET/POST that clients
rely on
mutation {
addComment(input: { subjectId: 1, body: "Hi." }) {
subject {
comments {
body
}
}
}
}

Input Types
⬢ Yes, inputs are also typed
input AddCommentInput {
subjectId: ID!
body: String!
}
mutation {
addComment(input: { subjectId: 1, body: "Hi." }) {
subject {
comments {
body
}
}
}
}

GraphiQL
⬢ An open source GraphQL playground

Query tree
⬢ Each query is a tree extracted from the graph
⬢ The query is resolved by traversing the tree and
resolving each ﬁeld
query {
viewer {
name 
bio
repos {
name 
description
}
}
}

$
{
"name": "J
"bio":"...
"followers
"repos": [
}
$
{
"name": "Pusheen",
"followers": [◌],
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌],
"repos": [◌, ◌] 
}
!
{
"name": "Awe
"description
"stargazers"
}
!
{
"name": "Todo",
}
!
!
{
}
!
{
}
!
{
"name": "Handy Ut
"description": ".
"stargazers": [◌]
{ }
{
"viewer": ◌ 
}
$
{
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}
Query tree

Query tree
!
{
}
!
{
}
!
{
"name": "Handy Util",
}
{ }
{
"viewer": ◌ 
}
$
{
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}

Fetching
Pagination 
Caching
Update
Optimistic Update
Realtime UI

Redux data ﬂow
View
State
subscribe
Redux Store

Redux data ﬂow
View
State
Reducer
Action
subscribe
prevState

Redux data ﬂow
View
State
Reducer
Action
subscribe
prevState
Backend ?

Redux data ﬂow
View
State
Reducer
Action
subscribe
prevState
Backend
Action
Action
Action

$
{
"name": "Neson",
"followers": [◌, ◌, ◌],
"repos": [◌, ◌, ◌] 
}
$
{
"name": "Lucy",
"bio":"...",
"followers": [◌],
"repos": [◌, ◌] 
}
$
{
"name": "Ja
"bio":"..."
"followers"
"repos": [◌
}
$
{
"name": "Pusheen",
"followers": [◌],
"repos": [◌] 
}
!
{
}
!
{
}
!
{
"name": "Handy Ut
"description": ".
"stargazers": [◌]
}
!
{
"name": "Awes
"description"
"stargazers":
}
!
{
"name": "Todo",
}
!
{ }
{
"viewer": ◌ 
}
GraphQL

Relay data fetching
View
$
$
$ $
$
dd
$ $ $ $
dd
dd
dd
Relay Store

Relay data fetching
viewer {
name
bio
}
View
dd
dd
dd
dd
viewer {
repos {
name
description
}
}
$
Relay Store

Relay data fetching
View
dd
dd
dd
dd
viewer {
repos {
name
description
}
}
Backend
query {
viewer { 
name 
bio
repos {
name
description
}
}
}
$
Relay Store
viewer {
name
bio
}

Relay data fetching
View
dd
dd
dd
dd
viewer {
repos {
name
description
}
}
Backend
{
"data": {
"viewer": { 
"name": "…",
"bio": "…",
"followers": […],
"repos": […]
}
}
}
$
viewer {
name
bio
}
query {
viewer { 
name 
bio
repos {
name
description
}
}
}

Relay data fetching
View
$
ㄎㄎㄎㄎ
viewer {
repos {
name
description
}
}
dd
dd
dd
dd
viewer {
name
bio
}

View
Relay data fetching
viewer {
name
bio
}
View
$
ㄎㄎㄎㄎ
viewer {
following {
name
}
}
dd
dd
dd
dd
$
$
$
$
$

View
Relay data fetching
viewer {
name
bio
}
View
$
ㄎㄎㄎㄎ
viewer {
following {
name
}
}
dd
dd
dd
dd
$
$
$
$
$
Backend
query {
viewer {
following {
name
}
}
}
{
"data": {
"viewer": {
"following": […]
}
}
}

View
Relay data fetching
viewer {
name
bio
}
View
$
ㄎㄎㄎㄎ
viewer {
following {
name
}
}
dd
dd
dd
dd
$
$
$
$
$
ㄎㄎㄎㄎ

Query tree
query {
user(login: "zetavg") {
name
repositories {
name
}
}
}
{
"data": {
"user": {
"repositories": [
{ "name": "dotfiles" },
{ "name": "Thing" },
{ "name": "Stuff" }
]
}
}
}

Query tree
Query Root
User
Repo Repo Repo
name
user(login: "zetavg")
"Pokai Chang"
"dotﬁles"
name repositories
name
"Thing"
name
"Stuﬀ"
query {
user(login: "zetavg") {
name
repositories {
name
}
}
}
{
"data": {
"user": {
"repositories": [
{ "name": "dotfiles" },
{ "name": "Thing" },
{ "name": "Stuff" }
]
}
}
}

Caching the query result
⬢ Strategy 1: traverse path
Query Root
User
Repo Repo Repo
name
"Pokai Chang"
"dotﬁles"
name repos
name
"Thing"
name
"Stuﬀ"
⬡ Same path, same object

Query Root
User
Repo Repo Repo
name
"Pokai Chang"
"dotﬁles"
name repos
name
"Thing"
name
"Stuﬀ"
user(login: "zetavg")/repos[2]
⬡ Same path, same object

Query Root
User
Repo Repo Repo
name
"Pokai Chang"
"dotfiles"
name repos
name
"Thing"
name
"Stuff"
repo(owner: "zetavg", name: "dotfiles")
Repo
name
"dotfiles"
⬡ Sometimes path assumption isn’t enough

Query Root
User
Repo Repo Repo
name
"Pokai Chang"
"dotfiles"
name repos
name
"Thing"
name
"Stuff"
Repo
name
"dotfiles"
Same object on different path
⬡ Sometimes path assumption isn’t enough

⬢ Strategy 0: object identifier
repo/dotfiles
Repo
name
"dotfiles"
repo/dotfiles
Repo
name
"dotfiles"
Query Root
User
Repo Repo
"Pokai Chang"
name repos
name
"Thing"
name
"Stuff"
repo/Thing repo/Stuff

Query Root
User
Repo Repo
"Pokai Chang"
name repos
name
"Thing"
name
"Stuff"
repo/Thing repo/Stuff
Repo
name
"dotfiles"
repo/dotfiles

⬡ Relay: we need the server to give a global id for
nodes that need to be identified
⬡ Apollo: client defines a dataIdFromObject
function that will be executed on every node
⬡ Fun fact: Relay stores each object it fetched in a
key-value store with the object id or traverse path
as key, any field that contains an object will actually
be the key of the object, so two objects having the
same id will be ensured the same by Implementation

⬢ Oﬀset based pagination, e.g.: per_page=5&page=1
Cursor?
page 1 page 2 page 3

⬢
Cursor?
1 2 3 4 5
page 1
Client fetches page 1

⬢
Cursor?
' Broken
1 2 3 4 5
page 1
Data inserted

⬢
Cursor?
' Broken
1 2 3 4 5
page 1 page 2
5 6 7 8 9
'
Client got malformed results

⬢
⬢ Cursor based pagination, e.g.: after: "…", next: 5
Cursor?
next 5next 5
' Broken

Relay Connections
⬢ The design of Relay Cursor Connections
query {
viewer {
friends(first: 10, after: "someCursor") {
edges {
cursor
node {
id
name
}
}
pageInfo {
hasNextPage
}
}
}
}
Edge (UserEdgeType)
Node (UserType)
{ … }
Cursor
Current cursor Connection
Edges
Edge (UserEdgeType)
Node (UserType)
{ … }
Cursor
Edge (UserEdgeTy
Node (UserType
{ … }
Cursor
Page Info
Starting cursor

Mutations
⬢ A mutation is a query that has side eﬀects
⬢ The changes made on the graph will be put on the
response, the client is responsible to select the
necessary parts
mutation {
renameRepo(input: {
repoID: "…",
name: "NewName"
}) {
repo { 
id
name
}
}
}
Grab the changes that are 
made on the existing repo

Mutations
⬢ A mutation is a query that has side eﬀects
⬢ The changes made on the graph will be put on the
response, the client is responsible to select the
necessary parts
⬢ In general, we need to write an updater function to
update the store with the payload: 
 
(oldState, payload) => newState
⬢ Relay and Apollo both has some conventions
⬡ Objects with matching identiﬁer in the store will be
updated automatically

Mutations
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Mutation
Store

Mutations
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Mutation
Server
Store

Mutations
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Mutation
Server
Updater
Store
Response

Mutations
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Mutation
Server
Updater
Store
Latency
Response
'

Optimistic Update
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Mutation
Store
Latency

Optimistic Update
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Mutation Optimistic Updater
Store
Latency
Optimistic Update
Layer

Optimistic Update
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Server
Updater
Store
Latency
Response
Optimistic Update
Layer

Optimistic Update
UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Server
Updater
Store
Latency
Response

GraphQL Live Query
⬢ Idea: after the client sends a query, server can push
updates of the query result to the client
⬢ May require a fully reactive backend
⬢ No open implementations yet

GraphQL Subscriptions
⬢ Clients can subscribe to a speciﬁc type of event as a
similar way as how we do mutations
⬢ Mutations are client-made changes while
Subscriptions are server-pushed updates
⬢ New query results will be pushed to the client when a
event occurred
subscription {
todoItemAddedToList(todoListID: "…") {
todoItem {
name
}
}
}

⬢ Clients can subscribe to a specific type of event as a
similar way as how we do mutations
⬢ Mutations are client-made changes while
Subscriptions are server-pushed updates
⬢ New query results will be pushed to the client when a
event occurred
⬢ GraphQL just tells us how things should work, we
need to configure different implementations
(WebSocket, APNS, GCM) of sending the data on
different platforms

UI
$
ㄎㄎㄎㄎ
dd
dd
dd
Subscription
Server
Updater
Store
When event occurred
On mount (normally)

References
⬢ GraphQL API Explorer
⬢ GraphQL Concepts Visualized
⬢ Mutations and Optimistic UI in Apollo Client
⬢ GraphQL Subscriptions in Apollo Client
⬢ https://github.com/zetavg/graphql-todomvc

Overview of GraphQL & Clients

More Related Content

What's hot

Similar to Overview of GraphQL & Clients

More from Pokai Chang

Recently uploaded

Overview of GraphQL & Clients