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
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.
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 TH-cam, Netflix, Amazon store... But the most important thing: All it depends of the bussiness needs, not your personal needs!
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.
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
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 😎
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.
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.
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.
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 th-cam.com/video/yLf0rIaRtRc/w-d-xo.html (which is actually referenced in 18:01). But they complement each other nicely.
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.
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.
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...
@@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.
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
thanks for the topic, but ... this is a duplicate of your video posted 3 months ago: th-cam.com/video/LIaekiT6Ehs/w-d-xo.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.
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!!
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
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
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.
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 TH-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.
This was a great presentation, but the kayshing destroyed it. I literally had to take a break to recover. *_*
It's 2023. And this is still a brilliant talk!
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.
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
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 😎
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.
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.
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.
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?
Mature view on using different API approaches.
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 th-cam.com/video/yLf0rIaRtRc/w-d-xo.html (which is actually referenced in 18:01). But they complement each other nicely.
Finally some common sense on this topic ❤️
Totally agree
54:08 I just have to say the name Native Mobile BFF sounds absolutely hilarious
Server push is being removed as of now from chrome,given how less it's being used
what about datomic
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.
This is a good talk. Nicely balanced.
51:21 Sample Scenarios Typical Use Cases of REST/GraghQL/gRPC
I had involuntary ticks everytime he said "Kayshh" when reading "cache" xD
these guys didnt know what will happen next month
Good video.
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.
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.
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
What beautiful slides
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.
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 :)
GraphQL is definitely not the new REST. REST is still the king. Long live REST.
How is GraphQL API? It's a query interface
Can you abort a GraphQL query?
I think so. It's a regular network call so it should be possible to handle cancellations
podías hablar más rápido por favor?
you have different types of kayshing :D ..brainfreeze..wait what...whaaaat
Ksh-able
There are no new ideas.
thanks for the topic, but ... this is a duplicate of your video posted 3 months ago: th-cam.com/video/LIaekiT6Ehs/w-d-xo.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.
is it NDC paying for bots in the comments ? very stange... I expect them on Crypto content, but not talks about API technologies!
00:32 gPRC! :o
I desperately need to blow my nose
omg, it was all fine until he tried to pronounce "caching" - he sounds Irish - why can't he pronounce that word?
Finally some common sense on this topic ❤️
bot!!!
Great talk! A lot of very useful stuff and it is really thoughts provoking.