GRAPHQL Josh Price @joshprice STEPPING STONES TO FP Language - - PowerPoint PPT Presentation

▶
graphql
SMART_READER_LITE
LIVE PREVIEW

GRAPHQL Josh Price @joshprice STEPPING STONES TO FP Language - - PowerPoint PPT Presentation

Feb 07, 2024 351 likes •1.32k views

The Future of the Realtime Web BETTER APIS WITH GRAPHQL Josh Price @joshprice STEPPING STONES TO FP Language (Elixir) Strongly-Typed APIs (GraphQL) GRAPHQL WAS HERE? http://whiteafrican.com/2008/05/12/crossing-the-mapping-chasm/ A

slide-1
SLIDE 1

BETTER APIS WITH

The Future of the Realtime Web

Josh Price @joshprice

GRAPHQL

slide-2
SLIDE 2
slide-3
SLIDE 3

STEPPING STONES TO FP

Language (Elixir) Strongly-Typed APIs (GraphQL)

slide-4
SLIDE 4

GRAPHQL WAS HERE?

http://whiteafrican.com/2008/05/12/crossing-the-mapping-chasm/
slide-5
SLIDE 5

COMMON ISSUES WITH REST

A TAXONOMY OF

slide-6
SLIDE 6

PERFORMANCE

slide-7
SLIDE 7

UNDERFETCHING

slide-8
SLIDE 8 COMMON ISSUES WITH REST

UNDERFETCHING

▸ N + 1 HTTP request problem ▸ eg. Fetched a Blog Post but not Comments ▸ Must make more requests to fulfil data requirements ▸ For complex views we saw 6-7 requests (usually serial) ▸ Have seen up to 25+ requests in the wild

slide-9
SLIDE 9

OVERFETCHING

slide-10
SLIDE 10 COMMON ISSUES WITH REST

OVERFETCHING

▸ Client wants a small subset of data from endpoint ▸ But gets everything regardless ▸ The addition of fields to a endpoint bloats payloads ▸ Create more endpoints, but this means more roundtrips ▸ Could create a homepage specific endpoint for each device,

but harder to manage

slide-11
SLIDE 11

BIG UPFRONT DESIGN

slide-12
SLIDE 12 COMMON ISSUES WITH REST

BIG UPFRONT DESIGN NEEDED

▸ Need to anticipate all current and future clients’ needs ▸ ie Mobile v Web clients ▸ Could have multiple representations/endpoints ▸ Divergence of server code ▸ Keeping everything in sync is hard

slide-13
SLIDE 13

HYPERMEDIA?

slide-14
SLIDE 14 COMMON ISSUES WITH REST

HYPERMEDIA ISN’T ALWAYS APPLICABLE

▸ If you control the clients and the server ▸ Less useful for your web or mobile app calling a known API

1000x / sec

▸ Semantics are communicated out of the ▸ A self-describing, well-typed API is an alternative approach

slide-15
SLIDE 15

GRAPHQL

slide-16
SLIDE 16 GRAPHQL HISTORY

WHAT IS GRAPHQL?

▸ Language for defining schemas, types & queries ▸ It’s a specification for that language (like OpenAPI, Swagger) ▸ Developed by Facebook in 2012 ▸ Used internally to improve mobile app performance ▸ Served 300B+ requests per day (1.6B DAU on mobile) ▸ Open sourced spec in mid 2015

slide-17
SLIDE 17

DATA FETCHING

GENERALISED

slide-18
SLIDE 18
slide-19
SLIDE 19

EASIER TO BUILD

GRAPHQL APIS ARE

slide-20
SLIDE 20

EASIER TO CONSUME

GRAPHQL APIS ARE

slide-21
SLIDE 21

PERFORMANCE

BETTER

slide-22
SLIDE 22

SELF DOCUMENTING

SELF DESCRIBING AND

slide-23
SLIDE 23

CONSUMER DRIVEN CONTRACTS

EXPOSE YOUR DOMAIN MODEL VIA

slide-24
SLIDE 24

ISOMORPHIC

QUERIES AND RESPONSES ARE

slide-25
SLIDE 25

STRONGLY TYPED APIS

TYPES IN YOUR SCHEMA ==

slide-26
SLIDE 26

EASIER EVOLUTION

BUILT-IN FIELD DEPRECATION MEANS

slide-27
SLIDE 27

MYTHS & MISCONCEPTIONS

slide-28
SLIDE 28

GRAPH DATABASE

YOU DO NOT NEED A

slide-29
SLIDE 29

QUERY LANGUAGE

THIS IS NOT YOUR TYPICAL

slide-30
SLIDE 30

LANGUAGE AGNOSTIC

NOT ONLY FOR JAVASCRIPT

slide-31
SLIDE 31

HTTP OR JSON

NOT DEPENDENT ON

slide-32
SLIDE 32

DOES NOT REPLACE REST

IT’S EASIER TO WORK WITH BUT

slide-33
SLIDE 33

MAKES REST EASIER

POTENTIALLY

slide-34
SLIDE 34

GRAPHQL CONCEPTS

LET’S LEARN SOME

slide-35
SLIDE 35

SCHEMAS, TYPES AND SCALARS

type Meetup { title: String! date: Date description: String url: URL! talks: [Talk!]! } type Talk { title: String! description: Markdown presenter: Person! } schema { query: Query mutation: Mutation }

GraphQL SDL

slide-36
SLIDE 36

SCHEMAS, TYPES AND SCALARS

type Meetup { title: String! date: Date description: String url: URL! talks: [Talk!]! } type Talk { title: String! description: String presenter: Person! } schema { query: Query mutation: Mutation } @desc "A meetup”
  • bject :meetup do
@desc "The title of the meetup" field :title, non_null(:string) @desc "The date of the meetup" field :date, :date @desc "The description of the meetup" field :description, :string @desc "The Meetup.com url" field :url, :string @desc "The talks at the meetup" field :talks, list_of(:talk) end

GraphQL SDL Elixir with Absinthe

slide-37
SLIDE 37 GRAPHQL CONCEPTS

RESOLVER FUNCTIONS FETCH YOUR DATA

▸ Resolver functions fetch (or update) data ▸ Called when query fields are matched against schema fields ▸ Return data or an error ▸ Can take arguments specified in schema ▸ Can take a context in from the query (ie current user for

authentication and authorisation)

slide-38
SLIDE 38 GRAPHQL CONCEPTS

RESOLVER FUNCTIONS (ELIXIR EXAMPLE)

defmodule GraphqlSydney.GraphQL.Schema do use Absinthe.Schema alias GraphqlSydney.Events import_types Absinthe.Type.Custom query do @desc "Get the next meetup" field :next_meetup, type: :meetup do resolve fn _, _ -> {:ok, Events.next_meetup} end end @desc "Get the previous meetups" field :previous_meetups, type: list_of(:meetup) do resolve fn _, _ -> {:ok, Events.past_meetups} end end end end
slide-39
SLIDE 39 GRAPHQL CONCEPTS

QUERY PROCESSING PIPELINE

▸ Client send Query documents as Strings ▸ Server Parses into AST ▸ Validation of AST ▸ Query fields matched against Schema ▸ Matching resolver functions executed ▸ Data (and errors) returned to client as a Map

slide-40
SLIDE 40 1 2 3 4 CLIENT DB CMS

SIMPLE QUERY LIFECYCLE

Query (String) Response (Map) Data Fetching Run Resolver Functions
slide-41
SLIDE 41

LET’S SEE IT IN ACTION!

slide-42
SLIDE 42
slide-43
SLIDE 43

QUERY: FETCH NEXT MEETUP

slide-44
SLIDE 44

QUERY: AUTOCOMPLETE / AUTOCORRECTION

slide-45
SLIDE 45

QUERY: FETCH NEXT MEETUP’S TALKS

slide-46
SLIDE 46

QUERY: INLINE DOCUMENTATION

slide-47
SLIDE 47

QUERY: MEETUP WITH TALKS AND PRESENTERS

slide-48
SLIDE 48

GETTING STARTED

slide-49
SLIDE 49 HOW TO GET STARTED WITH GRAPHQL

STEP 1: PICK A SERVER IMPLEMENTATION

▸ JavaScript reference implementation ▸ Apollo Server Tools ▸ Java / Scala (Sangria) ▸ .NET / F# ▸ Ruby / Python / PHP ▸ Elixir / Erlang ▸ Go / Rust / Haskell

slide-50
SLIDE 50 HOW TO GET STARTED WITH GRAPHQL

STEP 2: WRITE YOUR SCHEMA

▸ Figure out your domain types ▸ Write top level queries for reads ▸ Add mutations for writes ▸ Subscriptions for reactive data changes ▸ Don’t forget field descriptions!

slide-51
SLIDE 51 HOW TO GET STARTED WITH GRAPHQL

STEP 3: CHOOSE A CLIENT

▸ Relay Modern ▸ Declare data requirements of UI component as query fragments ▸ Sends a single query ▸ Render collects query fragments in the render tree ▸ Caches objects by unique ID ▸ Added graph convention of nodes and edges ▸ Pagination metadata, etc ▸ Not actually part of the spec and can be confusing

slide-52
SLIDE 52 HOW TO GET STARTED WITH GRAPHQL

STEP 3: CHOOSE A CLIENT

▸ Apollo 2.0 ▸ Bit simpler than Relay, no graph conventions ▸ Hand rolled queries for each view ▸ Handles client side caching ▸ Probably easiest to start here ▸ Also has native iOS and Android client libs

slide-53
SLIDE 53 HOW TO GET STARTED WITH GRAPHQL

STEP 4: PROFIT

▸ Start with read only first ▸ Shim existing REST APIs ▸ Frontend and Backend need to be on board ▸ Easy to experiment ▸ Try it out on new non-critical path projects

slide-54
SLIDE 54

THINGS TO WATCH OUT FOR

slide-55
SLIDE 55 THINGS TO WATCH OUT FOR

COMPLEX AND PATHOLOGICAL QUERIES

▸ Denial of Service possible for slow queries ▸ Be careful with exposing sorting, filtering and aggregation ▸ ie Don’t expose a sort field without an index ▸ Limit query depth and/or complexity ▸ Not all implementations have this though ▸ Instrumentation can alleviate this

slide-56
SLIDE 56 THINGS TO WATCH OUT FOR

AVOID “STRINGLY TYPING”

▸ It’s very easy overuse plain String types ▸ You lose information: makes mocking harder ▸ There are no type aliases in the spec (yet) ▸ Can write your own custom Scalars (impl specific) ▸ Fine-grained “Micro-types” are useful ▸ ie URL, Email, Markdown, Name, Money, etc

slide-57
SLIDE 57 THINGS TO WATCH OUT FOR

NO HTTP CACHING

▸ Can send queries by GET ▸ POST is preferred ▸ Can’t use standard HTTP caching ▸ Varnish, Squid, etc ▸ Can cache elsewhere however ▸ Client, Resolvers, Data Store, etc

slide-58
SLIDE 58

RICH TOOLING ECOSYSTEM

slide-59
SLIDE 59

EXPORATION & VISUALISATION

slide-60
SLIDE 60
slide-61
SLIDE 61
slide-62
SLIDE 62
slide-63
SLIDE 63
slide-64
SLIDE 64
slide-65
SLIDE 65
slide-66
SLIDE 66

GRAPHQL SERVER ANALYTICS

slide-67
SLIDE 67
slide-68
SLIDE 68

QUERY EXECUTION TRACING

slide-69
SLIDE 69

INTEGRATED CACHE MANAGEMENT

slide-70
SLIDE 70

ERROR TRACKING

slide-71
SLIDE 71

SCHEMA ANALYSIS

slide-72
SLIDE 72

SCHEMA STITCHING AND COMPOSITION

slide-73
SLIDE 73

SCHEMA COMPOSITION

slide-74
SLIDE 74
slide-75
SLIDE 75

SCHEMA STITCHING GRAFT

slide-76
SLIDE 76 TOOL ECOSYSTEM

SCHEMA COMPOSITION TOOLS

▸ Apollo Schema Stitching ▸ https://dev-blog.apollodata.com/graphql-schema-

stitching-8af23354ac37

▸ Gramps the IBM microservice API composition framework ▸ https://github.com/gramps-graphql/gramps ▸ GraphQL Weaver ▸ https://github.com/AEB-labs/graphql-weaver

slide-77
SLIDE 77

API MOCKING

slide-78
SLIDE 78
slide-79
SLIDE 79

GRAPHQL STACKS

slide-80
SLIDE 80
slide-81
SLIDE 81
slide-82
SLIDE 82
slide-83
SLIDE 83
slide-84
SLIDE 84

CMS BACKENDS

slide-85
SLIDE 85
slide-86
SLIDE 86
slide-87
SLIDE 87

GRAPHQL BACKENDS AS A SERVICE

slide-88
SLIDE 88
slide-89
SLIDE 89
slide-90
SLIDE 90
slide-91
SLIDE 91

REALTIME APIS WITH SUBSCRIPTIONS

slide-92
SLIDE 92

REACTIVE BACKENDS

HTTP/2 PUSH AND THE RISE OF

slide-93
SLIDE 93

HAS GRAPHQL CROSSED THE CHASM?

slide-94
SLIDE 94
slide-95
SLIDE 95

GRAPHQL IS HERE

http://whiteafrican.com/2008/05/12/crossing-the-mapping-chasm/
slide-96
SLIDE 96 NEXT STEPS

RESOURCES

▸ http://graphql.org/ ▸ https://github.com/chentsulin/awesome-graphql ▸ https://www.apollographql.com/ ▸ https://facebook.github.io/relay/ ▸ GraphQL Summit Videos ▸ https://www.youtube.com/playlist?

list=PLpi1lPB6opQywks7yYYs5jJAIRI3faRTm