What Is GraphQL? REST vs. GraphQL 

Probably the most easy to understand video I've seen about differences between REST and GraphQL. Thank you!

The graphics and animations are simply next level.

GraphQL seems like an ambitious & interesting idea, as well as a horrendous footgun. Thanks for the wonderful explanation as always!

It is most quick , constructive and comprehensive essence of knowledge without any extra BS payload like memes and distracting videos. Thank you, sir.

Great work as always ! I'm really impressed by the quality of your slides

This is a fantastic video! Thanks for the comparisons, it really helped me understand what was going on. I was having trouble understanding the concepts seeing as not many people explain it this simply and I didn't have time to dig into the documentation... Thanks a lot. I'll be sharing this video for anybody else who needs a quick, no fuss intro to graphql.

the work on animation is incredible very inspiring

Interesting. I implemented some similar features in the H2O-3 REST API framework back in 2015. You can white- or black-list fields, and specify which if any child objects to return in the payload, so you didn't have to make many REST requests and assemble an object graph yourself inside the client. The query language was just REST with a couple optional parameters on top of it. It doesn't require a schema (it's schema-on read, with automatically-generated rich metadata for the schemas), or a special query language. You just specify the field paths for any child or grandchild classes you want returned. The API is defined in a very lightweight way, simply by creating a parameterized class for each class in the API. No boilerplate, no IDL.

2:11 to 2:21 a superb concise explanation of the difference.

Added this to our standard training tools. Brilliant job, looking forward to your future videos! ^^

One of the best videos to grasp the idea of GraphQl.

Nicely explained! In ten years down the line, GraphQL will be identified as an anti-pattern in the industry. Though it may seem very easy and attractive initially, it would become more complex once the schemas become big. REST is simple and easy to implement. The only caveat with REST is multiple api calls to backend. The better and a traditional approach should be by introducing orchestration services for any frontend that requires more complex data models from the back end.

very clear explanation! instantly subscribed!

That was most well and detailed explanation I've seen Liked and subscribed

Complete brief video, thank you!

Great piece! Would love to have a piece elaborate on the caching behaviors of HTTP GET leveraged by browser, CDN and servers mentioned in the video.

amazing animations, a very clear explanation, thank you!

I like this channel. Valuable technical system design series.

Beautiful animations and explanation. Thanks.

such a great video - love the channel!

thank you for this! extremally valuable resources, please keeping making this content

Thanks for the explanation! That was very helpful!

The way you explained is TOP NOTCH

Good explanations ... good animations !!

Fantastic video, clear and short

Terrific overview and I *really* appreciate the caveats!

Excellent explanation, thanks! subscribed 👍

Really clarify my understanding of their usage

To the point and precise explanation. Nothing bla bla !! Very nice!

Wow, very concise. Thanks for the video.

Dude, you are the best. Thanks! Keep it up!

Great Job buddy. Impressed

Thank you for this great explanation.

Thank you for the video! I learned something new

Love your videos! Thank you so much!! ❤

Nice and stylish tutorial, thanks

Thank you very much for the explanation.

Thanks for the quality content.

Amazing video, animatin and presentation!

thanks for content! suggestion: Odata, or maybe a video about "Rest vs. Odata vs. GraphQL"

great breakdown, thanks

It always seemed to me that graphQL is only worth it beyond a certain level of complexity and when you're dealing with an extremely varied array of clients each needing different fields, different data, different implementations. This gives the clients maximum flexibility and you move a lot of the complexity to the client side. If you don't want to implement hundreds of endpoints and API's you just create the graphql middleware, schemas and you're good to go. But security is a big risk, you need to make sure sensible data is not being returned in any way, not to mention you introduce a lot more possibilities for bugs.

Great explanation!

great video. easy to understand

Finally this video has come 🥳🥳🥳, was waiting for so long. Thank you ❤️❤️❤️

In my company we use GraphQL as primary API and it is not good. We are planning to move everything to REST api. Knowledge gap is the biggest trade off for us. New talent is having hard time wrapping their head around GraphQL queries. REST is pretty simple and easy to understand thus less development time for all the developers.

What a beautiful and informative video.

Amazing, thank you for sharing it!

your videos are pretty good!! thx

Thank you! Great video.

Fantastic Motion animation btw

GraphQL was designed by Facebook to solve over fetching problems aggregating data lakes containing overlapping/duplicate data sometimes from uncontrolled 3rd parties for a global service that processes millions of write and read queries per hour 24/7. It can be useful for taming bloated data lakes or getting more out of old systems. If you are building a new system ground up you probably won't need it unless your data models are very complex with giant records, but probably a just bad design. I have seen startups fail because they wasted time and money on GQL when they didn't really need it or the complexity it adds made getting the service to work well difficult or fragile. Don't engineer like FB and Google until you are that big and make a system that gets the objective work done well and code it so it can grow and modularize later if needed.

Great video!

Love your videos!

Your videos are a god send

Thank you for the great video. What tool / software are you using for the video animation?

Learned a lot here!

Nice explain! thanks

Great video! But sincerely I would continue to use JSONAPI instead of GraphQL. JSONAPI is super nice, supported by a lot of frameworks and it's build around the specific fields to be fetched just when they are needed... not to mention the pre-build filters that you can specific on your resources and simplify the way you filter for particular records and collections

Great explanation! Clear and easy. Thanks a lot!

Nice one, thanks!

Thx! So helpful!!

Nice explanation

Nice comparison!

Awesome video...receiving all resources from one request seems great for GraphQL. However, not sure about its security capabilities and the fact caching is a headache. As a lead Engineer, I'll recommend GraphQL for our internal tools still not convinced about using it in our production apps.

Rest: simple to implement and use, with inefficiency in specific occasions because of multiple API calls required GraphQL: flexible and efficient to use, but complex to implement and use and often relies on extra tools

Nice video 👏👏. Which tool are you using for making such great videos?

great video!

Very nice, thanks!

Thanks Great Explentation

which software you use to crate this kind of animation video? please tell me. and thank you so much for shareing this wonderful explanation.

Thanks for your sharing

cool explaination

Super explanation

Great Video.

Like, your video content is very professional, what software did you use to make the video? thanks

Thank you for great video, tRPC is now gaining growth and replace graphql

great explanation, as usual

great! how do you prepare your presentations? so beautiful!

To be fair, you can also accidentally do a full scan of a table in SQL too. Maybe it's just a bit less likely because developers who build the queries are more aware of what's in it than frontend developers

There are two arguments I have against GraphQL - 1. Why can't you write efficient REST APIs so they offer precise data in one call? 2. Assuming GraphQL Apollo React client talks to Apollo backend server, I assume the Apollo backend server is doing more querying before returning precise data to the client. There is performance overhead on the server-side, GraphQL is just offering ease, not performance optimization. If my above two arguments are true, GraphQL will be replaced someday by an easy-to-use REST API abstraction on the server-side, this abstraction will offer the GraphQL benefits in REST.

this was best ! because everyone was speaking regarding graphql directly and i was thinking its a sql languange XD

GraphQL is a marketing tool. It requires way more server work to be done for really rare usecase. Usually it's better to use json rpc with predefined request differs.

Frankly I didn't understand the part with the table scan that could bring the DB down. Someone care to elaborate please?

I liked the nod to the SpaceX Dragon capsule in the GraphQL schema 😏

Great video, but I don’t see the advantage of GraphQL over JSONAPI. Also, there are several open source implementationsfor JSONAPI. I would only maybe use GraphQL to describe relations not predicted by a JSONAPI REST API, if that much.

Thanks

I immediately went to your channel to watch more videos, but the count is very low. But thats the catch, quantity > quality.

good job bro :D

Which program do you use for animations?

Nice video

In previous video I just watched they told that n+1 problem is a problem of GraphQL approach, in this video they told that n+1 problem is a problem of REST approach 🤯

I would presonally just pass in an additional parameter to grab smaller or fuller version of the request, where some data could be nullable.. but if you really need that kind of flexibility then fine 😅 but is slower so...

GraphQL is great, but I'm a little worried about the delay when I put NodeJS as BFF in between. How do you all solution?

Hey alex, good Video, how ever i have two questions 1. Is Odata and graphql sort of the same I mean you can fetch by the query or am I right in saying that the schema of odata is different and way different than Odata ?? 2. Do we need a specific type of database like a nosql or graph db for querying such information ??

how is this in principle different from soap and exchangign wsdl schemas?

any one understood at 4:21 . What he meant? How does the entire table span occurs?

Where are they better to use in terms of safety and cost?

Is it same persistent tables for GraphQL and REST? If so, can GraphQL guarantee atomic operations across tables?

u put ; after $petType, but : after $name. is it correct?