VERY few people excel at presenting complex topics in a way that is interesting, informative, and easily digestible. After watching this video and the OAuth 2.0 and OpenID Connect video that led me here, it's clear that Nate Barbettini is one of those people. Please keep doing what you're doing!
Great talk. And btw, regarding the acronym - you could indeed call it "the 5 C's", but slightly modified into "D V C's". D = The V = Roman letter for 5 C = ... well, the C's
It's very funny because peaple praise GraphQL because of the schema stuff but that we praise NoSQL because is schemaless over the schema in Databases. I can't understand Humans.
The "function explosion" is not a problem, I believe, with any careful planning. RPC is public by definition, so proper attention should be devoted to segmenting the api into groups. Granted, not all that simple to foresee everything, but we sure can go a long way to avoid the so-called "explosion". Also, why in the hell would to publish an API synonymous to internal structure? Have an abstraction layer for that!
hey hi I made an api with express. I can read the images on the same port with api.map... but I can access the links of my api images from a different server, but I cannot view the images.
I would say thay although caching is not as easy, it's better in GraphQL with ApolloEngine and ApolloClient due to the possibility of using id as a unique identifier for a server object, and per field timing and caching.
@@nbarbettini Their use of the id field and your ability to override its use is not something that they talk much about, but they should because, as you said, it gets really confusing if you don't know what it's doing.
gRPC 'solves' many of the of the issues you describe with RPC API's. If used with protocol buffers, you get a single endpoint instead of X endpoints because the generated code abstracts this from the developer. The most important asset of any API is the contract and protocol buffers allow you to create backwards compatible contacts, so no need for 'v2' function names. Maybe also don't compare RPC with REST or GraphQL it's like comparing apples with pears. Because SOAP is RPC, gRPC is RPC and Corba as well, but they are very different. So a more fair comparison would have been to compare gRPC with the other two. Other than that, great talk, thank you!
Seemed like this was put together from an initial idea to make them seem equal. If you listen closely, the content within shows why GraphQL is actually far superior. The only thing against it, really, is that it's more complicated and not everyone is familiar with it. I don't think this characteristic should hold equal weight when the point of the presentation is to compare technologies.
My goal was not to show that they are equal, but they are different tools for different jobs. I think GraphQL absolutely shines for first-party APIs and some third-party ones too (now that it is becoming more mainstream). I wouldn't use it for communication between microservices.
@@nbarbettini thanks Nate, for clearing my doubt. I have always believed that there is place for RPC, and REST is not suitable for micrservices communication, especially when it comes to asyn communication or messaging, that is where RPC shines.
VERY few people excel at presenting complex topics in a way that is interesting, informative, and easily digestible. After watching this video and the OAuth 2.0 and OpenID Connect video that led me here, it's clear that Nate Barbettini is one of those people. Please keep doing what you're doing!
I loved your oAuth in plain english talk. Brought me here. Another awesome win. Keep doing these.
@@jarnovirta6997 For me as well
Same here :-D He is a great speaker and learnt a lot by his talk. Thanks :)
I followed the same path and completely agree.
@@gauravmalhotra944 Same here
Great talk. And btw, regarding the acronym - you could indeed call it "the 5 C's", but slightly modified into "D V C's".
D = The
V = Roman letter for 5
C = ... well, the C's
It's very funny because peaple praise GraphQL because of the schema stuff but that we praise NoSQL because is schemaless over the schema in Databases. I can't understand Humans.
All these days I assumed I was doing REST API.
After watching this....
I was actually doing RPC in the name of REST API
😅😅🤣🤣🤣
I think we've all done that! :)
SAME haha
Wow, me too not an exception. First I watched ‘OAuth in plain English’. That interest brought me here. Another wonderful presentation. Kudos.
probably the most mature talk on this topic
Lol I feel attacked. Had no idea what RPC was, seems like have been using it all the time. An eye opener
man, that was such an amazing talk! thnx a lot for sheding some light (:
same here i also came after watching oAuth in plain English.Keep it up bro
Explained nicely which API design patterns should we use.
What an Amazing talk. I learned a ton of stuff - thank you very much !!!
The "function explosion" is not a problem, I believe, with any careful planning. RPC is public by definition, so proper attention should be devoted to segmenting the api into groups. Granted, not all that simple to foresee everything, but we sure can go a long way to avoid the so-called "explosion". Also, why in the hell would to publish an API synonymous to internal structure? Have an abstraction layer for that!
All I can say is GraphQL is the only positive contribution done to humanity by Facebook. LOL ! Great explanation tho.
hey hi
I made an api with express. I can read the images on the same port with api.map... but I can access the links of my api images from a different server, but I cannot view the images.
I would say thay although caching is not as easy, it's better in GraphQL with ApolloEngine and ApolloClient due to the possibility of using id as a unique identifier for a server object, and per field timing and caching.
I've had a pretty different experience with ApolloClient caching actually. More bugs due to ApolloClient doing weird caching stuff than anything else.
@@nbarbettini Their use of the id field and your ability to override its use is not something that they talk much about, but they should because, as you said, it gets really confusing if you don't know what it's doing.
Wow this is exactly what I am looking for! It clears my confusion! Thanks!
Interesting and useful ways to think about APIs
Thanks for the confirmation
gRPC 'solves' many of the of the issues you describe with RPC API's. If used with protocol buffers, you get a single endpoint instead of X endpoints because the generated code abstracts this from the developer. The most important asset of any API is the contract and protocol buffers allow you to create backwards compatible contacts, so no need for 'v2' function names.
Maybe also don't compare RPC with REST or GraphQL it's like comparing apples with pears. Because SOAP is RPC, gRPC is RPC and Corba as well, but they are very different. So a more fair comparison would have been to compare gRPC with the other two. Other than that, great talk, thank you!
Very informative and explanatory, thank you!
Great presentation! easy to understand. well done.
came from that great OAuth talk ...
Thank you! It's well organized presentation, I learned a lot.
Great content, thanks for uploading.
Wow. You rock, man. Amazing explanation
Great presentation Nate, Thanks :)
Great explanations!
Seemed like this was put together from an initial idea to make them seem equal. If you listen closely, the content within shows why GraphQL is actually far superior. The only thing against it, really, is that it's more complicated and not everyone is familiar with it. I don't think this characteristic should hold equal weight when the point of the presentation is to compare technologies.
My goal was not to show that they are equal, but they are different tools for different jobs. I think GraphQL absolutely shines for first-party APIs and some third-party ones too (now that it is becoming more mainstream). I wouldn't use it for communication between microservices.
@@nbarbettini thanks Nate, for clearing my doubt. I have always believed that there is place for RPC, and REST is not suitable for micrservices communication, especially when it comes to asyn communication or messaging, that is where RPC shines.
@@ngodinhloc3065 Indeed, Thrift and gRPC are very common for those scenarios.
Great talk! Thank you!
Thanks. Great presentation.
Thanks. Great presentation.
Great presentation !
Well done. Really nice explanation.
great video quality!
This guy is genius!
great so none of the APIs i have seen up to this point has been true RESTful APIs. Good to know.
Excellent
great talk
What does resource mean in the REST part?
It means some _THING_ that you want to get. For instance: contacts.google.com holds contact resources. IMDB holds movie resources. I hope that helps.
Every object/noun is a resource
👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻... Bravo!
Nate Barbettini - GOD _/\_
i dont to see the screen..
smart dude
That shirt is cool.
REST is the best.
http/3 makes graphql obsolete