bro I just love these explainer videos. You have got a unique niche of explaining everyday developer stuff with a whiteboard and in a simple manner. Keep them coming.
IMO there is no best kind of API ... they both solve problems in their own ways. What you choose depends on what you are trying to achieve in what circumstance. The video covers everything up nicely. Good job dude!!
If you use nestjs then it can autogenerate the schema for you based on code by providing some decorators for your code. Alternatively if you have a schema already you can generate types for your backend from schema file. Additionally you can generate boilerplate for grapgql object with the nest cli. Im new to graphql but enjoying it with nestjs. I think nestjs, typeorm and graphql is really powerful combo ❤️
I love both GraphQL and REST API's on the back-end. The tricky part to me is on the front-end. Apollo Client with React is complex setting up the Cache. I heard that it's easier with React-Query. Whereas I can do simple API calls: POST, GET, UPDATE, and DELETE.
This was a great video on each individual approach, but unfortunately did not live up to the title in actually comparing the two approaches in terms of use-case apart from detailing that a GraphQL req has the ability to control the fields returned. Still though, I really enjoy these videos! Keep it up!
One of the best explanations on TH-cam! I still wonder one thing though... The GQL server returns a single response with exactly the data you need which makes it fast. However, wouldn't the GQL server still fetch the same amount of data from the DB? For example if you need a couple of fields from large userData collection that's tied to another large user collection, wouldn't GQL query the entirety of both of those collections from the DB? I get that not sending those over HTTP is a benefit but is it that much faster or am I missing something? On top of that, you have the data resolution that you have to do in the GQL server before sending it to the client which adds another layer of processing.
> However, wouldn't the GQL server still fetch the same amount of data You got it right. When you have gql type, let's say User { id: ID, fistName: String, lastName: String, dep: Department }, you should fetch all of them from the DB. However some libraries have a workaround - complex type support. This means you can make an additional resolver for department field. So that you can get the department from db only when this field (dep) was queried on the client.
REST would be faster because GraphQL sits behind a REST endpoint and has to perform all the validation and message parsing, whereas technically in REST you can even receive the request data as a stream
Let me give you a honest advise, your content is good, topics are good and thumbnails are great, but the moment we see a whiteboard, the video becomes uninteresting. This is the reason why your views are low. I am sorry but it is true. ❤
Learn Full Stack Development: cdm.sh/fullstack
bro I just love these explainer videos. You have got a unique niche of explaining everyday developer stuff with a whiteboard and in a simple manner. Keep them coming.
This guy is the best! I came for WebSockets vs HTTP, and just went down a rabbithole.
IMO there is no best kind of API ... they both solve problems in their own ways. What you choose depends on what you are trying to achieve in what circumstance. The video covers everything up nicely. Good job dude!!
Graphql for connected data,REST for the rest.
Even if know topics, I always learn new things from your videos. Thankyou keep posting.
I am really liking the kind of topics you are choosing.
The explanation is great but kindly manage that ring light.
Now that you mention it, I can't focus at all.
This one is really amazing now I will definitely try graphQL. Thanks for the wonderful explanation bro 😎🔥🔥🎉🎉
Very Informative
great job, bro, keep on
The best explanation I've ever seen on GraphQL and REST API. Keep these videos coming.
Hey Bro
Good and Informative Content
Just Remove Background Music
If you use nestjs then it can autogenerate the schema for you based on code by providing some decorators for your code. Alternatively if you have a schema already you can generate types for your backend from schema file. Additionally you can generate boilerplate for grapgql object with the nest cli. Im new to graphql but enjoying it with nestjs. I think nestjs, typeorm and graphql is really powerful combo ❤️
No bullshit, this guy is the best. If you want coding explained well, get an indian. Also applies to pretty much any subject.
Mehul can you please make a video on how you learn things or even a twitter thread works
When you gonna release Graphql whole series on codedamn?
Great video 🔥 helped me alot
In REST also, we can have select params in query parameter as a comma-separated string, right?
in graphQL it pretty easy and graphQL creates api documentation automatically
@@majidshah48 rest also creats
Amazing Video ❤️
I like your attitude, subbed
Great video! 🔥
addicted to your video's
I love both GraphQL and REST API's on the back-end. The tricky part to me is on the front-end. Apollo Client with React is complex setting up the Cache. I heard that it's easier with React-Query. Whereas I can do simple API calls: POST, GET, UPDATE, and DELETE.
Great Content 👍🏻
You deserve a subscribe and like.
Nice explanation!
GraphQL is way to go for me though 🔥🔥
Videos are lit BtW
Nice! thanks.
I love REST more
Thank you
None!!
Which outro music
Love these random topics you keep making videos on. I keep learning different things. Thanks to youtube's algo too.
This was a great video on each individual approach, but unfortunately did not live up to the title in actually comparing the two approaches in terms of use-case apart from detailing that a GraphQL req has the ability to control the fields returned. Still though, I really enjoy these videos! Keep it up!
Thanks for such awesome videos, always waiting for your new videos, will be glad to get t-shirt giveaway
quality content.
It's always good staff here let's code the jounery
6:51 The reason I love GraphQL. Thanks, Mehul bhaiya for the explanation.
One of the best explanations on TH-cam!
I still wonder one thing though... The GQL server returns a single response with exactly the data you need which makes it fast. However, wouldn't the GQL server still fetch the same amount of data from the DB? For example if you need a couple of fields from large userData collection that's tied to another large user collection, wouldn't GQL query the entirety of both of those collections from the DB? I get that not sending those over HTTP is a benefit but is it that much faster or am I missing something? On top of that, you have the data resolution that you have to do in the GQL server before sending it to the client which adds another layer of processing.
> However, wouldn't the GQL server still fetch the same amount of data
You got it right. When you have gql type, let's say User { id: ID, fistName: String, lastName: String, dep: Department }, you should fetch all of them from the DB.
However some libraries have a workaround - complex type support. This means you can make an additional resolver for department field. So that you can get the department from db only when this field (dep) was queried on the client.
White HALO in the center in every recent video..
Pls sir adjust lighting it is so distracting 🥺🙏
Great explain
COMMENTED FOR T SHIRT GIVEAWAY!! :)
ty
Great content 🔥
Great explanation :-)
Great wideo
🧐🧐🧐
What about in terms of performance? Which one is better?
REST would be faster because GraphQL sits behind a REST endpoint and has to perform all the validation and message parsing, whereas technically in REST you can even receive the request data as a stream
amazing🔥💀
If you can please record in hindi also.
Keep these coming!
Let me give you a honest advise, your content is good, topics are good and thumbnails are great, but the moment we see a whiteboard, the video becomes uninteresting. This is the reason why your views are low. I am sorry but it is true. ❤
To be honest, I am here for the GIVEAWAY 🤦♂️
May the like be on this comment.