REST vs GraphQL - What's the best kind of API?

[@acarvey]

I'm taking your React course on Udemy right now, it's so great seeing you on so many platforms teaching and passing on your knowledge! I always find your tutorials helpful, easy to follow, and you convey concepts very succinctly.

[@academind]

Awesome, thank you!

[@jmrah]

I appreciated how unbiased this comparison was. I think one major thing GraphQL has going for it is that is a standardized spec. There's a lot of variation in the quality of REST APIs.

[@Devillman90]

I had a job interview before 2 weeks ago. And I was asked if i know what a GraphQL is, well i didn't knew cause so far i've used only Rest APIs and never had to dive in into the GraphQL, but now thanks to this 17 minutes video, I can understand the concepts behind the GraphQL and for what is used for. And I would like to thank you! All of your videos are very well structured and explained in a way that everyone can understand. I own almost all of your courses on Udemy and I learn a lot from you. Your courses are very well focused and cover lots of topics that most of the instructors are considering as "not important enough". So keep up the good work!

[@dimitartanev97]

Здравей, Наско. Аз съм Митко, от академията на Скейлфокус. Ти ме интервюира накрая с Александър, ако се сещаш😂. Тъкмо виждам коментар от българин и виждам, че си ти😂.

[@Devillman90]

@@dimitartanev97 Хах да аз съм и от време на време пиша по някое коментарче. Ти как си обадиха ли ти се oт Скейлфокус? Аз м/у другото напуснах :)

[@dimitartanev97]

@@Devillman90 Да, разбрах... наистина жалко. Аз започнах, предполагам си изиграл роля да ме вземат 😂. Благодаря ти. Иначе, Макс има супер content. Ако не беше неговият курс за ng, нямаше да завършя академията. 😂😂

[@Devillman90]

@@dimitartanev97 Да добре се справи на интервюто! Радвам, се че си започнал. Пожелавам ти много успехи в компанията! А за Макс да прави доста добри видеа малко подробни на моменти но по-добре така от колкото да остане нещо неразбрано :)

[@przemysawkepinski3030]

Like always. Magnificent simplicity in explaining stuff. Keep on !

[@TimothyBrake]

So we are somewhat back at sql in the front end 😁 Everything works in cycles...

[@brunoosales]

This helps to expose just needed data, as per mobile you must limit to only data needed avoiding waste of mobile data... Yet there are a server layer of control before the db, but in the end it's sql in frontend lol

[@jomesias]

Lol yes! It’s more of a generic way of storing the query columns and filter clauses, instead of having to deal with building the Rest api url (and body) dynamically. Imo it beats rest api hands down, it may be a standard but a sucky one at that!! Just create a config file for the GraphQl queries, to load them up and use them on your frontend, it can be managed a lot more easily than a Rest api. This the reason Stored procedures became so useful back in the Sql dbs days! Precompiled execution plans, highly maintainable and can return sql select data as well as receive input params (sql server supported even complex inputs like xml)

[@Microphunktv-jb3kj]

Not sure why this is a versus video... since pretty sure most people use still rest api... and use graphql as a data layer (.. middleware sort of) or am i missing something?

[@badarikrishna3169]

Was looking for you..! 😝 Who agrees that life revolves in circles. Checkout some topics which are making a comeback below 1. Server side rendering with React ( JSPs were using this) 2. Libraries are being preferred over UI framework (returning back to jQuery ? 😝) Your thoughts would be nice 😂

[@dufferzzzzz]

Felt like i skipped a step somewhere, started web dev with plain html and css for regular static sites.. now we use gatsby and typescript to generate static sites... Is it worth it? probably not... but I get paid to do it!

[@dveznik]

I really appreciate the precise pronunciation! Very easy to understand.

[@gabecoelho647]

Great explanation! I've never written an API in GraphQL but now I'm inclined to do so to try it out. Thank you!

[@waldemarenns4874]

Love this one. Thank you for the nice and short conclusion on what the difference is, between GraphQL and REST! Greetings from Cologne!

[@academind]

Thanks Waldemar, happy to read that!

[@raymondmichael4987]

With this kind of videos from Max, huge course on the topic is on the way, I'll buy it even before he releases 🤣🤣🤣🤣. Thanks bro, I like your teaching. Greetings from Tanzania 🇹🇿

[@FangerZero]

Thanks for the video, I had no idea what GraphQL was now I have an intro and I think I'll be sticking with REST.

[@adamtak3128]

FangerZero Graphql is the future. It’s simply amazing tbh. Especially in combination with something like Apollo or an ORM like Prisma. You can also generate your schemes by using something like GraphQl nexus which will also create crud operations for you with a single line if you choose.

[@thomasczthomash1859]

Wise decision. I've worked REST for years and GraphQL for around 6 months. GraphQL will never replace REST, it is not flexible enough and has too many issues without solutions

[@centurion3708]

In terms on fetching much data than needed, you can opt to use dto, convert a database entity into a simplified object to be presented on the frontend

[@lattelover7186]

Thank you. Nice comparation. I'm still not convinced to use GraphQL atm.

[@Netrole]

One of the biggest selling points of GraphQL for me was actually when fetching large amounts of data. With rest i would need multiple requests to different endpoint something like /users -> /users/id/comments (the last request times the number of users), where the second request has to wait for the first one to finish. But with GraphQL you can make it in one swoop and get everything you need. Also you can get data, put data, trigger a utility function, or really anything all in one request. You could literally trigger every single function and resource on the server at once.

[@anthonygayflor8126]

Netrole Im sold thanks to your comment! I was wasting so much time pondering what the best method was for me to save a freshly made document, then reference the objectId for the user documents in one go but no avail. It sounds simple but I’m only in the beginning stages of my app. I know I’m going to be making a ton of more requests like that and it really just annoyed me how complex i know it would have be. Awesome to hear there’s a solution to this :)

[@Kiev-in-3-days]

@@Netrole Isn't graphql doing just that? Multiple queries in the background? In an unoptimized way. Just like all those other trendy tools (webpack, react, Vue...) you just trading code speed for coding speed. Nothing wrong with that as long as you are aware of it.

[@Netrole]

@@Kiev-in-3-days If you dont run complex calculations on the server, code speed really isn't an issue. The real time killer for web apis is network latency. Having a single request instead of multiple consequtive requests saves a lot of time in network latency. I once had a case where i was calling an api and it took 500ms to return with some ids, then i had to follow up with about 5 parallel requests with those ids, which took 300-500ms each, and then some of those requests needed another follow up request with about 400ms until i had everything i needed. So obviously that is some pretty messy code but also pretty slow, about 1400ms. So i asked the api coder to give me an endpoint where i get everything i need in one request. A request to this endpoint took about 700ms, quiet a bit faster. So the code speed was not the major issue.

[@bobergsatoko]

​@@Kiev-in-3-days In the case described by Netrole where the client has to condition the requests and wait for data from the first request, the GraphQL design would have better performance since you don't have the network overhead. It's a pretty powerful example.

[@unmunm6409]

3rd party caching with REST is easier, like varnish or nginx, and is also possible to say witch data you want with REST API, that depends on the design you choose to go with.

[@ChumX100]

A big difficulty I faced when going for GraphQL over REST is that the complexity/unpredictability of requests makes it very hard to optimize the handling of requests. I mean, if the structure of a request just happens to not play nicely with my database schema and I didn't catch this type of request manually, GraphQL might (and many times does) handle it very inefficiently.

[@abeplus7352]

that just means your solution is not well planned or the package you're using for the implementation is difficult to work with. I don't mean this as an insult but here's how to go about it Your schema is like your route description in rest right , since it basically describes what query term to use and what stuff you access to . then Your resolver is the handler for the request it will contain the arguments. now your revolvers should talk to a controller/controller Facade that will give it access to the resources it should expose. this means that your resolver function doesn't have direct access for the db. hence, you just need to write controllers that will return to you resources you expect in the revolvers. So even having complex nested schema definitions will still be resolved quite easily in this approach since each sub nesting or a resource mutually exclusive from the schema definition can still be mapped in this regards. now , for the package you should use , if you're using graphQL in node , then i would highly highly recommend graphQL-js. github.com/graphql/graphql-js , as it will take the pain and suffering caused by sdl and make it baked into the framework itself.

[@ChumX100]

@@abeplus7352 Abe Plus tanks for the detailed response. It may very well be that my implementation approach wasn't well thought out. I was just testing GraphQL on Django with Django Rest Framework. Loved it on the client side. I'll definitely give it another try as soon as I get my hands on a project that could benefit from its features.

[@harunthuo2610]

genuinely love you Max. you're the best! Currently taking your Flutter Udemy course and its first class as all your content. Keep up the great work!

[@academind]

Thanks a lot for your support Harun, happy to read that you like the course!

[@bhatnagarcapital]

@@academind I 2 lv u and brad.

[@camillefloury]

You can select fields implementing ?select or ?fields query parameters with REST APi to retrieve only useful data

[@muthuhari8875]

Please create udemy course for microservices

[@thanveershah4758]

Uploading on youtube can help poor people like me

[@prathamkesarkar]

Yes please I would definitely buy that

[@a.h.s.3006]

@@thanveershah4758 he can do as usual, make a full course on udemy, shows the critical parts on youtube+philosophy of why we do this.

[@thanveershah4758]

@@a.h.s.3006 Agreed

[@qinkanglu8280]

I would love to buy that!

[@malangope]

Great explanation of the overall purpose of GraphQL and how it fits into an application. Heard about GraphQL the other day and wanted to know what it's about.

[@mdjasim3722]

Happy Teachers day Max Bro..You are the only who teached me alot like Angular,Angular Material,Nodejs from Udemy....In Simply I want to say Thanks Max Love from India.

[@academind]

Thanks so much Md, greetings from Germany :)

[@paulmonde6896]

I'm not a fun of the graphql. In Rest API you have a lot of endpoints but in graphql you have a lot of resolvers 🙃 In graphql, you have to add some additionaly work, like a graphql schema for exemple. If you want to send a data back with specific fields, you can simply select or unselect fields in your backend, you don't need a graphql to do that. In my opinion, Rest API wins.

[@andrewyang6806]

Hello Max! Could you add a bonus section of GraphQL in your React Complete Guide course in Udemy? It would be wonderful! Thanks!

[@Migler1]

I second that

[@alexandruluca8446]

I’m actually using PUT in my rest api where I need to filter or apply sorting or anything else. By using put, I can send filters, sorting, projection in the body, thus making it a little more readable in my opinion then sending everything as query parameters

[@olexandrvovchok2384]

That's bad practice. When you use GET you are sure nothing will be changed after the request. With PUT it's all different.

[@paulreitz5904]

Max is really making this CS stuff very understandable. Thank you Max!!!

[@caseyprovost7235]

REST for microservice communications or gRPC and JSON:API for modern front-ends instead of GraphQL ;)

[@Chaaos2]

This was exactly what I needed. Thank you good sir.

[@academind]

Happy to read that the video was helpful, thanks a lot for your comment!

[@BrayanMaykCastroPacheco]

Someone who has really developed a REST api wouldn't say fields are not possible to manage using it, it's actually pretty simple by using the "fields" query param

[@tibordigana2551]

query as data and not URL? Then it has nothing to do with REST. It is almost like people have already forgot SOAP.

[@nicklausbrain]

Tibor Digaňa it seems so really :)

[@tibordigana2551]

@@asanokatana SOAP is useful when you want to call the end point to "do something". The REST is useful to "get something".

[@adrianrygiol1705]

Hi Max, what do you think about OData (compared to GraphQL)?

[@Microphunktv-jb3kj]

Owhat? never even heard of... :D need to look into it.

[@JeffQue]

So, indeed, I was quite curious about "why all the young ones in that FB community are talking about GraphQL?" and you answered my question. I still prefer REST, though, but GraphQL can be useful for my work. So, why not both?, and let the client-writer freely choose (yep, we're not the client coder, but we supply some reference client Implementation).

[@chijiokenna2182]

The argument that GraphQL's specificity allows it to get specific fields and REST does not is very disingenuous. A simple "filter" multidimensinal GET parameter can easily help you achieve that.

[@thomasczthomash1859]

I've been trying to tell people this and they aren't getting it.

[@andyl2895]

Take OData for instance, it implements exactly that with $filter and $select

[@psionicronin1911]

This sounds interesting, got an example of this I could see?

[@chijiokenna2182]

@@psionicronin1911 Simply implement 'filter' as a GET parameter in your API requests (that is after the url, put '?filter[specific]=record&filter[specific2]=record2'. It'll be a lot better to make it dynamic. A lot of Google APIs do this.

[@andyl2895]

Example for Microsoft Project Server: /Projects ( All projects with all properties) /Projects?$filter=ProjectName eq 'ABC' (One project with all properties) /Projects?$filter=ProjectName&$select=ProjectName,ProjectId (one project with two properties) /Projects?$top=1/Tasks (First project with all of its tasks)

[@georgebeltran8536]

I would suggest a course of Nest.js + GraphQL + Websockets = Take all my money :)

[@thanveershah4758]

What is Nest ? Is it same as Next.js ?

[@academind]

This should be helpful => academind.com/learn/node-js/nestjs-introduction/

[@ProgrammingwithPeter]

@@thanveershah4758 NestJS is a fairly new NodeJs framework, pretty much similar to Angular architecture. It's a good framework and thinking of using it someday, if the community grows more. Take a look into it !

[@0xkwiss]

go check hasura

[@KriszX12]

I still prefer Rest... GraphQL is kind of hard to set up for a complex app, but after that is easy to use. Me personally ended up facing its restrictions over and over again when communicating with MongoDB and came to a solution were i used GraphQL and Express js mixed in the app. It is powerful but you need to learn it in depth before you want to use it believe me. :D I will learn it for sure but for now I am happy I can rely on express js any time.

[@Kyudaime04]

I'll have a look at GraphQL but to me giving the liberty of making queries from the front end complexify the permissions definition a lot. I might be wrong I still hadn't time to investigate further...

[@thanveershah4758]

Yeah , We are screwed as a Front End Engineers

[@romulloqueiroz]

@@thanveershah4758 We're not screwed, we just have to adapt. I've been studying GraphQL. It's hard at the beginning, but it gets each time easier as you learn. It's totally worth the effort.

[@ChumX100]

Correct me if I'm wrong, but authorization is part of the API system, so is a backend issue. The client just provides credentials it's credentials as usual. Also, I always thought GraphQL made front-end development easier, as you can get your data in the exact format you need from a single endpoint instead of having to merge bits and pieces from many endpoints.

[@thanveershah4758]

@@romulloqueiroz I can only use GraphQL in the front end if they have used it in the Backend right ?

[@romulloqueiroz]

@@thanveershah4758 Yes. Someone creates the api on the backend, so you call that api on the frontend.

[@randommode3016]

3:52 *Stateless:* they don't care about the exact client to them, for example you don't see session based authentication approaches being used there, because you don't store any data about the client on the backend there, just expose those endpoints and whoever sends the right kind of request, possibly combined with some authentication logic like some attached token, whoever sends a correct request gets the data or may store some data (depending on what you expose on your api)

[@ProgramWithBalaji]

Hello Max, What is your next course on Udemy?

[@academind]

We'll share some news in the next weeks :)

[@ProgramWithBalaji]

@@academind Waiting for the next week

[@alkismavridis1]

Great video, thanks! The more I learn and work with graphQL, the more genious I find it.

[@Kessra]

After almost 2 decades I wonder why people, especially ones producing tutorials and guides, still don't understand what REST really is. REST is loosly speaking just Web surfing for applications. You design the interaction between a server and a client like you'd normaly do on Web pages. Most so called REST APIs demand external documentation (Swagger, OpenAPI, ...) which a developer has to consult and hack into some code which in the end just produces some HTTP requests. In a true REST environment, however, a client indicates its capabilities through the "Accept" request header and the server will answer in a representation format supported by the client. This is summarized as content-type negotiation. The representation format itself is based on a media type that defines the syntax and semantic of messages/documents exchanged, plain JSON does neither define links nor respective elements/attributes/properties of a resource. I.e. in HTML you have all kinds of tags and the spec defines when those tags are admissible and what data they may contain and so on. A server can also use HTML to "teach" a client on what it can do next. I.e. a response may contain links and/or form sections. A link should usually be attached to a link-relation name to set the referenced resource into context to the current one. I.e. on a pageable list you might find relations such as first, next, prev and last or self to hint a client about the purpose of the link. HTML, as mentioned before, may also contain forms. Those forms not only provide a client with the necessary information on which HTTP operation to use, the target URL to send the request to and the media type the representation format sent follows, which in the case of HTML is often implicitly given as application/x-www-form-urlencoded, but it also teaches a client on the properties a resource supports. There is no need for external documentation that way at all and the form is dynamic on top. You need to add a new property to a resource? Just add it, the form will teach clients on the fly. As these support the media-type they will also know how to handle a new element/property added to a resource. One of the major problems those so called REST APIs have, is, that they use typed resources. Instead of sending the state of a resource in a representation format the client supports (after previous content-type negotiation) those APIs send out pre-defined structures of data which clients often implement directly 1:1, meaning that if anything changes in that response a client will not be able to process the response correctly. In best case the new stuff will just be ignored, in worst case the whole thing will blow up. By that, one usually should aim for a REST architecture if the server side is frequented by plenty of different ciients, especially ones not under your (direct) control. As one of the main goals of REST is the decoupling of clients and servers, adapting to changes and thus future-proof processing is inherently integrated into the overall design. For simply frontent to backend communication you don't need REST, but simply calling anything HTTP related REST is just wrong and probably the reason for the confusion so many people really have what REST is and what it isn't ...

[@16yanki]

I think what you said in 6:17 might be wrong. Graphql does support GET method, it's not the most common but saying "Graphql only works with POST" is way off. So in case you want a graphql response to get cached you will have to use GET, since caching is not supported for POST method. Other then that I think the tutorial was pretty clear and helpful.

[@emarcelino3]

fantastic. Could you make a video about the differences between graphQL and OData ?

[@thalibmuhammad9519]

academind successfully made me a better web developer

[@OM-bs7of]

Rest APIs can do everything that graphql does. Rest APIs can be programmed to accept the fields to be responded as parameters. Graphql adds more overhead and rest APIs are more extensible. No significant incentive to use graphql.

[@mikebell3579]

This was very useful. Now I understand where and when I would want to use GraphQL over REST. Thanks Max!

[@academind]

Happy to read that, thanks a lot!

[@fabmartel]

* what is the time to set up a GraphQL server layer? * what are the performances of this GraphQL server that comes in surplus between the user, the server and the database? * what is the impact (time, manipulations) when we have to change the structure of the data? * Is there a tool to deploy automatically? All this must be taken into account, and there on the net it lacks explanations that could tilt the balance between REST and GraphQL. And I know that on the side of GraphQL it is very easy to create queries because very padlock level schema and to have a precision of data in return, these are the only advantages that I see. But to convince, we must also see the technical part of how? at what cost? and time spent?

[@dylanalbertazzi]

So so good! Thank you for making this content!

[@stefersonpatake]

Max, Graphql looks easy to use and have more flexibility and so on... and what about the security of the whole database when you expose such fields name of the tables? With a 'little investigation' on the source code of the app, it's look like very easy to understand the structure and make some nasty call to retrieve all database data... Am I wrong about that? Thanks

[@BuddikaChaturanga]

you have to define boundaries, limitations, aliases etc.

[@adamtak3128]

Steferson Patake from my understanding you can only query for what is exposed. So if in your database you have a user with Id name email and password you can set your query for users to o my return any field you choose and exclude the rest

[@johnsavadkuhi7600]

hello mr Max. you are one the best Teacher in the world , I have never seen anyone like as you. teach at Harvard university. 👍👍👍

[@academind]

Wow, thank you so much for this amazing feedback John, this means a lot to me!

[@framegrace1]

With REST endpoint,function and attributes are parsed without needing to read the full body of the request. It can be done very fast and with no buffering. Then just stream the body to the correct handler. GraphQL needs to read the full JSON body before deciding what to do, and which endpoints to send. which means huge buffering issues and a very complicated handling. And all this for just a standard way to pass attributes? Would be much better to just agree on a default http attribute spec for REST and call it a day.

[@sahar6154]

As always great explanations. Thank you Max🌹

[@leftinashes]

I got my eye on Maximilian's Air Max 90s... ;) Danke schoen... great work as always!

[@abdisamadkhalif4283]

What about gRPC and gRPC-Web? Thank you Max.

[@AlejandroMartinez-gx1fc]

I'm working in a project, and i decided to use nuxt + vue + apollo + graphql + node + express-graphql + orientdb and i really enjoy it, orientdb is a nosql graph database and i think it works too good with graphql. Graphql is more complex at the beginning but i love it, and don't think go back to REST api again.

[@yaronlevy]

We can use FaunaDB which support GraphQL natively.

[@joshicaveira]

Watching you in any Speed below 1.5x is just weird for me ahahahaha Love the course bro

[@alexisdvt]

Thanks Max! By the way I wish that you and your team make a course about headless cms or e-commerce with Hugo! Greetings from Costa Rica!

[@academind]

Sorry, currently we got no plans regarding such a course, but this can always change. Greetings from Germany :)

[@alexisdvt]

Academind thanks for the quick response, no problem I’ll continue to learning it by my own 😊

[@andrerodriguez6464]

I've been using GraphQL for 3 months and now I can't think to go back to REST, once you get used to do the queries and mutations, it becomes really easy to use.

[@oliverspeck7411]

thanks for this introduction into GraphQL!

[@digigoliath]

Thanks for a great video. I just started learning Web Services & APIs in my Bootcamp and this is a great help.

[@academind]

Happy to read that, thank you!

[@microtech2448]

Certainly nice presentation still have a question. In graphql does it filter record for specific properties at database level or it fetches all the properties of object from database and then on server it filters columns based on query parameter? E.g. in your example graohql will bring just name and age at database level itself or at server side it will wipe out other unwanted fields?

[@ankitsachan1242]

This is very helpful for me to understand why I have to go for GraphQL. Thanks 🙏🙇

[@ccoddington]

Isn't it OData vs GraphQL?

[@viniciusvbf22]

YES! Or Web API vs GraphQL. GraphQL is built over RESTfull concepts, as the Web API is. Many people don't get that.

[@shnam928]

Your projects are so useful & perfect👍👍

[@desongyu]

Another great video Max! Excellent work.

[@fernandoz6329]

From a newbie stand point of view, GraphQL seems an evolution of XML Web service using Json and added some spice in the result. I know is not like the but it's looks like it. Great explanation, very clear and understandable.

[@liberalfarid]

Can't you basically use post only for your rest api and have your own query language in the json body.

[@yashkhandha]

Concise and to the mark. Amazing content! Thanks mate

[@academind]

Thank you Yash!

[@LLemminkainen]

I love how he says also instead of also

[@jmarkowski]

What's missed is that a major advantage of REST api's is that the requests can be cached. Not true with GraphQL queries.

[@shaunpx1]

My concern which I have been researching and yet to hear is security 🤔 how can we secure graphQL data qeiuries, what are the vulnerabilities ?

[@WigglyMalmsteam]

I’m a fan of Neo4j + GraphQL

[@fabianandiel6095]

Max is the best in teaching! Not more to say!

[@huynhut5395]

You say graphql is only work with POST method, maybe this is wrong. I see "GraphQL HTTP server should handle the HTTP GET and POST methods" in document of graphql. And can you create a video tutorial for uploading images with Graphql that has the same progress as Axios?

[@soushi8885]

I feel that REST API and GraphQL API are a bit like SQL and noSQL. Correct me I'm wrong, but it feels like the clarity of REST API feet well with the rigidity of SQL databases and the specificity of GrapheQL feet a lot with the flexibility of noSQL databases.

[@MA-zo6tb]

Thank you...I am in step to do GraphQL...

[@ExehakanTV]

Greetings, Can you prepare a video tutorial about installing pure php with GraphQL?

[@geoffrey_lee]

I am sure that I will get some negative comments surrounding this, but this is not a very technically accurate video. A rest API and a GaphQL armament technically different to implement, they differ only by their specification which many, many, many APIs differ by. To consider Facebook's API as a "standard" on the equivalent of REST is not accurate. I apologize for being a little bit negative here, but the real difference is just the approach that Facebook took to their API. There is no fundamental differences between REST APIs and it.

[@misha130]

Do you think graphql was made to solve the problems of http/1.1 and with h/2 it has become redundant? Fundamentally, I feel seperation of anything is better than bulk executions

[@w0083e5c]

In REST you actually rarely do a POST without any Body, that does not make a lot of sense. In case of a SELECT, you would use a URL similar to the one you use. By default you would use a GET for that - where you won't be using a body but instead the URL param. I'm sorry but I dont get this slide.

[@kde6769]

Beautiful video, great explanation!

[@thomasczthomash1859]

Answer = REST. GraphQL is a half cooked solution riddled with problems.

[@raymondwaluyo4082]

Hi max, i love your video as always 👍. Do u think using apollo is better than using express graphql ? Are u planning to continue ur graphql tutorial for graphql subscriptions ?

[@royzac7829]

Wonderful Job!! Thank so much!

[@fatememirjalili]

Great video! Your videos are really helpful. thank you!

[@weuzeify]

I was just learning about graphql and rest and you uploaded this . Oh max you r m'y magic man🎩😁

[@donnytechiera957]

Your explanation was so clear , thank u sir 👊🏽

[@parkour111100]

Great explanation, thanks Max!

[@halledan]

I hope you will build a serie on graphQL with Prisma2! I propose vue.js as frontend if you do :)

[@PlayaBurger]

this is perfect. thank you so much

[@simoghf1888]

Best instructor !

[@willysnowman]

Very good overview!

[@gmssoberyahsharahla]

I'd like to get this presentation that you used in the video

[@L4poker]

great video max! i have a question: if i use a specified SQL query with my REST API, wouldn’t i be able to fetch exactly the data i am looking for? im not understanding how i would be fetching more data with rest vs with graphql. thanks again

[@danisimeonov4759]

The problem is subsetting data. So having a mobile app fetch only 3 out of 12 attributes for a summary, while desktop app displays all 12. It’s difficult to write all that logic into one endpoint. The standard is to expose all data, and client would just use what it needs. Alternatively you would have to use multiple endpoints for almost the same functionality. (I am learning graphQL, take this opinion with a pinch of salt)

[@فريقالأبطال-ت2ك]

The best explanation ever

[@mkhalidumer]

HI Max, @10:02 you refer to a video, where can I find it as the link is not in the description

[@animeonly6839]

Something funny just happened I skipped his udemy lecture on graphql to check myself do I need to learn graphql and I searched graphql vs rest API and on top this video showed😅😅 Max is everywhere😂

[@DanielMircea]

I wanted to like graphql but you can't do any file uploads, you have no versioning, no caching as everything is a POST, a schema that needs to be shared with all the clients, an overly strict type system that makes sending deeply nested hashes more difficult than it needs to be and many other problems. Even the benefit of fetching less data isn't great, unless you're quering a nosql database. What happens, is that you still end up doing all the sequel queries server side, and you just save a bit of data.

[@andyl2895]

I dont see how graphQL is able to fetch less data than for example an OData REST query

[@lattelover7186]

@@andyl2895 It can fetch less data because GraphQL can request specific fields only, tho in REST we can still do using query parameter like /user?&fields=name,age but it adds additional complexity in backend.

[@andyl2895]

@@lattelover7186 OData has it built in, and I can't think how GraphQL doesn't have to implement it in the backend

[@Kiev-in-3-days]

You can always filter returned data.

[@Channel-qr5mh]

@@lattelover7186 GraphQL adds more complexity and overhead than REST anyway

[@andressuarez3079]

Excellent explanation. Thank you bud.

[@leonardoraele]

So, graphql is better, right? The video actually didn't stated any meaningful advantage of Rest.

[@wennie2939]

Max is always the best!

[@hadimohammadi9267]

Please explain how to create documentation like swagger in GraphQL. I don't know how to implement it. It's not straight forward in GraphQL.

[@ravis069able]

graphql - single interface solutions...Rest API - multiple interface solutions