GraphQL, gRPC or REST? Resolving the API Developer's Dilemma - Rob Crowley
Вставка
- Опубліковано 5 жов 2024
- 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:
ndcconferences...
ndc-london.com/
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
thanks a lot
Thx!!
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.
Sometimes they're old tools in a new toolbox :-)
See LISP as an example! One of the oldest high level languages, and certainly one of the finest!
@@dealloc *shiny new toolbox
@@fullkickproductions7245 LISP has been reskinned in what new language now?
@@milfex-lostex3984 doom emacs :p Hi
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
Lol exactly
Docs aren’t the greatest but for internal apis it’s pretty kickass
...or RPC in general, in fact. It should have never become more complicated than the basic concept of Remote Procedure Calls...
I think you might have learned enough about simic... ;-)
@@mitchthepower Our progress is measured in heartbeats
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 UA-cam, Netflix, Amazon store...
But the most important thing: All it depends of the bussiness needs, not your personal needs!
not real-time. it is event-driven
@@archmad Right.
I always thought "cache" was spoken like "cash". Is it not?
it varies between different accents
Australian: kay-sh
@@BDnevernind Specifikayshing =))
he also pronounces "leverage" as "leaverage". English is flexible
I speak ‘Merican(Texican) and cache and cash are pronounced the same.
This was a great presentation, but the kayshing destroyed it. I literally had to take a break to recover. *_*
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 😎
It's 2023. And this is still a brilliant talk!
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
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
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.
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.
Great talk! A lot of very useful stuff and it is really thoughts provoking.
This is a good talk. Nicely balanced.
@@samanthaferguson6018 are you a bot?
First part of the talk is basically a repetition of everything that's said in the "REST vs. GraphQL: Critical Look" talk by Zdenek Nemec ua-cam.com/video/yLf0rIaRtRc/v-deo.html (which is actually referenced in 18:01). But they complement each other nicely.
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.
Roger Valor by the time cross platform SOAP became popular in my neck of the woods, the modern web was just taking off and REST made sense to web devs as well as backend server guys.
Finally some common sense on this topic ❤️
Totally agree
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
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.
Before even hearing out I can tell the answer
"It depends"
Then why to compare ?
Why compare? Because there is always someone new to the tech who is asking this exact question. Getting a nice summary of the pros and cons of each is very helpful.
Mature view on using different API approaches.
Server push is being removed as of now from chrome,given how less it's being used
what about datomic
Cache is a French word that is pronounced Cash in Englishing (as in "Cash of Gold", rather than "We accept Cash")... maybe it's SQL (S-Q-L or Sequal), difficult to listen to someone who can't pronounce the word, but the summary was OK: GraphQL for query, gRPC for RPC
I've assumed that this recent trend towards cay-she derives from American-English but I might be hurling blame at the easy victim there. ;)
I had to stop listening once he started in that direction but then again, I'm incapable of controlling my aversion to "sequel" so I'm obviously not the most pronunciation-tolerant person in the world.
This is a good talk. Nicely balanced.
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.
The client is a master of the data if someone is writing the GraphQL back end to supply that data, exactly the same as REST, it doesn't come for free. GraphQL is pointless.
If you use ODATA with you REST API, you can also specify properties you want and load all required related entities at once. It event goes further and allows you to sort and filter data - something you cannot do in GraphQL without implementing it yourself...
@@thomasczthomash1859 Sorry you see it that way. You are missing out on a lot.
@@AB-fp8xo Your missing the whole point. I see this quite often, people stuck in the REST paradigm. Oh well. I'll leave you with this. GraphQL wasn't built only for the data and state transfer between client and server. It was built for a better developer experience too, because a component's data/ state (also fetching/ mutating on the server) is local to itself. You can't do that with REST.
@@scottamolinari Just to be sure: honest question, what is REST for you? Many people think that REST is using HTTP verbs, but this is (surprise surprise) a plain HTTP API. If you do not utilize hyperlinks and dont allow clients to discover and traverse your object graph, you might as well be honest and not call the API a REST API. Sadly this is a very common misconception in the industry.
54:08 I just have to say the name Native Mobile BFF sounds absolutely hilarious
since when is "caching" pronounced as "Kay-shing"?
So, and let me get this correct, you failed to Cache in THIS Entire Demo, because its kayshing... dont be such a compiler.
@@youtube.com-handle 👌👍
Appli-kay-shin kay-shing. 😎
Since when is data pronounced as data. 🤪
Not going to lie, this hung me up to for the first 3 times he said it that way. But by the 6th time I got used to it.
these guys didnt know what will happen next month
Good video.
51:21 Sample Scenarios Typical Use Cases of REST/GraghQL/gRPC
What beautiful slides
Can you abort a GraphQL query?
I think so. It's a regular network call so it should be possible to handle cancellations
GraphQL is definitely not the new REST. REST is still the king. Long live REST.
I had involuntary ticks everytime he said "Kayshh" when reading "cache" xD
How is GraphQL API? It's a query interface
Okay but I'm still confused. Is this guy Dutch or Irish?
just use all of them. Hourses for courses
Horses 🐴
@@thomasczthomash1859 o yes, ha ha, what a silly mistake. I will leave it, otherwise readers won't understand your comment :)
Im still in in love with the power of wsdl (not it’s steep learning curve though). Grpc is really nice, super easy IDL. Never was a big fan of REST, because before openAPI it was a nightmare to do larger applications and doing refactorings.
The hate for XML being noisy is 99% irrelevant, just use attributes instead of elements and you get the exact same noisiness like JSON.
And XML supports comments, and you can describe your document’s structure with xsd. And that since it’s beginnings.
Not a big fan of the namespaces for XML though, I just leave them away.
They make sense for really special cases like xaml, html svg, webgl etc
podías hablar más rápido por favor?
Ksh-able
is it NDC paying for bots in the comments ? very stange... I expect them on Crypto content, but not talks about API technologies!
you have different types of kayshing :D ..brainfreeze..wait what...whaaaat
00:32 gPRC! :o
There are no new ideas.
thanks for the topic, but ... this is a duplicate of your video posted 3 months ago: ua-cam.com/video/LIaekiT6Ehs/v-deo.html ...
i got a bit anxious before reminded that i had already seen this video))
nevertheless, keep going) nice videos, have dozens in my lists.
omg, it was all fine until he tried to pronounce "caching" - he sounds Irish - why can't he pronounce that word?
I desperately need to blow my nose
Great talk! A lot of very useful stuff and it is really thoughts provoking.
Finally some common sense on this topic ❤️
bot!!!