This is a wonderful video. For months I’ve been using a GraphQL API but I never took a step back to determine WHY I was using it and the advantages of using it over REST API
Very interesting video! A small remark: the sound attached in the explanations (I don't have a term) is a little too loud in tune with the voice. Otherwise... I hope the result is worth the effort :)
@Kodaps Really? Let me count mistakes: 1. REST and RESTful API and REST web APIs are different things 2. "where each row represents an object" - why? who decided this? you? Somehow you went from API approach to ORM? And the only way to do ORM is object-row mapping in your context. That is not actually the case. 3. And you say it loudly REPRESENTATIONAL state transfer. You transfer REPRESENTATION, not the whole state, because, where there are relations, state also includes relations. It is just logic. 4. REST purpose is not to communicate items, its purpose is to communicate representation of the state of an object. Why you need to add some flavor to interpretation? 5. Why I should care about relationships if I sometimes care just about property in the state of the object? You present it like it always important to work with relationships. IMHO in mutation scenarios, relationships are less important than just mutating the state of a known object (which ID is already known). I do not need to navigate through relations to update state at all! The thing that you present as advantage are virtual and it is not always important and can be easily covered by REST API and sufficient API management 6. "We define response shape on a client". This was solved years ago with OData and OData is a standard for REST. Yes, you can define the shape of the response. 7. Strong typing is viable as much as tooling supports it. For REST APIs we have strong tooling, for GraphQL it is missing. So overall I do not see any significant advantage of GraphQL. In some teams differences may play positive role, in others they will make no difference, in others they may introduce unnecessary bottlenecks. I do not see GraphQL as viable alternative to simple RESTful API with API management.
@dxhelios7002. Restful API's is to REST as communication is to communicate. When he made that point, he made it generalizing To API that uses REST protocols in which REST in it's own falls into that category. But I think you're right.
Just trying to really understand GraphQL's benefits. Can't you use REST to do exactly what GraphQL does? Doesn't that just depend on how you've built the API? I can build a /user endpoint that takes the required columns as a parameters, and returns only the needed columns and relationships. Not sure what GraphQL does that REST can't aside extra documentation. Could someone explain?
In your example, the server (statically) decides which fields to send via the rest API, based on how it is build. In GraphQL the client defines the fields it needs and requests them, which can result in smaller network payloads.
@@KodapsAcademy But the client can decide what fields it needs. All I have to do is make the endpoint take, say, a "fields" parameter, and put that in whatever SELECT functionality the backend is using to fetch the data. Then the server will only return the needed data. The server doesn't have to return everything.
Merci pour tes vidéos de qualité ! Je pense qu'il y a un autre inconvenient à GraphQL : on est, sauf erreur de ma part, obligé (ou presque) d'utiliser une librairie en backend et aussi en frontend comme par exemple Apollo server et Apollo Client. Cela rend moins accessible l'API et rend la maintenance plus compliqué sur le long run (mise à jour d'Apollo par exemple).
ET merci pour le compliment :) C'est fortement recommandé côté serveur de passer par une lib, effectivement. Côté client ce n'est pas forcément nécessaire mais ça simplifie la vie :)
@@KodapsAcademy Top ! Je pense bientot faire une API GraphQl pour me permettre de gérer la composition d'un portefeuille d'actifs (actions, cryptos, immobilier, etc.) donc d'après ta réponse je devrais pouvoir consommer l'API en vanilla JS sans trop de difficultés par exemple dans un script macro si je veux utiliser le tableur Google Calc. Du coup, si c'est le cas, je ne trouve plus trop d'interet à la classique API REST.
J'ai déjà fait des appels à une API GraphQL avec du Lua, donc avec du JS Vanilla ça peut le faire sans problème, il suffit de faire un POST sur le point d'entrée qui va bien (genre /graphql ) en envoyant en body de ta requête (HTTP) la requête GraphQL que tu veux lancer
Feel free to add some substance to your contribution, e.g. what makes you say so, how do you propose to cache GraphQL requests other than via Apollo, etc. :)
This is a wonderful video. For months I’ve been using a GraphQL API but I never took a step back to determine WHY I was using it and the advantages of using it over REST API
Glad to have been of service :)
Definitely a useful video ! Happy I watched this, very clear and concise with no fluf
By far, the best video about GraphQL! Thanks a ton!!
Very good clean, quick video.. thanks for the refresh
Glad to be of service :)
I'm Brazilian and I thought the video was fantastic, congratulations.
I’m glad you liked it, thanks for the kind words :)
What an excellent explanation
Your channel deserves more views.
Thanks :)
Thanks
Thank you !
This is channel is underrated
Nice and compact comparison.
Thanks :)
Only 2.9K views? Great video, thanks!
Love the details info you provided!!! Keep up with the great work💪🏻
Thanks for the kind words, Ann!
Amazing explanation!
Thanks :)
Thank you very much for the video ..
Thanks ! very clear and informative
Glad you liked it :)
Great video!
Thanks :)
Very interesting video!
A small remark: the sound attached in the explanations (I don't have a term) is a little too loud in tune with the voice.
Otherwise... I hope the result is worth the effort :)
Great lesson from Mr. Robot himself hehehe
Thanks!
@Kodaps Really? Let me count mistakes:
1. REST and RESTful API and REST web APIs are different things
2. "where each row represents an object" - why? who decided this? you? Somehow you went from API approach to ORM? And the only way to do ORM is object-row mapping in your context. That is not actually the case.
3. And you say it loudly REPRESENTATIONAL state transfer. You transfer REPRESENTATION, not the whole state, because, where there are relations, state also includes relations. It is just logic.
4. REST purpose is not to communicate items, its purpose is to communicate representation of the state of an object. Why you need to add some flavor to interpretation?
5. Why I should care about relationships if I sometimes care just about property in the state of the object? You present it like it always important to work with relationships. IMHO in mutation scenarios, relationships are less important than just mutating the state of a known object (which ID is already known). I do not need to navigate through relations to update state at all! The thing that you present as advantage are virtual and it is not always important and can be easily covered by REST API and sufficient API management
6. "We define response shape on a client". This was solved years ago with OData and OData is a standard for REST. Yes, you can define the shape of the response.
7. Strong typing is viable as much as tooling supports it. For REST APIs we have strong tooling, for GraphQL it is missing.
So overall I do not see any significant advantage of GraphQL. In some teams differences may play positive role, in others they will make no difference, in others they may introduce unnecessary bottlenecks. I do not see GraphQL as viable alternative to simple RESTful API with API management.
I didn't realise GraphQL and REST could evoke such an emotional response :D
@dxhelios7002. Restful API's is to REST as communication is to communicate. When he made that point, he made it generalizing To API that uses REST protocols in which REST in it's own falls into that category. But I think you're right.
hey dude just some constructive criticism - i think the sound effect volume is too high in the mix. it's distracting. thanks for the vid!
Thanks for the feedback, it's always welcome, and I'm sorry that the video was not quite up to par :)
Just trying to really understand GraphQL's benefits. Can't you use REST to do exactly what GraphQL does? Doesn't that just depend on how you've built the API?
I can build a /user endpoint that takes the required columns as a parameters, and returns only the needed columns and relationships.
Not sure what GraphQL does that REST can't aside extra documentation. Could someone explain?
In your example, the server (statically) decides which fields to send via the rest API, based on how it is build. In GraphQL the client defines the fields it needs and requests them, which can result in smaller network payloads.
@@KodapsAcademy But the client can decide what fields it needs. All I have to do is make the endpoint take, say, a "fields" parameter, and put that in whatever SELECT functionality the backend is using to fetch the data. Then the server will only return the needed data.
The server doesn't have to return everything.
I like your teaching... You just got a subscriber
Glad you liked it and that I was able to be helpful :)
Merci pour tes vidéos de qualité ! Je pense qu'il y a un autre inconvenient à GraphQL : on est, sauf erreur de ma part, obligé (ou presque) d'utiliser une librairie en backend et aussi en frontend comme par exemple Apollo server et Apollo Client. Cela rend moins accessible l'API et rend la maintenance plus compliqué sur le long run (mise à jour d'Apollo par exemple).
ET merci pour le compliment :) C'est fortement recommandé côté serveur de passer par une lib, effectivement. Côté client ce n'est pas forcément nécessaire mais ça simplifie la vie :)
@@KodapsAcademy Top ! Je pense bientot faire une API GraphQl pour me permettre de gérer la composition d'un portefeuille d'actifs (actions, cryptos, immobilier, etc.) donc d'après ta réponse je devrais pouvoir consommer l'API en vanilla JS sans trop de difficultés par exemple dans un script macro si je veux utiliser le tableur Google Calc. Du coup, si c'est le cas, je ne trouve plus trop d'interet à la classique API REST.
J'ai déjà fait des appels à une API GraphQL avec du Lua, donc avec du JS Vanilla ça peut le faire sans problème, il suffit de faire un POST sur le point d'entrée qui va bien (genre /graphql ) en envoyant en body de ta requête (HTTP) la requête GraphQL que tu veux lancer
@@lydstylsans soucis je fais du curl / postman
great video!
Thanks:)
Lovely, thank you
Glad you liked it :)
Very well done - subbed ;o,
Thanks, welcome aboard :)
@@KodapsAcademy
Merci 😁
bien vu ;)
OpenApi is the defacto standard for rest api documentation
I know, I’ve used it as swagger. But documentation is built into the protocol and is discoverable in GQL, which makes for better tooling.
I somehow like your energy
Thanks :)
All right, here's the signal for UA-cam's algorithm.
Thanks :)
nice
graphql + apollo = wasted time
Feel free to add some substance to your contribution, e.g. what makes you say so, how do you propose to cache GraphQL requests other than via Apollo, etc. :)
Yes @laas29 why did you say that. Please elaborate more. We need your response.