5 ms·

Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend w

by pyr0hu 2y ago

Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend with simple permission handling and haven't run into anything yet, but I wanna know what could await me

joshstrange 2y ago
With REST I can fairly easily filter out any data based on roles/permissions either at query time or before turning it into JSON. With GraphQL I need that info deep in the resolver logic and for nested data I don't want to fetch the name of a person if they calling user doesn't even have access to see that user (and I don't want to fetch the user and their name only to delete it from the response later). GraphQL, being so open-ended to what you are fetching, means I have to make sure to plug a ton of holes whereas REST I have a specific query, there is no way to fetch nested data (unless I specifically allow it via GET/POST params). I can easily say "If role X -> use this query, if role Y -> use this query, etc", I found that very difficult to do in GraphQL. GraphQL feels like magic when you first start with it (which should be a red flag) but once you need to support more roles or sets of permissions and as your business logic starts to creep in things go haywire. In my experience things that are easy up front are unmanageable once business logic gets added in. For straight CRUD it's amazing but very rarely do our apps stay as just CRUD and that's when things fall down. For example, on create of a new user I need to send a welcome email. It's been 5 years since I was working on that GraphQL project but I have no clue how we'd handle that. I'm sure there is some kind of a event system we could hook into but with REST I just have a simple endpoint that saves the data to the DB and then sends and email (or puts it in a queue), way easier than in GraphQL. Again, fetching and updating data is easy until you need to handle edge cases. I have the same feelings about Firebase and friends. Feels like magic at the start but falls down quick and/or becomes way too complicated. GraphQL feels like DRY run amuck, "I have to keep writing CRUD, let me abstract that away", ok but now if you need special logic for certain use-cases you have a mess on your hands. Maybe GraphQL has ways to solve it but I'll bet my hat that it's overly complicated and hard to follow, like most of GraphQL once you get past the surface. I'd love to see a "Pet Store" (I think that's the common example I've seen demo'd in REST/Swagger/GraphQL/etc) example with heavy restrictions based on different users/roles. It's like using the "Todo app" example in a framework, sure that works and is straight forward, I want to see how you handle the hard stuff and if it's still easy.
- RedShift1 2y ago
  > with REST I just have a simple endpoint that saves the data to the DB and then sends and email (or puts it in a queue) With GraphQL you can just do the exact same thing? I do this all the time. I don't understand how you wouldn't be able to do that.
hamandcheese 2y ago
Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something. A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no additional permission checking when fetching the orders connection. Now, suppose 6 months pass. Some other engineer is now implementing reviews. Each review must have an author. What do ya know, there's already a user object available in Graphql. How convenient! Now every user can inspect all orders of every other user, if that user has left a review. Mistakes like this are all too easy with graphql, and is the number one reason I would never consider using graphql without a query whitelist.
- RedShift1 2y ago
  So GraphQL is bad because you didn't implement authorization, which you should have been doing regardless of the API technology you use?
  - hamandcheese 2y ago
    I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API. In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default. In a typical REST application, it is enough to ask "does this user have permission to take this action". In graphql, the question is rather different. It is "does this user have permission to access this data irrespective of the action they are taking", and you have to both ask that question and answer it correctly for everything in your graph.
    - randomdata 2y ago
      If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer. In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started using it as a poor man's SQL, but that's not really what it is for.

by pyr0hu 2y ago

joshstrange 2y ago

With REST I can fairly easily filter out any data based on roles/permissions either at query time or before turning it into JSON. With GraphQL I need that info deep in the resolver logic and for nested data I don't want to fetch the name of a person if they calling user doesn't even have access to see that user (and I don't want to fetch the user and their name only to delete it from the response later). GraphQL, being so open-ended to what you are fetching, means I have to make sure to plug a ton of holes whereas REST I have a specific query, there is no way to fetch nested data (unless I specifically allow it via GET/POST params). I can easily say "If role X -> use this query, if role Y -> use this query, etc", I found that very difficult to do in GraphQL. GraphQL feels like magic when you first start with it (which should be a red flag) but once you need to support more roles or sets of permissions and as your business logic starts to creep in things go haywire. In my experience things that are easy up front are unmanageable once business logic gets added in. For straight CRUD it's amazing but very rarely do our apps stay as just CRUD and that's when things fall down. For example, on create of a new user I need to send a welcome email. It's been 5 years since I was working on that GraphQL project but I have no clue how we'd handle that. I'm sure there is some kind of a event system we could hook into but with REST I just have a simple endpoint that saves the data to the DB and then sends and email (or puts it in a queue), way easier than in GraphQL. Again, fetching and updating data is easy until you need to handle edge cases. I have the same feelings about Firebase and friends. Feels like magic at the start but falls down quick and/or becomes way too complicated. GraphQL feels like DRY run amuck, "I have to keep writing CRUD, let me abstract that away", ok but now if you need special logic for certain use-cases you have a mess on your hands. Maybe GraphQL has ways to solve it but I'll bet my hat that it's overly complicated and hard to follow, like most of GraphQL once you get past the surface. I'd love to see a "Pet Store" (I think that's the common example I've seen demo'd in REST/Swagger/GraphQL/etc) example with heavy restrictions based on different users/roles. It's like using the "Todo app" example in a framework, sure that works and is straight forward, I want to see how you handle the hard stuff and if it's still easy.

RedShift1 2y ago
> with REST I just have a simple endpoint that saves the data to the DB and then sends and email (or puts it in a queue) With GraphQL you can just do the exact same thing? I do this all the time. I don't understand how you wouldn't be able to do that.

hamandcheese 2y ago

Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something. A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no additional permission checking when fetching the orders connection. Now, suppose 6 months pass. Some other engineer is now implementing reviews. Each review must have an author. What do ya know, there's already a user object available in Graphql. How convenient! Now every user can inspect all orders of every other user, if that user has left a review. Mistakes like this are all too easy with graphql, and is the number one reason I would never consider using graphql without a query whitelist.

RedShift1 2y ago
So GraphQL is bad because you didn't implement authorization, which you should have been doing regardless of the API technology you use?
- hamandcheese 2y ago
  I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API. In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default. In a typical REST application, it is enough to ask "does this user have permission to take this action". In graphql, the question is rather different. It is "does this user have permission to access this data irrespective of the action they are taking", and you have to both ask that question and answer it correctly for everything in your graph.
  - randomdata 2y ago
    If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer. In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started using it as a poor man's SQL, but that's not really what it is for.