Upgrade to Pro — share decks privately, control downloads, hide ads and more …

It Depends - Examining GraphQL Myths & Assumptions

It Depends - Examining GraphQL Myths & Assumptions

F34d97ba1bfea0ff5e35a9c198562402?s=128

Marc-Andre Giroux

December 07, 2020
Tweet

Transcript

  1. Marc-Andre Giroux - GraphQL Galaxy 2020 It Depends Examining GraphQL

    Myths & Assumptions
  2. Marc-Andre Giroux GitHub Montreal, Canada

  3. It Depends

  4. Caching We’re thinking of using GraphQL as our API Terrible

    mistake! Say bye to caching.
  5. None
  6. None
  7. https://tools.ietf.org/html/rfc7234

  8. None
  9. None
  10. Solutions must be looked at from a specific context

  11. There’s some truth to it

  12. Conventions

  13. Flexibility vs Cache Hits

  14. Performance We’re thinking of using GraphQL as our API Cool!

    Why are you choosing GraphQL over other API styles? Because… performance!
  15. Is GraphQL faster than ____?

  16. GET /user { viewer { name age } }

  17. The trade-off, though, is that a uniform interface degrades efficiency,

    since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
  18. One Query to Rule them All

  19. viewer { contributionsCollection { commitContributionsByRepository { contributions { nodes {

    commitCount } } } } repositories(first: 100) { nodes { name issues(first: 100) { nodes { body } } } } issues(first: 100) { edges { node { author { login } } } }
  20. @defer & @stream

  21. viewer { contributionsCollection { commitContributionsByRepository { contributions { nodes {

    commitCount } } } } repositories(first: 100) @defer { nodes { name issues(first: 100) { nodes { body } } } } issues(first: 100) @defer { edges { node { author { login } } } }
  22. Full Circle?

  23. Make Tradeoffs, Mitigate Downsides

  24. Predictability

  25. BFF The Backend-For-Frontend Pattern

  26. https://samnewman.io/patterns/architectural/bff/

  27. BFFs are not only about representation

  28. Autonomy

  29. type User { name: String! age: Int! Friends: [User!]! }

  30. type User { name: String! nameForAndroid: String! age: Int! ageForThisOneClient:

    Int! friends: [User!]! friendsForXBOX: [XBOXFriend!]! }
  31. Complete Separation

  32. “One Graph”

  33. type User { name: String! nameForAndroid: String! age: Int! ageForThisOneClient:

    Int! friends: [User!]! friendsForXBOX: [XBOXFriend!]! }
  34. It Depends

  35. Why this is important

  36. We want GraphQL to succeed

  37. We want developers using GraphQL to succeed.

  38. In which context?

  39. Compared to what?

  40. What are the trade-offs?

  41. Thank You! @__xuorig__ book.productionreadygraphql.com twitch.tv/graphqlfm - youtube.com/c/GraphQLFM/ (30% OFF GRAPHQLGALAXY30)