GraphQL, gRPC or REST? Resolving the API Developer's Dilemma

GraphQL, gRPC or REST? Resolving the API Developer's Dilemma

GraphQL, gRPC, REST and WebHooks are among a bewildering array of technologies and architectural styles that are available to API developers today. Presented with such myriad options, how can we be confident of making an appropriate decision for the problem at hand? In search of guidance, developers often turn to online communities. This can exacerbate the problem as discussions about API styles often descend into statements about the superiority of one approach over another being presented as universal truths. Such comments invariably earn emotive rebuttals that also lack sufficient nuance. The result of such exchanges is increased confusion and uncertainty. Join me on a tour of these API styles where we will cut through this noise, demonstrate where each style shines (plus where they don't!) and ultimately resolve this dilemma of choice.

In this session we'll take an in-depth look at API design; the best practices that have evolved; the game changing supporting technologies that are now available including HTTP/2; and most importantly what you need to do to deliver a world class developer experience:

- How to determine the suitability of an API style for your application context. Don't be a victim of technology hype!
- What is required to support graceful evolution of the API contract including the potential implications of both Hyrum's Law and the Law of Implicit Interfaces
- Understand the supporting toolchains and technologies that dovetail with each API style.
- The importance of treating your API as a product with an unwavering focus on improving the ease of consumption for your clients.

By the end of the session, you will not only understand the concepts underpinning these various API styles but also have the knowledge to put them into practice. If you want to take to your API design expertise to the next level,

3353b76e1480888ea7a482ebaa883dcb?s=128

Rob Crowley

August 03, 2019
Tweet

Transcript

  1. RESOLVING THE API DEVELOPER’S DILEMMA @ROBDCROWLEY | ROBDCROWLEY

  2. ▪ A TOUR OF API STYLES OVER TIME ▪ CONSTRAINTS

    AND INDUCED PROPERTIES ▪ MYTH BUSTING ▪ SAMPLE SCENARIOS
  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  10. None
  11. None
  12. None
  13. None
  14. None
  15. None
  16. ’ ’

  17. None
  18. None
  19. None
  20. None
  21. None
  22. Properties are induced by the set of constraints within an

    architecture
  23. CUSTOMER / BUSINESS / PRODUCT REQUIREMENTS

  24. IMPLICATIONS OF DISTRIBUTED SYSTEM COMPLEXITY, 8 FALLACIES, EVOLUTIONARY REQUIREMENTS

  25. SYSTEM OF WORK, CONWAY’S LAW, KNOWLEDGE / EXPERTISE

  26. None
  27. “ ”

  28. “ ”

  29. “ ”

  30. None
  31. None
  32. None
  33. None
  34. If an API is mostly actions, maybe it should be

    RPC. If an API is mostly CRUD and is manipulating related data, maybe it should be REST
  35. None
  36. ▪ API STYLES ADDRESS DIFFERENT PROBLEM SPACES ▪ RESTISH APIS

    WOULD MOST LIKELY BE BETTER AS GRAPHQL OR RPC ▪ gRPC IS PERFECT FOR SYCHRONOUS COMMUNICATIONS BETWEEN INTERNAL SERVICES
  37. “ “

  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. None
  46. ▪ THERE ARE MANY KINDS OF CACHES: CLIENT, SEVER AND

    NETWORK ▪ HIGHLY CUSTOMIZABLE APIS BENEFIT LESS FROM HTTP CACHING ▪ IF NETWORK CACHING IS VALUABLE THEN CONSIDER REST ▪ BEST PRACTICES ARE STILL EMERGING FOR GRAPHQL AND gRPC
  47. “ “

  48. None
  49. GRAPHQL ENABLES EACH CLIENT TO RETRIEVE EXACTLY THE DATA IT

    REQUIRES IN A SINGLE ROUND TRIP TO THE SERVER
  50. None
  51. None
  52. None
  53. None
  54. None
  55. ▪ WITH HTTP/1.X THE COST OF A HANDSHAKE WAS HIGH

    ▪ HTTP/2 REMOVES THE NEED FOR COMPOUND DOCUMENTS ▪ SERVER PUSH CREATES NEW POSSIBILITIES BUT PROFILE USE CASES THOROUGHLY
  56. “ “

  57. None
  58. None
  59. None
  60. ▪ DON’T ADD REQUIRED INPUTS ▪ DON’T REMOVE OUTPUTS OR

    MAKE THEM OPTIONAL ▪ DON’T CHANGE THE TYPE OF A FIELD ▪ FOLLOW THE ROBUSTNESS PRINCIPLE / POSTEL’S LAW
  61. None
  62. None
  63. None
  64. With a sufficient number of users of an API, it

    does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody. ’
  65. None
  66. Make a system evolvable by paying attention to the interfaces.

  67. None
  68. - Front end and back end teams agree on schema.

    - UI is developed using mocked data based on schema - API is built out with any changes being communicated to front end team - Integrate front and back ends - Ship - Repeat
  69. ▪ IS A TECHNIQUE TO MANAGE BREAKING CHANGES ▪ SHOULD

    BE A LAST RESORT, PREFER GRACEFUL EVOLUTION ▪ IS NOT A SUBSTITUTE FOR COMMUNICATING WITH USERS ▪ DOES NOT PROTECT AGAINST CONSUMERS DEPENDING ON IMPLICIT INTERFACE BEHAVIOUR
  70. “ “

  71. None
  72. None
  73. None
  74. ▪ API DESIGN SKILLS ARE TABLE STAKES IRRESPECTIVE OF STYLE

    ▪ DESIGING A REST API FOLLOWS OUTSIDE-IN FLOW ▪ GRAPHQL DELAYS THIS MOMENT TO PROFILING QUERIES
  75. None
  76. CRUD. SINGLE CLIENT THAT USES ALL FIELDS. USE CASE THAT

    IS WELL SUITED TO REST.
  77. AGGREGATE DATA FROM MULTIPLE SOURCES INTO ONE CONVENIENT API. PERFECT

    USE CASE FOR GRAPHQL.
  78. None
  79. SINGLE CLIENT. API IS STATIC AND WELL UNDERSTOOD. USE CASE

    WELL SUITED TO GRPC (I’M STILL EXPERIMENTING THOUGH!)
  80. None
  81. POLYGLOT ENVIRONMENT. GRPC IS PERFECT FOR SYCHRONOUS COMMUNICATION BETWEEN INTERNAL

    MICROSERVICES.
  82. None
  83. None
  84. None
  85. None
  86. None
  87. ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪

  88. ▪ ▪ ▪

  89. ▪ ▪ ▪ ▪ ▪ ▪ ▪