The Future of the Realtime Web BETTER APIS WITH GRAPHQL. Josh

Transcription

1 The Future of the Realtime Web BETTER APIS WITH GRAPHQL Josh

2

3 STEPPING STONES TO FP Language (Elixir) Strongly-Typed APIs (GraphQL)

4 GRAPHQL WAS HERE?

5 A TAXONOMY OF COMMON ISSUES WITH REST

6 PERFORMANCE

7 UNDERFETCHING

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

9 OVERFETCHING

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

11 BIG UPFRONT DESIGN

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

13 HYPERMEDIA?

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

15 GRAPHQL

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

17 GENERALISED DATA FETCHING

18

19 GRAPHQL APIS ARE EASIER TO BUILD

20 GRAPHQL APIS ARE EASIER TO CONSUME

21 BETTER PERFORMANCE

22 SELF DESCRIBING AND SELF DOCUMENTING

23 EXPOSE YOUR DOMAIN MODEL VIA CONSUMER DRIVEN CONTRACTS

24 QUERIES AND RESPONSES ARE ISOMORPHIC

25 TYPES IN YOUR SCHEMA == STRONGLY TYPED APIS

26 BUILT-IN FIELD DEPRECATION MEANS EASIER EVOLUTION

27 MYTHS & MISCONCEPTIONS

28 YOU DO NOT NEED A GRAPH DATABASE

29 THIS IS NOT YOUR TYPICAL QUERY LANGUAGE

30 NOT ONLY FOR JAVASCRIPT LANGUAGE AGNOSTIC

31 NOT DEPENDENT ON HTTP OR JSON

32 IT S EASIER TO WORK WITH BUT DOES NOT REPLACE REST

33 POTENTIALLY MAKES REST EASIER

34 LET S LEARN SOME GRAPHQL CONCEPTS

35 SCHEMAS, TYPES AND SCALARS GraphQL SDL 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 }

36 SCHEMAS, TYPES AND SCALARS GraphQL SDL Elixir with Absinthe 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 "A meetup object :meetup "The title of the meetup" field :title, "The date of the meetup" field :date, "The description of the meetup" field :description, "The Meetup.com url" field :url, "The talks at the meetup" field :talks, list_of(:talk) end

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)

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

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

40 SIMPLE QUERY LIFECYCLE Run Resolver Functions Data Fetching 1 Query (String) 2 DB CLIENT 4 Response (Map) 3 CMS

41 LET S SEE IT IN ACTION!

42

43 QUERY: FETCH NEXT MEETUP

44 QUERY: AUTOCOMPLETE / AUTOCORRECTION

45 QUERY: FETCH NEXT MEETUP S TALKS

46 QUERY: INLINE DOCUMENTATION

47 QUERY: MEETUP WITH TALKS AND PRESENTERS

48 GETTING STARTED

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

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!

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

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

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

54 THINGS TO WATCH OUT FOR

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

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, , Markdown, Name, Money, etc

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

58 RICH TOOLING ECOSYSTEM

59 EXPORATION & VISUALISATION

60

61

62

63

64

65

66 GRAPHQL SERVER ANALYTICS

67

68 QUERY EXECUTION TRACING

69 INTEGRATED CACHE MANAGEMENT

70 ERROR TRACKING

71 SCHEMA ANALYSIS

72 SCHEMA STITCHING AND COMPOSITION

73 SCHEMA COMPOSITION

74

75 SCHEMA STITCHING GRAFT

76 TOOL ECOSYSTEM SCHEMA COMPOSITION TOOLS Apollo Schema Stitching Gramps the IBM microservice API composition framework GraphQL Weaver

77 API MOCKING

78

79 GRAPHQL STACKS

80

81

82

83

84 CMS BACKENDS

85

86

87 GRAPHQL BACKENDS AS A SERVICE

88

89

90

91 REALTIME APIS WITH SUBSCRIPTIONS

92 HTTP/2 PUSH AND THE RISE OF REACTIVE BACKENDS

93 HAS GRAPHQL CROSSED THE CHASM?

94

95 GRAPHQL IS HERE

96 NEXT STEPS RESOURCES GraphQL Summit Videos list=plpi1lpb6opqywks7yyys5jjairi3fartm