...And GraphQL for All? A few things to think about before blindly dumping REST for GraphQL

GraphQL is new. GraphQL is cool. Look! Github dumped REST for it! We MUST do it too! Well, why not. GraphQL could be a great tool, but like any tool, you don't choose it "just because".You choose it because it solves a problem in a given context. You choose it knowing its strengths and weaknesses.

During this session, while discovering what is GraphQL we will see what REST API providers should think about before blindly dumping REST for it. From design and implementation to pricing model and analytics down to developers experience and implementations, choosing an API design style will have impact on the whole API lifecycle. Therefore, this choice must be an enligthned one and not based on simple beliefs.

Transcript

1. … and GraphQL for ALL?
2. Arnaud Lauret @apihandyman
3. apistylebook.com Collections Of Resources For API Designers
6. Feelings
8. Context
9. Feelings vs Context
10. API Style Impacts Whole API Lifecyle
11. … and GraphQL for all? a few things to think about before blindly dump REST for GraphQL
12. What is GraphQL?
13. Query Language for Data
14. WYWIWYG
15. Queries Track 1
16. { viewer { name avatarURL } } GET /user
17. POST https://api.github.com/graphql { "query": "{ me: viewer { name avatarURL} }" }
18. { "data": { "viewer": { "name": "Arnaud Lauret", "avatarURL": "https://avatars0.githubus…" } } }
19. { me: viewer { fullname: name picture: avatarURL } }
20. { "data": { "me": { "fullname": "Arnaud Lauret", "picture": "https://avatars0.githubus…" } } }
21. GET /user GET /user/repos?sort=created&direction=desc
22. { me: viewer { fullname: name picture: avatarURL repositories( first: 2, orderBy: {field: CREATED_AT, direction: DESC}) { edges { node { name }}}}}
23. { "data": { "me": { "fullname": "Arnaud Lauret", "picture": "https://avatars0.githubus...", "repositories": { "edges": [ {"node": { "name": "apistylebook-api"} }, { "node": { "name": "restfest-videos-data"}} ] }}}}
24. { me: viewer { name avatarURL } kin: user(login: "kinlane") { name avatarURL } mike: user(login: "mamund") { name avatarURL } graphqlRepos: search( first: 5, query: "graphql", type: REPOSITORY) { edges { node { ... on Repository { name description }}}} }
25. Not SQL nor ETL Track 2
26. { "data": { "me": { "myFirstTwoRepos": { "edges": [ { "repo": { "name": "a-repo" } } ] }}}} { "data": { "me": { "myFirstTwoRepos": [ {"name": "a-repo"} ] }}} X
27. Schema Track 3
28. { __type(name:"User") { fields { name description } } }
30. GraphQL ecosystem Track 4
31. Consumer Libraries GraphiQL Explorer Server Libraries
32. GraphQL in a nutshell Track 5
33. • Data you need • Less data volume • Less API calls • Schema • Providers and consumers tools
34. learngraphql.com developer.github.com/early-access/graphql/
35. Fascinating but let’s keep a cool head
37. Queries Semantic Track 1
38. GET /users/{id} PATCH /users/{id} DELETE /users/{id} Consistency & Predictability
39. Query: Read Mutation: Write
40. query { user(id: "{id}") { name } } mutation { } Inconsistency & Unpredictability deleteUser(id: "{id}") removeUser(id: "{id}") suppressPeople(id: "{id}")
41. Errors Semantic Track 2
42. 404 = Shared Semantic Humans And Machines
43. { user(login: "unknown-user") { name } }
44. Could not resolve to a User with the login of 'unknown-user'
45. { user { name } }
46. Field 'user' is missing required arguments: login = Specific Semantic Humans Only
47. Focusing on data instead of actions Track 3
48. Hypermedia REST = Process
49. GraphQL = Data
50. Client Caching Track 4
51. REST = Standard HTTP protocol caching
52. GraphQL = Custom Client Caching
53. GraphQL DX in a nutshell Track 5
54. • More flexibility • Less predictability and consistency • Less guidance in process • More Responsability
55. Good or Bad? ...it depends!
57. “If you suck at providing REST API You’ll suck at providing GraphQL API” Arnaud Lauret, @apihandyman
58. GraphQL will not solve your API design problems Track 1
59. Still a well designed consumer friendly abstraction
60. Need stronger governance
61. GraphQL will not solve your API documentation problems Track 2
62. A5 Amsus2 B B5 B7 B7/D# C C5 C#5 Cadd9 D D5 D#5 E5 Em F#m G
63. Interface Description it not Documentation
64. Less data may be more data and more CPU Track 3
65. Bandwidth Usage
66. Lazy consumers
67. Analytics and Pricing Track 4
68. Query used + Query depth + Data Volume ---------------- Pricing?
69. API Gateway Impacts?
70. GraphQL PX in a nutshell Track 5
71. Same Challenges As REST But From A New Perspective
72. • Design Governance • Documentation • Architecture And Infrastructure • Pricing Model • API Tooling
75. IT DEPENDS!!!
76. Thank you