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

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, then this is the session for you. See you there!

Check out more of our talks, courses, and conferences in the following links:

[MartinThoma]

1:02 Start with Agenda
2:40 About the speaker RobDCrowley
8:18 API Timeline
18:13 REST vs GraphQL
19:29 GraphQL = RDA + RPC
19:55: gRPC = HTTP/2 + Protobuf
21:48: REST is a state-machine over HTTP
27:48 GraphQL breaks caching - client-side chaching, server-side caching
30:58 Authentication
33:09 Caching summary
33:50 "REST APIs are inefficient"
35:34 Over/Underfetching
40:52 Performance
41:52: "GraphQL elimits the need for API versioning"
48:00 Contract First

[drmangrum]

The problem is too many developers latch on to the "great new thing" thinking it's better to what came before it just because it's new. Just because a technology is new doesn't mean the old technologies are irrelevant. New technologies are just new tools in the toolbox. Use what's best for your situation.

[rauru]

Me coming here: ok I need to learn more abour GraphQL
Me coming out: ok I need to learn more HTTP2 and find out what the heck is gRPC

[Euler-hn]

From my experience:

RPC is good when you need execute actions or events -> eg. An authoritative game server; A "near real-time" system.

Use REST when you need expose data or datasets -> eg. Data from a "products" table for a frontend ecommerce; Statistical data for analysis like Covid19 datasets...

GraphQL is good when you need specific fields from different datasets/tables, conceptually very similar to "views" in databases -> eg. Personalized recommendation systems like those on Youtube, Netflix, Amazon store...

But the most important thing: All it depends of the bussiness needs, not your personal needs!

[chandragie]

It's 2023. And this is still a brilliant talk!

[seff]

love seeing this nuanced approach. twitter takes constantly make me feel like making any decision is the wrong decision because there's some expert out there flinging witty puns around shitting on my tech stack.

[KamilSkalski]

You can also use grpc-js, which is purely-JS grpc client (think are also wrapping up server implementation, for use in node I guess), so browser can easily become one of many polyglot consumers of grpc based API

[scottamolinari]

I always thought "cache" was spoken like "cash". Is it not?

[onur]

This presentation was amazing! I am going to start with my bachelor thesis soon about graphql and rest. Are there any good book recommendations out there? Let me know 😎

[keja]

This was a great presentation, but the kayshing destroyed it. I literally had to take a break to recover. *_*

[RogerValor]

SOAP failed because it was trying to create self building protocols serving project management instead of software development. All comparisons to REST (and Xml-Rpc/Json-Rpc) being embraced again is quite hard to compare to it. So I would not listen to such hyped articles anyway. Whenever people want to create programs without understanding how to code try to create protocols, it will just fail. So this talk greatly shows, how each more simple API strategy has it's strengths and weaknesses.

[AlexeyLopatin-mr]

Mature view on using different API approaches.

[thorick]

Totally agree with the sentiment. Each architecture addresses a certain type of problem. You choose the one that best fits your circumstance. Good luck with message type polymorphism if you try to change your SOAP service to REST using JSON as the message format, for example. For the vast majority of consumer facing web/mobile apps this kind of capability is completely irrelevant so SOAP is complicated to use and a complete waste of computing resources. Like owning a McLaren if all you want is a car to get around town to go grocery shopping. You're far better off with that Toyota Yaris.

[MrNorthCat]

Great talk! A lot of very useful stuff and it is really thoughts provoking.

[stevepascoe]

Finally some common sense on this topic ❤️

[Christobanistan]

Note that Protobuf can be replaced in gRPC. If both ends were .Net, for example, you could not serialize at all but blit out the in-memory binary representation, which is much faster.

[scottamolinari]

One other thing. It is always missed, because these discussions are targeted at GraphQL as an API, but GraphQL clients also do one other thing amazingly well, which helps developer efficiency. They allow for the components (as in SFCs in React/ Vue, etc.) to be the masters of their own data. You can't do that easily with a REST client.

[rafaelfreitas]

54:08 I just have to say the name Native Mobile BFF sounds absolutely hilarious

[parapadirapa]

Anyone has a couple of books on this subject, comparing the pros and cons of the different API styles and mentioning practical applications of each style? Thanks in advance

[MaheshKumar-lqxm]

Before even hearing out I can tell the answer
"It depends"

Then why to compare ?