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

Slide 1

Slide 1 text

Evaluating the State of Modern APIs Comparing REST, GraphQL, and gRPC Spencer Schneidenbach

Slide 2

Slide 2 text

[email protected]

Slide 3

Slide 3 text

Why? @schneidenbach

Slide 4

Slide 4 text

“X is dead, long live Y” @schneidenbach

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

There’s No Silver Bullet @schneidenbach

Slide 7

Slide 7 text

What we need to talk about • History of APIs • Use cases • Ease of adoption/use • Performance • Team constraints @schneidenbach

Slide 8

Slide 8 text

History Lesson @schneidenbach

Slide 9

Slide 9 text

How did we get here? REST RPC GraphQL @schneidenbach

Slide 10

Slide 10 text

How did we get here? SOAP REST RPC GraphQL @schneidenbach

Slide 11

Slide 11 text

Rough Timeline SOAP REST GraphQL gRPC @schneidenbach

Slide 12

Slide 12 text

First stop SOAP REST GraphQL gRPC @schneidenbach

Slide 13

Slide 13 text

SOAP @schneidenbach

Slide 14

Slide 14 text

SOAP • XML over HTTP (typically) • Contained request/response in “envelope” • Highly structured @schneidenbach

Slide 15

Slide 15 text

@schneidenbach

Slide 16

Slide 16 text

https://www.tutorialspoint.com/wsdl/wsdl_quick_guide.htm @schneidenbach

Slide 17

Slide 17 text

Problems • Incongruent implementations across platforms • Heavy/noisy • Strictly XML based • Very sensitive to envelope/data construction format • nil/null vs empty string @schneidenbach

Slide 18

Slide 18 text

@schneidenbach

Slide 19

Slide 19 text

RPC style @schneidenbach

Slide 20

Slide 20 text

https://stevenontheinternet.tumblr.com/post/62300850469/ninja-baby @schneidenbach

Slide 21

Slide 21 text

@schneidenbach

Slide 22

Slide 22 text

@schneidenbach Archival footage of developers protesting SOAP

Slide 23

Slide 23 text

REST stop SOAP REST GraphQL gRPC @schneidenbach

Slide 24

Slide 24 text

REST APIs to the rescue @schneidenbach

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

What is REST? Representational State Transfer @schneidenbach

Slide 27

Slide 27 text

Uniform Interface Code on Demand (optional) Layered Stateless Cacheable Client-Server The Six Constraints of REST @schneidenbach

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

@schneidenbach

Slide 31

Slide 31 text

“REST kills SOAP” @schneidenbach

Slide 32

Slide 32 text

RPC-ish SOAP Envelopes Inconsistency XML @schneidenbach

Slide 33

Slide 33 text

POST /order Placing an order POST /payment POST /shipping @schneidenbach

Slide 34

Slide 34 text

@schneidenbach

Slide 35

Slide 35 text

@schneidenbach

Slide 36

Slide 36 text

POST /createOrder Placing an order @schneidenbach

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

“REST kills SOAP” …yeah, for the most part @schneidenbach

Slide 40

Slide 40 text

Next on our journey SOAP REST GraphQL gRPC @schneidenbach

Slide 41

Slide 41 text

GraphQL @schneidenbach

Slide 42

Slide 42 text

@schneidenbach

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

What they had • REST-based APIs were WAY too chatty • HTML views pushed up to the client weren’t mobile-optimized @schneidenbach

Slide 45

Slide 45 text

@schneidenbach

Slide 46

Slide 46 text

GraphQL has… • Strong spec • Predictable requests/responses • No over/under-fetching • Strongly typed • Nearly self-documenting • First-class deprecation @schneidenbach

Slide 47

Slide 47 text

How Does REST Get Related Resources? @schneidenbach

Slide 48

Slide 48 text

{ "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

Slide 49

Slide 49 text

@schneidenbach

Slide 50

Slide 50 text

“REST in Peace” “Long live GraphQL” @schneidenbach

Slide 51

Slide 51 text

SOAP vs REST @schneidenbach

Slide 52

Slide 52 text

@schneidenbach

Slide 53

Slide 53 text

@schneidenbach

Slide 54

Slide 54 text

@schneidenbach

Slide 55

Slide 55 text

@schneidenbach

Slide 56

Slide 56 text

@schneidenbach

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

@schneidenbach

Slide 59

Slide 59 text

Lessons Learned @schneidenbach

Slide 60

Slide 60 text

Last… for now SOAP REST GraphQL gRPC @schneidenbach

Slide 61

Slide 61 text

gRPC @schneidenbach

Slide 62

Slide 62 text

@schneidenbach

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

HTTP/2 @schneidenbach

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

.proto file syntax = "proto3"; service Greeter { rpc SayHello (HelloRequest) returns (HelloReply); } message HelloRequest { string name = 1; } message HelloReply { string message = 1; } @schneidenbach

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

@schneidenbach

Slide 70

Slide 70 text

What we need to talk about • Use cases • Ease of adoption/use • Team constraints • Performance @schneidenbach

Slide 71

Slide 71 text

REST gRPC GraphQL Requirements machine @schneidenbach

Slide 72

Slide 72 text

REST gRPC GraphQL Requirements machine Integration APIs @schneidenbach

Slide 73

Slide 73 text

Integration APIs • Lots of potential consumers with potentially different platforms… and team skills • Ease of use/time to “make magic happen” is critical @schneidenbach

Slide 74

Slide 74 text

@schneidenbach

Slide 75

Slide 75 text

REST gRPC GraphQL Requirements machine Integration APIs REST @schneidenbach

Slide 76

Slide 76 text

REST gRPC GraphQL Requirements machine Backends for frontends? @schneidenbach

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

REST gRPC GraphQL Requirements machine Backends for frontends? I think we need more info @schneidenbach

Slide 79

Slide 79 text

REST gRPC GraphQL Requirements machine Microservices? @schneidenbach

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

REST gRPC GraphQL Requirements machine Microservices? I think we need more info @schneidenbach

Slide 82

Slide 82 text

What we need to talk about • Use cases • Ease of adoption/use • Team constraints • Performance @schneidenbach

Slide 83

Slide 83 text

Ease of adoption • REST wins hands down, but that isn’t the end all be all @schneidenbach

Slide 84

Slide 84 text

What we need to talk about • Use cases • Ease of adoption/use • Performance • Team constraints @schneidenbach

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

What we need to talk about • Use cases • Ease of adoption/use • Performance • Team constraints @schneidenbach

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

No matter what • Versioning/deprecation strategy • Documentation • Uptime guarantees • Quality control/testing • Tooling/SDKs @schneidenbach