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.
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.
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!
Здравей, Наско. Аз съм Митко, от академията на Скейлфокус. Ти ме интервюира накрая с Александър, ако се сещаш😂. Тъкмо виждам коментар от българин и виждам, че си ти😂.
@@Devillman90 Да, разбрах... наистина жалко. Аз започнах, предполагам си изиграл роля да ме вземат 😂. Благодаря ти. Иначе, Макс има супер content. Ако не беше неговият курс за ng, нямаше да завършя академията. 😂😂
@@dimitartanev97 Да добре се справи на интервюто! Радвам, се че си започнал. Пожелавам ти много успехи в компанията! А за Макс да прави доста добри видеа малко подробни на моменти но по-добре така от колкото да остане нещо неразбрано :)
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
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)
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?
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 😂
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!
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 🇹🇿
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.
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 :)
@@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.
@@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.
@@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.
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.
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
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.
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.
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.
@@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.
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.
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
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
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.
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 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.
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.
* 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?
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
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.
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 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.
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)
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
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.
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 ...
@@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 !
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.
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?
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).
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.
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.
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.
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?
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.
@@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.
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)
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.
You can put that logic in your resolver. Of course this is if your API Most of the time communicates to a db and have a couple of corner cases where it doesn't. If your API never uses a db, there's no point in using graphql.
GraphQL is nice tool for sure. More complex case is that calling 3rd API then access db then call 3rd API then access db. I just want to know how to solve this kind of case. This case may occur on e-payment
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
how about both ... think about it , writing a rest api super trivial right, especially given that most packages and frameworks have been around for a very long time. so why wouldn't you write a rest api and then consume your rest api via graphQL layer . guess what you just setup an encapsulation to all your micro services. The way i go about it is the following. If i'm writing a personal project , i tend to choose rest . As getting me from 0 - 100 is very simple . however , if i'm maintaining a huge amount of micro services , then i will write those in rest , and consume them via a graphQL layer to get the benefits of SDL , declarative resource fetching ... etc.
the reason why i say this is because it's alot easier for people to wrap their head around rest then graphQL . consuming an api through graphQL basically means you're writing a service that forwards http requests to your rest service.
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.
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
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)
im running this example and everything looks good in eb however im getting a 500 error - .eba-2mppykm8.us-west-2.elasticbeanstalk.com/:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error)
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.
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 ?
wait so you are saying the only benefit of GraphQL is that you can specific which field do you want ? But that can also be achieved using rest apis ofcourse we need to add more logic in the backend but it totally possible only with few lines of code. So are you saying GraphQL is nothing but hype ?
GraphQL simply makes the back end developer's job harder, especially on the optimization part. Most developers work on both the frontend and backend. If you're the one building the backend anyway, you already have total control of the format of the data - return it in the most efficient way. If you are building an API to be consumed by others, you definitely to have control on what clients can request. In GraphQL, it is so easy for a Payment Platform API to accidentally allow the client access to private information.
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.
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.
At 5:32 -- I'd probably stay away from saying GET requests don't have a body. Some good info at StackOverflow about this. This comment from 2015 notes that RFCs 7230-7237 removed the phrase "the message-body SHOULD be ignored when handling the request" from the HTTP spec: stackoverflow.com/questions/978061/#comment68112820_983458 . So initially not *using* the body from a GET request was a [strong] recommendation ("should"), but now even that recommendation has been removed. As a practical example, ElasticSearch depends on GETs with bodies (stackoverflow.com/questions/978061/http-get-with-request-body#20349624). If you need to do something covered by the verb GET and need a body to do it (perhaps there's a query that's routinely too long for a querystring), I believe we're getting much closer to that being standard practice.
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😂
