Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GraphQL - A love story

254 views

Published on

My VISUG XL talk about GraphQL

Published in: Software
  • Be the first to comment

  • Be the first to like this

GraphQL - A love story

  1. 1. GraphQL - A love story Bart Wullems http://bartwullems.blogspot.com bart.wullems@ordina.be
  2. 2. REST
  3. 3. What ABOUT REST? • 90’s : SOAP, RPC, XML HELL • 2000: Roy Fielding “Representational state transfer” • HTTP • Client-Server architecture • Web Resources • Statelessness • Layered System • Uniform interface • Great ideas in REST • REST is an architectural style: the concept was wildly interpreted
  4. 4. REST SERVICE – The blogging app example Give me user ‘Mary’, her post titles and the last 3 follower names
  5. 5. REST FLAVORS IN THE WILD – ‘TRUEISH REST’ • For every resource a separate request is send + Clean, re-usable API design - Overhead(3 requests) - A lot of data (all post and follower data) /api/user/<id> /api/user/<id>/posts /api/user/<id>/followers
  6. 6. REST FLAVORS IN THE WILD – ‘RPC REST’ • One request that returns all posts with followers - RPC style API, results in a lot of similar methods + Less overhead(1 request) - A lot of data (all user data for every follower) /api/<userid>/postswithfollowers
  7. 7. REST FLAVORS IN THE WILD – ‘TAILORED REST’ • One request tailor made for a specific client - RPC style API, results in a lot of similar methods + Little overhead(1 request) - Minimized dataset(only data required by the client is returned) /api/getpostswithlast3followernames
  8. 8. Disadvantages of REST • Trade-off between generic and specific endpoints • Generic endpoints typically overfetch data • Specific endpoints (per view) are getting pretty ugly to version hell • Over- or under-fetching of data is unavoidable 8
  9. 9. A better REST?
  10. 10. GRAPHQL
  11. 11. What is GraphQL? • New api standard that was invented & open-sourced by Facebook • Used internally since 2012 • Open source version published in July 2015 • A query language for APIs • GraphQL server exposes a single endpoint and responds to queries • Specification: https://facebook.github.io/graphql
  12. 12. What is GraphQL? • A runtime for fullfilling those queries… • A GraphQL server takes a query and returns a response in the exact same shape • Each field in the query selection set is “resolved” by a server side function • GraphQL provides a standard contract allowing clients to talk to any number of backend stores
  13. 13. Makes it easier to evolve APIs over time • GraphQL requires that every request specifies every field • We know what is being used= we can deprecate with confidence • Schema allows for marking fields as depecrated
  14. 14. GRAPHQL SERVICE – The blogging app example(again) Give me user ‘Mary’, her post titles and the last 3 follower names
  15. 15. GRAPHQL - Fetch everything with a single request
  16. 16. Languages
  17. 17. Who is using GraphQL 17
  18. 18. GRAPHQL in .NET
  19. 19. Rich ecosystem and tooling for GraphQL developers • Optimized, caching and offline client libraries • Introspection • Code generation • IDE integration • Data visualizations
  20. 20. Demo – GraphQL Hello World
  21. 21. GraphQL Schema
  22. 22. GraphQL Schema • Defines capabilities of the API by specifying how a client can fetch and update data • Represents the contract between client and server • Collection of GraphQL types with special root type
  23. 23. GraphQL Schema • Schema is defined with SDL(Schema Definition Language) • Support for advanced types • Object, Interface, Union, Enum, Input, Scalar • Self-documenting • Allows code generation
  24. 24. Demo – Building up the schema
  25. 25. GraphQL Operations • There are 3 operation types: • Query • Mutation • Subscription • Variables are optional. When using variables, clients send a “variables” object containing the values alongside the query
  26. 26. Queries
  27. 27. Fetching data with queries
  28. 28. Fields • GraphQL queries consist of a set of fields • GraphQL server has one resolver function per field • The purpose of each resolver is to retrieve the corresponding data
  29. 29. Selection sets • Selection sets specify what fields to resolve and thus what data to return • Selection sets can be nested arbitrarily
  30. 30. Demo – Introducing a first query
  31. 31. Interfaces
  32. 32. Interfaces • Defines a common set of fields • Object types implement interfaces
  33. 33. Demo – Introducing interfaces
  34. 34. Inline fragments
  35. 35. Inline fragments • Used to ask for a field on a specific object type
  36. 36. Demo – Inline fragments
  37. 37. Unions • Union types are very similar to interfaces, but they don’t need to specify any common fields between the types
  38. 38. Demo – Introducing unions
  39. 39. Mutations
  40. 40. Writing data with mutations
  41. 41. Demo – Mutations
  42. 42. Subscriptions
  43. 43. Realtime updates with subscriptions
  44. 44. Demo – Subscriptions
  45. 45. Resolvers
  46. 46. Resolvers (again) • Resolvers describe the logic that fetches data for a specific field. • Field resolvers run independently of each other which allows the execution engine to parallelize their execution. • Allows to build powerful schemas that consists of multiple data sources in a very simple way.
  47. 47. Demo - Resolvers
  48. 48. N+1 Queries Problem • Without a caching or batching mechanism, it's easy for a naive GraphQL server to issue new (database) requests each time a field is resolved. • Especially happen when clients send deeply nested queries. • Solution: Optimizing requests with the DataLoader 48
  49. 49. Demo - Dataloaders
  50. 50. GraphQL Architectures
  51. 51. GraphQL is only a specification
  52. 52. Architectural Use Case 1 • GraphQL server with a connected database • Uses single server that implements GraphQL • Server resolves queries and constructs responses with data that it fetches from the database
  53. 53. Architectural Use Case 2 • GraphQL server integrating existing systems • Unify existing systems • The server doesn’t care what the data sources are • Serves as BFF
  54. 54. Architectural Use Case 3 • Hybrid approach • Combines connected database and integrated systems
  55. 55. Conclusion
  56. 56. Reasons to love GraphQL • No more over- and underfetching • Rapid product iterations – no need to change API when product requirements and design change • Fine-grained about what data is read by clients – enables API evolvability • Benefits of schema and types – allows amazing developer productivity and tooling support
  57. 57. Topics I didn’t cover • Pagination • Filtering and sorting • Directives • Fragments • Authorization • Middleware • Tracing & Instrumentation • Schema stitching • Validation • Batching • Persisted Queries • Federation • Aliases • Error Handling • Thinking in Graphs • Caching
  58. 58. developers

×