Evaluating the State of APIs - Comparing REST, GraphQL, gRPC

Transcript

1. Evaluating the State of Modern APIs Comparing REST, GraphQL, and gRPC Spencer Schneidenbach
2. spencer@avironsoftware.com
3. Why? @schneidenbach
4. “X is dead, long live Y” @schneidenbach
6. There’s No Silver Bullet @schneidenbach
7. What we need to talk about • History of APIs • Use cases • Ease of adoption/use • Performance • Team constraints @schneidenbach
8. History Lesson @schneidenbach
9. How did we get here? REST RPC GraphQL @schneidenbach
10. How did we get here? SOAP REST RPC GraphQL @schneidenbach
11. Rough Timeline SOAP REST GraphQL gRPC @schneidenbach
12. First stop SOAP REST GraphQL gRPC @schneidenbach
13. SOAP @schneidenbach
14. SOAP • XML over HTTP (typically) • Contained request/response in “envelope” • Highly structured @schneidenbach
15. @schneidenbach
16. <definitions name = "HelloService" targetNamespace = "http://www.examples.com/wsdl/HelloService.wsdl" xmlns = "http://schemas.xmlsoap.org/wsdl/" xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns = "http://www.examples.com/wsdl/HelloService.wsdl" xmlns:xsd = "http://www.w3.org/2001/XMLSchema"> <message name = "SayHelloRequest"> <part name = "firstName" type = "xsd:string"/> </message> <message name = "SayHelloResponse"> <part name = "greeting" type = "xsd:string"/> </message> <portType name = "Hello_PortType"> <operation name = "sayHello"> <input message = "tns:SayHelloRequest"/> <output message = "tns:SayHelloResponse"/> </operation> </portType> https://www.tutorialspoint.com/wsdl/wsdl_quick_guide.htm @schneidenbach
17. Problems • Incongruent implementations across platforms • Heavy/noisy • Strictly XML based • Very sensitive to envelope/data construction format • nil/null vs empty string @schneidenbach
18. <operation name="sayHello"> @schneidenbach
19. RPC style @schneidenbach
20. https://stevenontheinternet.tumblr.com/post/62300850469/ninja-baby @schneidenbach
21. @schneidenbach
22. @schneidenbach Archival footage of developers protesting SOAP
23. REST stop SOAP REST GraphQL gRPC @schneidenbach
24. REST APIs to the rescue @schneidenbach
25. JSON to the rescue! REST to the rescue! { "actor": { "name": "Tom Cruise", "age": 56, "Born At": "Syracuse, NY", "Birthdate": "July 3 1962", "photo": "https://jsonformatter.org/img/tom-cruise.jpg" } } https://codeblogmoney.com/json-example-with-data-types-including-json-array/ @schneidenbach
26. What is REST? Representational State Transfer @schneidenbach
27. Uniform Interface Code on Demand (optional) Layered Stateless Cacheable Client-Server The Six Constraints of REST @schneidenbach
28. Resource identification Uniform Interface constraint Content-Type: application/json Resource manipulation with representations Self-descriptive Hypermedia as the engine of application state (HATEOAS) GET /employees/1234 PUT /employees/1234 @schneidenbach
29. What is a RESTful API? RESTful API == an API that follows REST architecture Term has been sort of co-opted REST != JSON REST != HTTP Lots of people say “REST API” when they really mean HTTP JSON API @schneidenbach
30. @schneidenbach
31. “REST kills SOAP” @schneidenbach
32. RPC-ish SOAP Envelopes Inconsistency XML @schneidenbach
33. POST /order Placing an order POST /payment POST /shipping @schneidenbach
34. @schneidenbach
35. @schneidenbach
36. POST /createOrder Placing an order @schneidenbach
37. REST Strengths • Ubiquitous, universally understood • Easy to start up in your favorite library • Hypermedia can be a boon… if implemented well/correctly • JSON/XML easy to read and descriptive @schneidenbach
38. REST Weaknesses • Over/under-fetching • Design-first - you have to well understand the use cases for your API ahead of time • Most APIs are not purely RESTful - not a bad thing, but is a thing • No built-in spec - lots can be generated/created after the fact (OpenAPI for instance) but not perfect • Versioning tricky @schneidenbach
39. “REST kills SOAP” …yeah, for the most part @schneidenbach
40. Next on our journey SOAP REST GraphQL gRPC @schneidenbach
41. GraphQL @schneidenbach
42. @schneidenbach
43. When we built Facebook’s mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers. https://engineering.fb.com/2015/09/14/core-data/graphql-a-data-query-language/ @schneidenbach
44. What they had • REST-based APIs were WAY too chatty • HTML views pushed up to the client weren’t mobile-optimized @schneidenbach
45. @schneidenbach
46. GraphQL has… • Strong spec • Predictable requests/responses • No over/under-fetching • Strongly typed • Nearly self-documenting • First-class deprecation @schneidenbach
47. How Does REST Get Related Resources? @schneidenbach
48. { "invoices": [ { ... }, { ... } ] } GET /customers/1234/ invoices GET /customers/ 1234 ?expand=invoices Within the parent object Related resource retrieval strategies As a separate request Using an expand parameter @schneidenbach
49. @schneidenbach
50. “REST in Peace” “Long live GraphQL” @schneidenbach
51. SOAP vs REST @schneidenbach
52. @schneidenbach
53. @schneidenbach
54. @schneidenbach
55. @schneidenbach
56. @schneidenbach
57. GraphQL weaknesses • Less ubiquitous from a framework/platform perspective • Caching more difficult • Steep learning curve for developers used to REST • Narrower use cases • Not as widely used @schneidenbach
58. @schneidenbach
59. Lessons Learned @schneidenbach
60. Last… for now SOAP REST GraphQL gRPC @schneidenbach
61. gRPC @schneidenbach
62. @schneidenbach
63. gRPC is based on many years of experience in building distributed systems. With the new framework, we want to bring to the developer community a modern, bandwidth and CPU ef fi cient, low latency way to create massively distributed systems that span data centers, as well as power mobile apps, real-time communications, IoT devices and APIs. https://developers.googleblog.com/2015/02/introducing-grpc-new-open-source-http2.html?m=1 @schneidenbach
64. HTTP/2 @schneidenbach
65. HTTP/2 • Support for multiplexing • Supports streams of data first-class • Multiple requests per one connection • Serialized in Protobuf format by default • Encryption NOT optional @schneidenbach
66. .proto file syntax = "proto3"; service Greeter { rpc SayHello (HelloRequest) returns (HelloReply); } message HelloRequest { string name = 1; } message HelloReply { string message = 1; } @schneidenbach
67. Advantages of gRPC • Strict contracts • Designed with performance in mind - less data over the wire and less connection overhead • Clients and servers can generate code from .proto files • Also helps enable polyglot development @schneidenbach
68. Challenges with gRPC • Not as widely known/adopted as REST/GraphQL • Bound to HTTP/2 (though this is less of an issue than it was when introduced) • No human readable formatting w/o helpers • Strict contracts @schneidenbach
69. @schneidenbach
70. What we need to talk about • Use cases • Ease of adoption/use • Team constraints • Performance @schneidenbach
71. REST gRPC GraphQL Requirements machine @schneidenbach
72. REST gRPC GraphQL Requirements machine Integration APIs @schneidenbach
73. Integration APIs • Lots of potential consumers with potentially different platforms… and team skills • Ease of use/time to “make magic happen” is critical @schneidenbach
74. @schneidenbach
75. REST gRPC GraphQL Requirements machine Integration APIs REST @schneidenbach
76. REST gRPC GraphQL Requirements machine Backends for frontends? @schneidenbach
77. Backends for frontends • Aka, data aggregation services for mobile/web • Homogenous data requirements (CRUD?) Low volume of requests? Skip BFF, go straight REST • Lots of different data sources to aggregate? GraphQL good for that use case • Clients need data in a wide variety of shapes? GraphQL perfect • Performance as a first class feature? GraphQL/gRPC @schneidenbach
78. REST gRPC GraphQL Requirements machine Backends for frontends? I think we need more info @schneidenbach
79. REST gRPC GraphQL Requirements machine Microservices? @schneidenbach
80. Microservices • Just starting out? Go with what you know • Huge volume of requests/transactions? Latency/bandwidth critical? gRPC • Humdrum moving of data back and forth with no particular need for high performance? Probably REST… • …or maybe a message queue? • Lots of services needing different shapes of data? Look at GraphQL @schneidenbach
81. REST gRPC GraphQL Requirements machine Microservices? I think we need more info @schneidenbach
82. What we need to talk about • Use cases • Ease of adoption/use • Team constraints • Performance @schneidenbach
83. Ease of adoption • REST wins hands down, but that isn’t the end all be all @schneidenbach
84. What we need to talk about • Use cases • Ease of adoption/use • Performance • Team constraints @schneidenbach
85. Performance • REST as a straight CRUD service is gonna be pretty fast on any framework • GraphQL is designed to be less bytes on return trip. But… • GraphQL, depending on its level of aggregation, is data-first, optimize-second. • gRPC was designed with high performance in mind, which is why it uses HTTP/2 • Buuuuuut… performance is relative. How fast is fast enough? @schneidenbach
86. My recommendation would be: measure, fi nd bottlenecks and fi x the ones that matter. https://samsaffron.com/archive/2011/03/30/How+I+learned+to+stop+worrying+and+write+my+own+ORM @schneidenbach
87. What we need to talk about • Use cases • Ease of adoption/use • Performance • Team constraints @schneidenbach
88. Team constraints • What kinds of devs is your team composed of? • Is the new technology worth the overhead of “learning a new thing”? • This is such a cultural question that it’s hard to answer here, but it’s a consideration to make @schneidenbach
89. No matter what • Versioning/deprecation strategy • Documentation • Uptime guarantees • Quality control/testing • Tooling/SDKs @schneidenbach
90. Rough Timeline SOAP REST GraphQL gRPC ? @schneidenbach
91. “gRPC is dead” “Long live god-knows-what” @schneidenbach
92. @schneidenbach
93. Thank you! schneids.net @schneidenbach