In the video you had a pop up note to not store passwords in the db. Did you mean don't store "plain text" passwords? I can't think of anywhere else to store them (encrypted of course)?
If we are trying to query data from an existing microservice written in REST and fetch it with our own app written with GraphQL. Is that possible or are we forced to also build out a REST API in our own app to fetch from the third party REST API?
You are the link I've been missing between programming theory and programming practice. I can't tell you how much you've helped me improve my programming skills. Your examples are concrete and applicable, not too simple or too advanced. Thank you.
I liked the content, however I have to disagree, that is why we have the concept of DTOs inside endpoints when using restful api, because you do not send all the object, you can send a partial object, you might not be allowed to send certain fields or receive them in the request. So this precise security issue would be more from the bad design rather than restful functionality.
When this REST "problem" was mentioned, it was exactly the first thing I thought. Are using DB objects directly in the API interface? That is just bad architecture. You always abstract the interface objects. This is a contract. And it shouldn't change when you optimize the database.
100% agreed on NEVER sending the raw db objects back to the caller of the api. I like to create dedicated response models with Pydantic (ex. GetBlogsResponse). Then convert that response model to json (automatic in FastAPI ftw!) before returning the data to the caller.
I usually even have 2 or more DTOs for a DB entity, the basic one has a requestDto and a responseDto, that is the most basic structure, because you never share your entities structure publicly.
> "There is no standard way of doing [controlling the fields you get]". Aside from the fact that REST isn't a protocol so "standard" is a hard thing to define here, there are many ways to overcome this issues, and all of them are standards in HTTP and pretty natural in REST design principles: - HTTP cache on GET request; which is always useful - Always return empty response on PUT/POST/DELETE request, with a location header if the resource modified is at a different location - Use content negotiation (request's ACCEPT header and response's Content-Type header) to return smaller response Most problem with "you can't control what you get" are coming from badly designed API and a lack of understanding of what HTTP has to offer. And also, most people don't know more than type-marshalling and think their internal datamodel is the same as the returned resources.
After working in graphql for a year after working in rest for a ~decade, I am not even slightly sold on using graphql. Ignores how HTTP response codes work, every api call is made to /graphql, etc. I don't see a ton of scenarios. for the overfetching/underfetching problem.
This is unfortunately NOT what REST is or should be. While plenty of people seem to have such an understanding of "REST", this is basically just citing what others understood incorrectly in the past and is more or less just wrong or incomplete at least. View REST as a collection of indirection mechanism that help to decouple clients from services. In a REST architecture it is the job of the service to teach a client everything it needs to know to make further requests. It provides URIs the client can use to retrieve new resource' states expressed by a negotiated document type. But instead of using those URIs directly i.e. to determine its use, URIs are usually attached to link-relation names which allows to swap URIs out when needed while still being able to lookup the URI through its link-relation name. Media types are a major part of REST. Plain JSON does not provide a client any hint on that data, it doesn't even specify what a link is. Returning plain JSON is like returning a plain text document. Unless a client knows what type it received beforehand (which is already a hint on a tight coupling) it won't be able to make any sense of it. This ultimately leads to typed resources which REST does not have. Just read through what Fielding clarified on some of the common issues he has with people calling RPC-like services exposed over HTTP REST/ful: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven. Media types are nothing more than a human-readable description of what elements/components to expect within a document as well as the semantic description of what this field expresses and when it should be used. If a client is able to process such "documents" it is able to extract the data of it and it is then the job of the client developer to provide some mapping from the received representation payload to an object your application can work upon further. The media type de facto becomes the part both services and clients bind to. The contract if you will. This guarantees that messages/documents exchanged are always processable by the recipient if client and server could agree on a media type both support. In REST you could even have various media types the state of the resource could be expressed in and as such the more media types your client and server support, the more likely they become to interoperate with other services out of the box. In regards to sending data to the service, a typical client interaction here should look like this: clients looks up the URI of an exposed "form" link relation and requests that representation. It will receive a form-based representation format that follows a well-defined document type that defines the respective parts of a form. That definition will specify that there will be a certain property responsible for defining the HTTP operation to use upon submitting the form, the media type to represent the data in upon sending as well as a target URL to send the data to. Besides that the respective components the form contains will lay out the structure of the properties the target resource has and that are expected by the server. There is no need to contact any other information than that to generate a request. This is HATEOAS applied. You use the hypermedia controls defined by the media type and utilized in the response to allow clients to progress their task further. How a client is supposed to know what to do next is a bit out of scope here. Though as Jim Webber mentioned in his great talk back in 2011 ( ruclips.net/video/aQVSzMV8DWc/видео.html ) you should basically create a "domain application protocol", similar to how shopping cart and checkout are done on Amazon or elsewhere, where a client is following a predefined interaction protocol until either the task is complete or the task was aborted mid ways for some unknown reasons. This can be done by designing the whole interaction as part of a state-machine the client is following along until it completed its task. Granted, all of those indirection mechanisms add up quite some complexity which are not needed if you are just interested in interacting with your mobile app clients that are fully under your control. REST should be used only if you want/need a service that has to run for decades and thus supports new stuff over time and/or if you have plenty of clients connecting to your services that are not under your control. While every peer in such a network should act on the same premises, if a client violates some of the requirements it is its own fault similar to how HTTP clients can not be made accountable if a server updates states on GET operations. If you don't need services to coop with change or don't need clients to be able to interoperate with other services except for yours, don't do REST.
yet another thing about new tech that annoys me: facebook thought they hava a problem so they create graphql. does your company have facebook level problems? definitely not. ... so many programmer choices are driven by shiny toys. makes me sick.
I CANT use my car because my way to work is solved in 5 minutes on foot? or I shouldnt use my Mustang oder Dodge to drive to work if it can be done in smaller like Twingo or Chiquichento?
After developing some applications that store many millions of records, I can say that REST API's are the only way to go. The security issues around REST are easy to manage if you enforce Swagger definitions of what endpoints expose, as accidental leakage of data can be picked up through exceptions with the approved Swagger data structure. Also, GraphQL has huge performance issues, where you can't fine tune heavily indexed database queries to speed the query like you can with REST. With REST, you know how the data will be structured, so targeted database indexes can improve query performance from 10x to 200x faster. GraphQL may be good for small exploratory queries, but when writing a full stack application, you know exactly how the API's will be called, because you wrote the front end, so again, REST API's stand out as the preferred solution for a full stack application, or an application that consumes the APIs in a predictable way. I would only implement GraphQL if it was necessary to have a 'Supports GraphQL' marketing line on the product home page, otherwise, for me, it is a cool but inferior technology. There are many ways to solve the 'many API calls for REST endpoints' issue. The key with REST API's is, 'It's important to understand the intent of REST API's, so that you can break those rules in a consistent manner'. And yes, it's almost always necessary to break the hardline REST API rules for endpoints to get an application of even medium complexity to operate at speed.
@David Thomas Agree 100%... Also, it seems there's too much boilerplate code with GraphQL. After years of developing REST servers I've made my own set of libraries and servers that can work with any data model and provide most of the features that GraphQL does, and works well with million documents sized databases
@@BuyHighSellLo Absolutely, they have quite a lot more resources to optimize the delivery of their graphql tech too. GraphQL is fine for adhoc queries that don't see a lot of use, and as you can imagine, the high level of chatter between the GraphQL server and the database layer is a sub-optimal way to expand on queries. By far the fastest way to get data out of a database, in a predictable pattern, is to retrieve data with hard coded SQL(or whatever db language you use) queries, that are backed by intense performance testing, leverage database queries, and get all the data in a single db query. If Facebook is having amazing performance with GraphQL, it makes me think they are writing optimised queries that are triggered when specific shape GraphQL queries come in, and not using a generic GraphQL query engine that isn't able to properly leverage a single db query that triggers associated indexes. When you see the light and implement an optimised DB query to get data in a known shape, then you end up exposing that query via REST, hence, in the vast majority of cases for larger applications, REST >GraphQL, by far
@@warpmonkey The issue here is that you're assuming you _can_ provide data in a known shape. GraphQL is designed for the opposite of that, when you don't know the shape. At my last company we used GraphQL to great success because it was a tiny startup with a massive data model, the frontend was evolving constantly, and backend needing to manage a brand new api endpoint every day is infeasible. Graphql provides a great solution. The biggest issue with your response is that you assume that a company has to be huge in order to optimize their performance with GraphQL, but not huge in order to do so with their db queries. In general, I don't know _any_ business developer that spends time optimizing db queries unless they get incredibly out of hand. That time is better spent actually delivering business value, which GraphQL allows you to do. Is graphql a good solution for everything? Absolutely not. I think it was good for that use case though. I just think a lot of the arguments in this thread are incredibly dismissive of the actual power of the tech. Just like anything, it depends. One thing that is very difficult with graphql is security. But, you balance the difficulty managing that vs the fact that you no longer need to manage frontend apis for however many UIs you have. Hint: at my last company it saved the backend over 40+ manhours a week just in new api calls.
@@a-rezhko sorry but you're incorrect.. HTTP has been replaced 3 times.. Google wrote spdy which became v2, the v3 gave us QUIC, v4 was drafted in 2020. So the current live version is only 7 years old and the latest is not even 2. OData was always niche and now its in rapid decline as companies EOL legacy apps.. you might as well be advocating for VT100, sure it's still out there but it's a dead end..building anything new on it means apps are obsolete on launch.
Software development would be so much better if everyone worked together and stopped re-inventing the wheel. It makes open source bloated, confusing and overwhelming.
Clearly you haven't tried Wheel XI.1 Lollipop Leapord. They introduced an SDK for 3rd party plugin extensions, allowing for custom Roll interactions via subscription-based centripetal force engines and freemium features that allow affiliates to monetize their Rotate physics services through distributed blockchain transactions. All with extensive Analytics dashboards! Throw out your legacy wheel tooling, you won't need it. Also it won't be compatible.
@@Simon-xi8tb Agreed! Clojure does not need to out-compete every other language out there to be successful. It just needs a community that’s big enough to make it sustainable in the web development space. There are plenty of people actively using Clojure for work, and the ecosystem is very robust. In short, I don’t think Clojure is in danger of going anywhere in the foreseeable future. Now let's see how many can make Clojure a standard and all agree to use it without re-inventing the wheel and confusing the open source space of options even more. See my point?
@@Simon-xi8tb just one more tool in the toolbox. There will be another 5 next week. All saying they have advantages over it. Maybe you can convince them to not re-invent Clojure. That was my point. Open source needs better teamwork across the spectrum. Not just for one tool for a short time. Build upon the tool and keep it going. Yes and a language is a tool.
Great video. I have the opposite conclusion. I think GraphQL works for small needs, but handcuffs you at scale. REST has more things to worry about initially, but you can control them in the end game when the requirements get nuanced and intertwined. We did extensive analysis of both for a major application, and went with REST over GraphQL precisely for the ability to maintain control at scale.
If it is an mobile app, better don’t go for graphQL. Users hate frequently app updates just for fixing bugs. majority of business logic should stay in server and app just handle displaying.
@@alvin3171997 Look up "N + 1" with graphql and you'll find one aspect. The other is just the general lock-in of any library that takes over for you. It's easy at the start, but corners you in the end. It's not run time scalablity, as much as development time scalability--the ability of the developer to do advanced things toward the end of the effort.
@@alvin3171997 To elaborate a bit more on one thing. Suppose all the variables you need are not at rest, but must be calcualted at run time based on inputs. In REST, this is trivial. In GraphQL, becuse the libraries (including ORM) have taken over for you, it's hard.
Just for information - there is a bit abandoned evolution of classic rest called json:api. It has many interesting conventions for handling complex and dependent resources. I dont like graphql because of its unpredictable execution pipeline. I found a lot of similar concepts in json:api and it is a bit comfortable for me to handle
Still the worst thing about using QraphQL in Python is that you have to write "strings" or dicts which completely eliminatas the advantage of syntax highlight, intelli sense and other IDE features. I love Python but if I'm to work with GraphQL project I'd chose TypeScript any day.
An excellent video tutorial as usual. Now, with a Flask/GraphQL/Ariadne backend, the question becomes, how to design and implement the front end, that will actually fire off the GraphQL queries and display, or otherwise handle, the results. As well as minimising database queries from the backend to the GraphQL server, requests to the backend from the frontend could also be reduced by smart caching of some kind.
There is a mistake in GQL Schema: 1. Never use [Type], because it means nullable array of nullable items of type T. The allowed values for this includes: null, [], [null] and [null, null] and so on. Use [Type!]! -- it includes an empty list bust the null for value and items is disallowed 2. Never use Type! as return type in queries if you are not sure that the corresponding value exists. blog(blogId: ID!): Blog -- returns Blog or null if blog couldn't be found by id 3. Never use GraphQL errors to pass business logic errors -- just because there is no way to describe the errors with the GraphQL schema.
Stating that Swagger sets "the standard" is at best propaganda and at worst misinformation. Swagger does not set the standard for REST protocols over HTTP. REST and HTTP Actions are SEPARATE ideas that have never worked very well in practice for anything beyond toy projects. In any project with dependencies, REST implementations are always dealing with exceptions and workarounds (which are all pointing to RPC) that make it obvious that REST is a failed approach. It's better than inheritance, because the ideas aren't coupled to bad design, but are poor targets for overall architecture. If you have an analytics system you'll be using an RPC API over GraphQL and any system less complex will be just fine with an RPC API without wasting effort on these terminal REST projects.
I'm not familiar with graphql at all, FaceTime this video, it feels like writing manual definition of data classes before the dataclass module. It makes you write more disciplined code, but inflexibility leads to limitation like the n+1 problem. Also, if the rest interface was created with fast API, lots of the testing issues go away because swagger docs are free in fast API. So graphql just seems like an expensive way of shifting API design further downstream
If you use ODATA for REST you typically wouldn't need to make separate calls to get related objects. e.g Author details of the Blog post. It has a keyword named "EXPAND" that your specify in the api call to do this.
9:16 regarding sending the data directly from the database using REST. I think that always we should use DTO and never expose our db entities. Entity should be isolated from client requests.
In my experience, GraphQL is fantastic for the backend for frontend layer - just being able to request what you need is the largest selling point. There are other huge benefits: self documenting, type generation, great deprecation patterns, parallel queries, etc. The biggest issue I’ve seen in the field is that consumers aren’t willing to put in the work to understand how to use GraphQL and they end up treating it as a RESTful API and typically grab wayyyy more data than they need. Or worse, they over utilize the recursive nature of GraphQL rather than using dedicated queries to fetch the specific data they need.
I enjoyed this breakdown. My personal experience with GraphQL has me putting it in the bin, probably permanently. The N+1 problem and subsequent design limitations have been such a gigantic issue that I would sooner code my own custom batch endpoint than use graphql. It is a nice idea though, I am sure it works very well for lots of applications that don't come up so hard against the limitations.
thanks for the video! informative and entertaining as always! i'm not a friend of mixing different syntaxes... syntices (?)... in the same file. off the top of your head, do you know of any graphql libraries for python where you can define the graphql type definitions separately? i guess reading from a file always works 🤔
so with graphql you have to predefine queries... EXACTLY as you have to do with rest. acting like rest necessarily and literally means mapping table to api is just ... idiotic. want fast "rest" development? use rails.
In GraphQT, can you return Author name on the same level as Blog ID? Like {"data": {"blogs": [ {"id": "1", "authorId": "1", "authorName": "Author 1"} ] } }
I was just thinking, well shouldn't it be 256 shades of gray then I realized how amateur I was of course you have to subtract 0 and 255 as they are black and white.
this is a bit lopsided on the rest side, as it shows a barely correct example of using POST to update an existing resource, and the issues with security are not specific to rest here either, and like using ariadne for graphql, you would just use a rest framework for rest, having usually the same amount of predefined utilities, that allow you to create data serialization and deserialization, validation etc. so it becomes more a question of predefined architecture: ariadne forces you to connect to some architecture, but while rest apis often have shortcut pass through solutions, it really also depends on how you layer it - and there rest apis can also already have predefined "ways" to do. in a way, rest is simply more "bare bones", while graphql is specifcly created to host an api, that has a strong independent app mindset. it is easy to create a rest endpoint that returns some custom dataset, or to govern how much data each request really gets, making rest usually a backend heavy development type, and usually, with the need to have apps, that are quick, and specialize in making the user happy, having the query decisions on the backend is often simply the more controllable, easier to finetune situation, if you don't run a platform which operates a large amount of independent and often thirdparty app logic.
In part, the GraphQL schema is the documentation (and you can view it in the playground most GraphQL libraries offer). You can add comments to a GraphQL schema which will then be included in the documentation. Here's an example of a GraphQL library that uses this: dgraph.io/docs/graphql/schema/documentation/ (I haven't used this library myself, it's merely intended to show how documentation is handled).
One of the biggest challenges for me with graphql (and to a lesser extent with REST) is how to return errors to the client. The "happy flow" is standardized very nicely I think, but "unhappy flow" is all over the place. Would be curious to hear your take on that.
@@mymawazo1449 That would be one way of handling it, but by default most GraphQL packages use the HTTP 200 status code regardless of whether an error was returned or not. This is because you can query / mutate several fields in one query, some of which may be successful and some of which may return an error.
When part of the data is queried succesfully, you might want to show that data to the client, while handling the errored out data in some other way. Also errors have no typing by default in the graphQL packages I've worked with in contrast to the data. How do you handle this when using typescript for example? So in short, yes you could just modify your package to throw a status 400, I've done that in one project, but it's not a very elegant solution. That's why I'm asking for Arjan's take
Easiest would be to check length returned error array and treat it as a failed response if its gt 0. Any controlled throws at server is caught that way. Connection errors is upto client and or client library to handle in choosen way. If you want to be able to use partial results its a bit more work though.
Hi Arjan, you make great videos😀 . I like do build some bigger Applikation with a UI (PyQt, Tkinter, WX) but i have some trouble how i can build it with a MVC-Concept. I always get a big mess in the controller part. Do you have some hints? Maybe this is a idea for another great video .😅
I do not know much about graphQL but isn't a API that allows the consumer to define the returned fields much more insecure than a REST API that only defines endpoints with data, the developer want to send to the consumer? Until now I only use REST APIs and I always define the data types for a specific end point in my backend (in my case .net Core 6)
Your schema is the "data types". The graphql schema defines what fields they are able to ask for as a caller. You can also very easily provide field level permissions since graphql somewhat native supports custom decorators (field level resolvers also help)
When I used the api I had created for the frontend devs at our, I realized how difficult it is to use. I focused so much on the data structure and forgot about usability. I was considering migrating at least certain parts of the api to GraphQL and this video really helped me understand it. This video has helped me understand which parts are better left as REST.
at ruclips.net/video/7ccdWqGgHaM/видео.html you mention 'don't store passwords in the database' - where are you supposed to store passwords? Just to generalize a bit, looking at web development security, it's difficult to find easily digestible information. Maybe it would be interesting to do some videos showing real life exploits, as a suggestion. Thanks for your work!
I think in this case it means "don't store plaintext passwords in your database". There's a series of transformations that you should apply to the passwords before saving them on your database, so that they can't be retrieved in case there's a database breach
When user creates account, accept plaintext password in the request, then use an "industry standard" hashing function like bcrypt to create a hashed password string. Store only this hashed string in the database. When the user signs in, accept the plaintext password in the request, hash it again using the same hashing function, check if the recently hashed string matches the hashed string stored in the database for that user.
No, in 8 bits, there can be 256 total shades example: 0,0,0 1,1,1 2,2,2 ..... 255,255,255 where 0 is black and 255 is white, remaining 254 are gray shades,
@@ArjanCodes I was kind of thinking that, but since screens will never be able to display pure black, and a brighter light will always be "whiter", I would count both as gray. LOL philosophical binary claptrap. :-P
Now I wanna try coding a GraphQL API to figure out how it works! However, I feel like there are some great frameworks that make creating REST APIs much easier (Django Rest Framework for example).
Thanks! After playing around with Flask and a couple of the GraphQL libraries, I must admit I prefer backend development with NodeJS and Typescript. To me that feels much easier to use.
The first 1,000 people to use this link will get a 1 month free trial of Skillshare: skl.sh/arjancodes02221.
Thanks!
In the video you had a pop up note to not store passwords in the db. Did you mean don't store "plain text" passwords? I can't think of anywhere else to store them (encrypted of course)?
If we are trying to query data from an existing microservice written in REST and fetch it with our own app written with GraphQL. Is that possible or are we forced to also build out a REST API in our own app to fetch from the third party REST API?
You are the link I've been missing between programming theory and programming practice. I can't tell you how much you've helped me improve my programming skills. Your examples are concrete and applicable, not too simple or too advanced. Thank you.
so true
I liked the content, however I have to disagree, that is why we have the concept of DTOs inside endpoints when using restful api, because you do not send all the object, you can send a partial object, you might not be allowed to send certain fields or receive them in the request. So this precise security issue would be more from the bad design rather than restful functionality.
When this REST "problem" was mentioned, it was exactly the first thing I thought. Are using DB objects directly in the API interface? That is just bad architecture. You always abstract the interface objects. This is a contract. And it shouldn't change when you optimize the database.
100% agreed on NEVER sending the raw db objects back to the caller of the api. I like to create dedicated response models with Pydantic (ex. GetBlogsResponse). Then convert that response model to json (automatic in FastAPI ftw!) before returning the data to the caller.
I usually even have 2 or more DTOs for a DB entity, the basic one has a requestDto and a responseDto, that is the most basic structure, because you never share your entities structure publicly.
Would be interested in you talking about “database stuff” especially with how to interface with some different ones using python. Thanks again Arjan!
> "There is no standard way of doing [controlling the fields you get]".
Aside from the fact that REST isn't a protocol so "standard" is a hard thing to define here, there are many ways to overcome this issues, and all of them are standards in HTTP and pretty natural in REST design principles:
- HTTP cache on GET request; which is always useful
- Always return empty response on PUT/POST/DELETE request, with a location header if the resource modified is at a different location
- Use content negotiation (request's ACCEPT header and response's Content-Type header) to return smaller response
Most problem with "you can't control what you get" are coming from badly designed API and a lack of understanding of what HTTP has to offer. And also, most people don't know more than type-marshalling and think their internal datamodel is the same as the returned resources.
After working in graphql for a year after working in rest for a ~decade, I am not even slightly sold on using graphql. Ignores how HTTP response codes work, every api call is made to /graphql, etc. I don't see a ton of scenarios. for the overfetching/underfetching problem.
This is unfortunately NOT what REST is or should be. While plenty of people seem to have such an understanding of "REST", this is basically just citing what others understood incorrectly in the past and is more or less just wrong or incomplete at least. View REST as a collection of indirection mechanism that help to decouple clients from services. In a REST architecture it is the job of the service to teach a client everything it needs to know to make further requests. It provides URIs the client can use to retrieve new resource' states expressed by a negotiated document type. But instead of using those URIs directly i.e. to determine its use, URIs are usually attached to link-relation names which allows to swap URIs out when needed while still being able to lookup the URI through its link-relation name.
Media types are a major part of REST. Plain JSON does not provide a client any hint on that data, it doesn't even specify what a link is. Returning plain JSON is like returning a plain text document. Unless a client knows what type it received beforehand (which is already a hint on a tight coupling) it won't be able to make any sense of it. This ultimately leads to typed resources which REST does not have. Just read through what Fielding clarified on some of the common issues he has with people calling RPC-like services exposed over HTTP REST/ful: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven. Media types are nothing more than a human-readable description of what elements/components to expect within a document as well as the semantic description of what this field expresses and when it should be used. If a client is able to process such "documents" it is able to extract the data of it and it is then the job of the client developer to provide some mapping from the received representation payload to an object your application can work upon further. The media type de facto becomes the part both services and clients bind to. The contract if you will. This guarantees that messages/documents exchanged are always processable by the recipient if client and server could agree on a media type both support. In REST you could even have various media types the state of the resource could be expressed in and as such the more media types your client and server support, the more likely they become to interoperate with other services out of the box.
In regards to sending data to the service, a typical client interaction here should look like this: clients looks up the URI of an exposed "form" link relation and requests that representation. It will receive a form-based representation format that follows a well-defined document type that defines the respective parts of a form. That definition will specify that there will be a certain property responsible for defining the HTTP operation to use upon submitting the form, the media type to represent the data in upon sending as well as a target URL to send the data to. Besides that the respective components the form contains will lay out the structure of the properties the target resource has and that are expected by the server. There is no need to contact any other information than that to generate a request. This is HATEOAS applied. You use the hypermedia controls defined by the media type and utilized in the response to allow clients to progress their task further.
How a client is supposed to know what to do next is a bit out of scope here. Though as Jim Webber mentioned in his great talk back in 2011 ( ruclips.net/video/aQVSzMV8DWc/видео.html ) you should basically create a "domain application protocol", similar to how shopping cart and checkout are done on Amazon or elsewhere, where a client is following a predefined interaction protocol until either the task is complete or the task was aborted mid ways for some unknown reasons. This can be done by designing the whole interaction as part of a state-machine the client is following along until it completed its task.
Granted, all of those indirection mechanisms add up quite some complexity which are not needed if you are just interested in interacting with your mobile app clients that are fully under your control. REST should be used only if you want/need a service that has to run for decades and thus supports new stuff over time and/or if you have plenty of clients connecting to your services that are not under your control. While every peer in such a network should act on the same premises, if a client violates some of the requirements it is its own fault similar to how HTTP clients can not be made accountable if a server updates states on GET operations. If you don't need services to coop with change or don't need clients to be able to interoperate with other services except for yours, don't do REST.
yet another thing about new tech that annoys me: facebook thought they hava a problem so they create graphql. does your company have facebook level problems? definitely not. ... so many programmer choices are driven by shiny toys. makes me sick.
I CANT use my car because my way to work is solved in 5 minutes on foot? or I shouldnt use my Mustang oder Dodge to drive to work if it can be done in smaller like Twingo or Chiquichento?
After developing some applications that store many millions of records, I can say that REST API's are the only way to go. The security issues around REST are easy to manage if you enforce Swagger definitions of what endpoints expose, as accidental leakage of data can be picked up through exceptions with the approved Swagger data structure.
Also, GraphQL has huge performance issues, where you can't fine tune heavily indexed database queries to speed the query like you can with REST. With REST, you know how the data will be structured, so targeted database indexes can improve query performance from 10x to 200x faster.
GraphQL may be good for small exploratory queries, but when writing a full stack application, you know exactly how the API's will be called, because you wrote the front end, so again, REST API's stand out as the preferred solution for a full stack application, or an application that consumes the APIs in a predictable way.
I would only implement GraphQL if it was necessary to have a 'Supports GraphQL' marketing line on the product home page, otherwise, for me, it is a cool but inferior technology.
There are many ways to solve the 'many API calls for REST endpoints' issue. The key with REST API's is, 'It's important to understand the intent of REST API's, so that you can break those rules in a consistent manner'.
And yes, it's almost always necessary to break the hardline REST API rules for endpoints to get an application of even medium complexity to operate at speed.
@David Thomas Agree 100%... Also, it seems there's too much boilerplate code with GraphQL. After years of developing REST servers I've made my own set of libraries and servers that can work with any data model and provide most of the features that GraphQL does, and works well with million documents sized databases
Doesn’t literally Facebook use graphQL? You sound a little too sure that rest>graphql
@@BuyHighSellLo Absolutely, they have quite a lot more resources to optimize the delivery of their graphql tech too. GraphQL is fine for adhoc queries that don't see a lot of use, and as you can imagine, the high level of chatter between the GraphQL server and the database layer is a sub-optimal way to expand on queries. By far the fastest way to get data out of a database, in a predictable pattern, is to retrieve data with hard coded SQL(or whatever db language you use) queries, that are backed by intense performance testing, leverage database queries, and get all the data in a single db query.
If Facebook is having amazing performance with GraphQL, it makes me think they are writing optimised queries that are triggered when specific shape GraphQL queries come in, and not using a generic GraphQL query engine that isn't able to properly leverage a single db query that triggers associated indexes.
When you see the light and implement an optimised DB query to get data in a known shape, then you end up exposing that query via REST, hence, in the vast majority of cases for larger applications, REST >GraphQL, by far
@@warpmonkey great insight. Thanks!
@@warpmonkey The issue here is that you're assuming you _can_ provide data in a known shape. GraphQL is designed for the opposite of that, when you don't know the shape. At my last company we used GraphQL to great success because it was a tiny startup with a massive data model, the frontend was evolving constantly, and backend needing to manage a brand new api endpoint every day is infeasible. Graphql provides a great solution.
The biggest issue with your response is that you assume that a company has to be huge in order to optimize their performance with GraphQL, but not huge in order to do so with their db queries. In general, I don't know _any_ business developer that spends time optimizing db queries unless they get incredibly out of hand. That time is better spent actually delivering business value, which GraphQL allows you to do.
Is graphql a good solution for everything? Absolutely not. I think it was good for that use case though. I just think a lot of the arguments in this thread are incredibly dismissive of the actual power of the tech. Just like anything, it depends.
One thing that is very difficult with graphql is security. But, you balance the difficulty managing that vs the fact that you no longer need to manage frontend apis for however many UIs you have. Hint: at my last company it saved the backend over 40+ manhours a week just in new api calls.
REST + ODATA is really powerful and perfectly exposes data layer as API.
Yeah it was... 15 years ago... 🤣
@@dustinwilliams448 so what? http is 30 years old :)
@@a-rezhko sorry but you're incorrect.. HTTP has been replaced 3 times.. Google wrote spdy which became v2, the v3 gave us QUIC, v4 was drafted in 2020. So the current live version is only 7 years old and the latest is not even 2.
OData was always niche and now its in rapid decline as companies EOL legacy apps.. you might as well be advocating for VT100, sure it's still out there but it's a dead end..building anything new on it means apps are obsolete on launch.
Odata also perfectly exposes unsolved issues known for years 😁
Graph QL if you dont have enough work and want to look busy
REST if you dont have enough time for how busy you are
A big downside of GraphQL is that it breaks caching. This makes it unsuitable for external API's.
All the stuff he mention about rest is all stuff much easier to implement in rest and much harder in hql
How to write 1000 lines to replace 1 in rest and call it better
Software development would be so much better if everyone worked together and stopped re-inventing the wheel. It makes open source bloated, confusing and overwhelming.
Clearly you haven't tried Wheel XI.1 Lollipop Leapord. They introduced an SDK for 3rd party plugin extensions, allowing for custom Roll interactions via subscription-based centripetal force engines and freemium features that allow affiliates to monetize their Rotate physics services through distributed blockchain transactions. All with extensive Analytics dashboards! Throw out your legacy wheel tooling, you won't need it. Also it won't be compatible.
stop worrying and just use Clojure
@@Simon-xi8tb Agreed! Clojure does not need to out-compete every other language out there to be successful. It just needs a community that’s big enough to make it sustainable in the web development space.
There are plenty of people actively using Clojure for work, and the ecosystem is very robust. In short, I don’t think Clojure is in danger of going anywhere in the foreseeable future.
Now let's see how many can make Clojure a standard and all agree to use it without re-inventing the wheel and confusing the open source space of options even more.
See my point?
@@ed-ou812 You would have a point if Clojure was re-inventing , but it does a lot more inventing than re-inventing.
@@Simon-xi8tb just one more tool in the toolbox. There will be another 5 next week. All saying they have advantages over it. Maybe you can convince them to not re-invent Clojure. That was my point. Open source needs better teamwork across the spectrum. Not just for one tool for a short time. Build upon the tool and keep it going. Yes and a language is a tool.
Great video Arjan! Concepts were explained very clearly with nice examples! I would also love to see a video on FastAPI!
Great video. I have the opposite conclusion. I think GraphQL works for small needs, but handcuffs you at scale. REST has more things to worry about initially, but you can control them in the end game when the requirements get nuanced and intertwined. We did extensive analysis of both for a major application, and went with REST over GraphQL precisely for the ability to maintain control at scale.
Could you elaborate more on graphql at scale problem? We are trying to pick graphql for our app.
If it is an mobile app, better don’t go for graphQL.
Users hate frequently app updates just for fixing bugs.
majority of business logic should stay in server and app just handle displaying.
@@alvin3171997 Look up "N + 1" with graphql and you'll find one aspect. The other is just the general lock-in of any library that takes over for you. It's easy at the start, but corners you in the end. It's not run time scalablity, as much as development time scalability--the ability of the developer to do advanced things toward the end of the effort.
@@alvin3171997 To elaborate a bit more on one thing. Suppose all the variables you need are not at rest, but must be calcualted at run time based on inputs. In REST, this is trivial. In GraphQL, becuse the libraries (including ORM) have taken over for you, it's hard.
Just for information - there is a bit abandoned evolution of classic rest called json:api. It has many interesting conventions for handling complex and dependent resources. I dont like graphql because of its unpredictable execution pipeline. I found a lot of similar concepts in json:api and it is a bit comfortable for me to handle
GraphQL is great for 22 year old CTOs who say things like "Mongo just scales better" unironically.
Still the worst thing about using QraphQL in Python is that you have to write "strings" or dicts which completely eliminatas the advantage of syntax highlight, intelli sense and other IDE features. I love Python but if I'm to work with GraphQL project I'd chose TypeScript any day.
I was actually kind of surprised he used this library. The Strawberry library works with dataclasses, which I found to be much more convenient.
Great video as always! I haven't had a chance to look into GraphQL yet, so I found the summary and comparison with REST here to be quite informative.
Glad you enjoyed it!
An excellent video tutorial as usual. Now, with a Flask/GraphQL/Ariadne backend, the question becomes, how to design and implement the front end, that will actually fire off the GraphQL queries and display, or otherwise handle, the results. As well as minimising database queries from the backend to the GraphQL server, requests to the backend from the frontend could also be reduced by smart caching of some kind.
There is a mistake in GQL Schema:
1. Never use [Type], because it means nullable array of nullable items of type T. The allowed values for this includes: null, [], [null] and [null, null] and so on.
Use [Type!]! -- it includes an empty list bust the null for value and items is disallowed
2. Never use Type! as return type in queries if you are not sure that the corresponding value exists.
blog(blogId: ID!): Blog -- returns Blog or null if blog couldn't be found by id
3. Never use GraphQL errors to pass business logic errors -- just because there is no way to describe the errors with the GraphQL schema.
Stating that Swagger sets "the standard" is at best propaganda and at worst misinformation. Swagger does not set the standard for REST protocols over HTTP. REST and HTTP Actions are SEPARATE ideas that have never worked very well in practice for anything beyond toy projects. In any project with dependencies, REST implementations are always dealing with exceptions and workarounds (which are all pointing to RPC) that make it obvious that REST is a failed approach. It's better than inheritance, because the ideas aren't coupled to bad design, but are poor targets for overall architecture. If you have an analytics system you'll be using an RPC API over GraphQL and any system less complex will be just fine with an RPC API without wasting effort on these terminal REST projects.
I'm not familiar with graphql at all, FaceTime this video, it feels like writing manual definition of data classes before the dataclass module. It makes you write more disciplined code, but inflexibility leads to limitation like the n+1 problem. Also, if the rest interface was created with fast API, lots of the testing issues go away because swagger docs are free in fast API.
So graphql just seems like an expensive way of shifting API design further downstream
For newbies: newer return all blogs, always return paged data
Explain why these docstring-like typedefs aren't a ten-day-old fish code smell.
If you use ODATA for REST you typically wouldn't need to make separate calls to get related objects. e.g Author details of the Blog post. It has a keyword named "EXPAND" that your specify in the api call to do this.
9:16 regarding sending the data directly from the database using REST. I think that always we should use DTO and never expose our db entities. Entity should be isolated from client requests.
In my experience, GraphQL is fantastic for the backend for frontend layer - just being able to request what you need is the largest selling point. There are other huge benefits: self documenting, type generation, great deprecation patterns, parallel queries, etc. The biggest issue I’ve seen in the field is that consumers aren’t willing to put in the work to understand how to use GraphQL and they end up treating it as a RESTful API and typically grab wayyyy more data than they need. Or worse, they over utilize the recursive nature of GraphQL rather than using dedicated queries to fetch the specific data they need.
what about read speed of repeated, simple queries? also what about hosting scalability relative to something like postgres?
I enjoyed this breakdown. My personal experience with GraphQL has me putting it in the bin, probably permanently. The N+1 problem and subsequent design limitations have been such a gigantic issue that I would sooner code my own custom batch endpoint than use graphql. It is a nice idea though, I am sure it works very well for lots of applications that don't come up so hard against the limitations.
9:24 WTF so where should I store passwords if not in the database?
gPRC > REST > GraphQL. No nuance necessary 😜
Great intro! We should all strive to be more nuanced and empathic to alternatives.
RPC -> REST -> GRAPHQL -> ??? What's next ?
This was an excellent explanation of the difference between GraphQL and REST, very nice, Thank you!
Glad you enjoyed it!
Quite complicated as my first exposure to this…
thanks for the video! informative and entertaining as always! i'm not a friend of mixing different syntaxes... syntices (?)... in the same file. off the top of your head, do you know of any graphql libraries for python where you can define the graphql type definitions separately? i guess reading from a file always works 🤔
where do you save passwords (hashes) if not in the database?
You know he knows what he's talking about because people who use Vim usually do.
I guess that's one way to look at it? Ahah
Have you tried hypermedia with htmx?
where do you store passwords then? 9:24.5
so with graphql you have to predefine queries... EXACTLY as you have to do with rest. acting like rest necessarily and literally means mapping table to api is just ... idiotic.
want fast "rest" development? use rails.
In GraphQT, can you return Author name on the same level as Blog ID? Like {"data": {"blogs": [ {"id": "1", "authorId": "1", "authorName": "Author 1"} ] } }
Ah, what is flask?
RPC?
More videos like this please! I would also enjoy if you talked more about different types of databases and how to interact with them in Python :)
Actually it is 255 shades of gray 💩☺️
I thought the same but the values 0 and 255 are black and white, the shades of grey are actually the values from 1 to 254. Pretty deep joke !
You got it Ryad ;).
Love to see how much the channel as grown! You da man Arjan
Thank you Jake, glad you liked the video!
I was just thinking, well shouldn't it be 256 shades of gray then I realized how amateur I was of course you have to subtract 0 and 255 as they are black and white.
this is a bit lopsided on the rest side, as it shows a barely correct example of using POST to update an existing resource, and the issues with security are not specific to rest here either, and like using ariadne for graphql, you would just use a rest framework for rest, having usually the same amount of predefined utilities, that allow you to create data serialization and deserialization, validation etc.
so it becomes more a question of predefined architecture: ariadne forces you to connect to some architecture, but while rest apis often have shortcut pass through solutions, it really also depends on how you layer it - and there rest apis can also already have predefined "ways" to do. in a way, rest is simply more "bare bones", while graphql is specifcly created to host an api, that has a strong independent app mindset.
it is easy to create a rest endpoint that returns some custom dataset, or to govern how much data each request really gets, making rest usually a backend heavy development type, and usually, with the need to have apps, that are quick, and specialize in making the user happy, having the query decisions on the backend is often simply the more controllable, easier to finetune situation, if you don't run a platform which operates a large amount of independent and often thirdparty app logic.
So either you define a ton of endpoints or you build complexity with graphql. I wonder if there is an equivalent for swagger for graphql
The odd IDE errors and brushing over some important points were distracting me a lot but overall the main content here was great. Thank you Arjan!
your code is so beautiful
Is GraphQL supports media types?
We want to fetch and show video using graphQL which is in react application with Apollo client.
It always depends! 🤣
what about documentation, like OpenApi docs? I just dont see how graphql would do this, is there a common way?
In part, the GraphQL schema is the documentation (and you can view it in the playground most GraphQL libraries offer). You can add comments to a GraphQL schema which will then be included in the documentation. Here's an example of a GraphQL library that uses this: dgraph.io/docs/graphql/schema/documentation/ (I haven't used this library myself, it's merely intended to show how documentation is handled).
@@ArjanCodes hehehe, is this a joke - or just coincidence? the link is down / doesnt exist
Just found your channel and I just know it's uphill from here for me. Thank you ArjanCodes! 💖
how can i get all tables in graphQL like in SQL SELECT * FROM * ??
You should try Postgraphile, it's not perfect but it resolves some of your concerns...
One of the biggest challenges for me with graphql (and to a lesser extent with REST) is how to return errors to the client. The "happy flow" is standardized very nicely I think, but "unhappy flow" is all over the place. Would be curious to hear your take on that.
Have your API throw an error and return a standardized error message with a relevant HTTP Error Code?
@@mymawazo1449 That would be one way of handling it, but by default most GraphQL packages use the HTTP 200 status code regardless of whether an error was returned or not. This is because you can query / mutate several fields in one query, some of which may be successful and some of which may return an error.
When part of the data is queried succesfully, you might want to show that data to the client, while handling the errored out data in some other way. Also errors have no typing by default in the graphQL packages I've worked with in contrast to the data. How do you handle this when using typescript for example? So in short, yes you could just modify your package to throw a status 400, I've done that in one project, but it's not a very elegant solution. That's why I'm asking for Arjan's take
Easiest would be to check length returned error array and treat it as a failed response if its gt 0. Any controlled throws at server is caught that way. Connection errors is upto client and or client library to handle in choosen way. If you want to be able to use partial results its a bit more work though.
Hi Arjan, you make great videos😀 . I like do build some bigger Applikation with a UI (PyQt, Tkinter, WX) but i have some trouble how i can build it with a MVC-Concept. I always get a big mess in the controller part. Do you have some hints? Maybe this is a idea for another great video .😅
I was already subscribed, but when you said that you are nuanced people, I hit the bell button. Great video!
I sometimes find it tiring to test complex graphql queries that’s my only gripe with graphql
You can return related data in one request in API using data serializers
wasnt graphql involved with nvidias big leak?
This is only 5 times easier to code in Python than with Java Spring
Plz do a video on python debugging techniques in vscode
Arjan, do you have in mind a video about sparql and rdflib for python? That would litterally save me 😆😆
Why not both?
255 shades of grey
I do not know much about graphQL but isn't a API that allows the consumer to define the returned fields much more insecure than a REST API that only defines endpoints with data, the developer want to send to the consumer?
Until now I only use REST APIs and I always define the data types for a specific end point in my backend (in my case .net Core 6)
Your schema is the "data types". The graphql schema defines what fields they are able to ask for as a caller. You can also very easily provide field level permissions since graphql somewhat native supports custom decorators (field level resolvers also help)
I like OData
gRPC!!!
Is that an xor? Use both; each where it makes sense.
I'd go with JSONPure
What can you say about FAST API?
@ArjanCodes You look more comfortable and confident in your videos! you'll go 100K subscriber in no time
Thanks! Let's hope so! :)
Oh yes, glad I'm here early. The content is indeed a bit advanced and that's good.
no one is paying attention to JSONRPC
Great video! Would love to see a video on comparing the common GraphQL libraries
Love that you are using copilot!
Your first two and a half minutes on "what is rest" put explicitly what tons of reading never provided me
Glad to hear it helped!
25:56 what you are looking for
When I used the api I had created for the frontend devs at our, I realized how difficult it is to use. I focused so much on the data structure and forgot about usability. I was considering migrating at least certain parts of the api to GraphQL and this video really helped me understand it. This video has helped me understand which parts are better left as REST.
I think you can have both!
at ruclips.net/video/7ccdWqGgHaM/видео.html you mention 'don't store passwords in the database' - where are you supposed to store passwords? Just to generalize a bit, looking at web development security, it's difficult to find easily digestible information. Maybe it would be interesting to do some videos showing real life exploits, as a suggestion. Thanks for your work!
I think in this case it means "don't store plaintext passwords in your database". There's a series of transformations that you should apply to the passwords before saving them on your database, so that they can't be retrieved in case there's a database breach
When user creates account, accept plaintext password in the request, then use an "industry standard" hashing function like bcrypt to create a hashed password string. Store only this hashed string in the database. When the user signs in, accept the plaintext password in the request, hash it again using the same hashing function, check if the recently hashed string matches the hashed string stored in the database for that user.
Fastapi graphql is better
Only 254 shades of grey? Ah, right, because we're zero indexed and of course the final shade is reserved for the dirty bit. 😎
No, in 8 bits, there can be 256 total shades
example: 0,0,0 1,1,1 2,2,2 ..... 255,255,255
where 0 is black and 255 is white, remaining 254 are gray shades,
@rdean150
@@rajveersingh2056 That whooshing sound is the joke flying overhead
Great content, can't wait for more!
Thanks!
Thank you Ivan!
Really? Wrapping is the answer? Maybe good for pretenders
What would be a good alternative in your opinion?
@@ArjanCodes Data without logic is noise
I love you man, heart my comment please!
Thanks and happy to oblige ;).
254 shades?! Don't you mean 256? D-:
I don't count black and white as shades of grey ;).
@@ArjanCodes I was kind of thinking that, but since screens will never be able to display pure black, and a brighter light will always be "whiter", I would count both as gray. LOL philosophical binary claptrap. :-P
thanks
gRPC!
Great video. Thanks
You’re welcome, happy you enjoyed it!
Excellent content! Thanks
Glad you liked it, Wilhelm!
Now I wanna try coding a GraphQL API to figure out how it works! However, I feel like there are some great frameworks that make creating REST APIs much easier (Django Rest Framework for example).
There are surely frameworks better suited for REST APIs. Haven't played around with Django REST, but it sounds interesting!
dunno, everything in python looks so "javascript" style, so a bit messy and without an high level structure/syntax to follow
anyway, amazing video Arjan as always!
Thanks! After playing around with Flask and a couple of the GraphQL libraries, I must admit I prefer backend development with NodeJS and Typescript. To me that feels much easier to use.
Opinionated -language- programmer
If you like type, you can annotate your python code and statically check it with mypy, you can also check type at runtime thanks to pydantic.
we are currently making this exact decision in our company. i really appreciate ur opinion, u r clearly very experienced
What about graphql subscriptions? Using sse or ws with the same api for real-time stuff is pretty cool