4 ms·

IMHO, Rest works just fine. If you are serious about performance I don't really get how you do that with GQL. maybe I'm just ignorant but the apps I've worked o

by x86x87 3y ago

IMHO, Rest works just fine. If you are serious about performance I don't really get how you do that with GQL. maybe I'm just ignorant but the apps I've worked on were medium to large size and it was a fricking nightmare (apollo-based, a couple of years back). Here: https://hackerone.com/hacktivity?querystring=graphql&filter=type:public&order_direction=DESC&order_field=latest_disclosable_activity_at&followed_only=false&collaboration_only=false https://hackerone.com/hacktivity?querystring=graphql&filter=...

valenterry 3y ago
I think it's simple. You can get the best performance with REST, but you have to really put lots of resources into it. On the other hand, with constraint resources, you likely end up with better performance when using graphql because of the reduction of requests and decreased latency. In most cases, graphql hits the sweet spot.
- victor106 3y ago
  > reduction of requests and decreased latency. How? GQL still depends on an API or a database, isn’t it? And depending on where that Api or DB is located in relation to the calling user/app latency is still going to be the same? What am I missing here? If you are implying that GQL somehow intelligently caches data, then all the issues with cache invalidation etc still would apply, correct? The problem with some of these debates about GQL vs Rest us that you have people either saying GQL is great or bad and same with REST. I wish there is someone that breaks it down and truly explains the pros and cons of each.
  - devjab 3y ago
    I think that it might be because the difference is mostly in how we work together. With GQL your frontend and backend engineers are always happy, with Rest they are always at each others throats to deliver. This is because GQL gives your teams the tools they want. On the frontend you get the data access without ever having to talk with your backend, on the backend you get the load data without ever having to talk with your frontend. So both your frontend and your backend can focus on what they do best without ever talking with eachother. Obviously that's not exactly how it works, but if you give your frontend engineers the full query abilities of GQL and your backend the ability to monitor and then fix bottlenecks through the GQL load tools you simply remove a lot of the conflict zones in modern development. You can do everything you can with GQL with Rest, but you're not going to want to do it. And speaking from experience, you're not going to want to do it with Odata either unless Microsoft magically improves the experience after 10 years of it sucking.
    - andrewprock 3y ago
      [flagged]
  - valenterry 3y ago
    You are right, but you are missing the frontend part. e.g. frontend says "backend, give me the users". Then later, for every user it says "backend, given me the users favourite images". However, with graphql the frontend can say "backend, give me the users and include each favourites images". Even if the way to retrieve it from the database is the same for the backend, there is still reduced latency because it is only frontend->backend->db (users)->backend->db (images)->backend->frontend instead of frontend->backend->db (users)->backend->frontend->backend->db (images)->backend->frontend
devjab 3y ago
> maybe I'm just ignorant Never that, but maybe inexperienced? Nothing you say is wrong, but you need to look at it from the organizational point of view. The way we build (most, all of them where I work, but I'm sure people can point to places) "enterprise" apps today, is that we have a frontend that's build in Typescript, and then something behind it to move the data. Your frontend engineers are going to want a query language that allows them to pick and chose the data they need. You can do that with rest, but you really, really, don't want to build it yourself. Some frameworks have options for parts of it, but in general you're out of luck when it comes to things like inheritance trees on objects. So you have Odata, RPC, GraphQL, and while Odata is nice on the client side, it's not nice on the server side. RPC's work great, but they are also a lot of work, and then you have GraphQL. What GraphQL allows you to do is the combination of having an engine that makes your frontend engineers happy, while allowing your backend engineers a lot of visibility on resource drains. This means that you can work on the heavy load areas, and "leave" the others, more easily than you can with Rest where you're likely going to "over engineer" a lot of your backend. RPC is sort of like Rest in that department, but because it's intended to be like that, its rarely an issue because you chose it for that reason. Or to put it more simply. You use Odata and GraphQL and not Rest because they lessen the "working together" burden.

by x86x87 3y ago

valenterry 3y ago

I think it's simple. You can get the best performance with REST, but you have to really put lots of resources into it. On the other hand, with constraint resources, you likely end up with better performance when using graphql because of the reduction of requests and decreased latency. In most cases, graphql hits the sweet spot.

victor106 3y ago
> reduction of requests and decreased latency. How? GQL still depends on an API or a database, isn’t it? And depending on where that Api or DB is located in relation to the calling user/app latency is still going to be the same? What am I missing here? If you are implying that GQL somehow intelligently caches data, then all the issues with cache invalidation etc still would apply, correct? The problem with some of these debates about GQL vs Rest us that you have people either saying GQL is great or bad and same with REST. I wish there is someone that breaks it down and truly explains the pros and cons of each.
- devjab 3y ago
  I think that it might be because the difference is mostly in how we work together. With GQL your frontend and backend engineers are always happy, with Rest they are always at each others throats to deliver. This is because GQL gives your teams the tools they want. On the frontend you get the data access without ever having to talk with your backend, on the backend you get the load data without ever having to talk with your frontend. So both your frontend and your backend can focus on what they do best without ever talking with eachother. Obviously that's not exactly how it works, but if you give your frontend engineers the full query abilities of GQL and your backend the ability to monitor and then fix bottlenecks through the GQL load tools you simply remove a lot of the conflict zones in modern development. You can do everything you can with GQL with Rest, but you're not going to want to do it. And speaking from experience, you're not going to want to do it with Odata either unless Microsoft magically improves the experience after 10 years of it sucking.
  - andrewprock 3y ago
    [flagged]
- valenterry 3y ago
  You are right, but you are missing the frontend part. e.g. frontend says "backend, give me the users". Then later, for every user it says "backend, given me the users favourite images". However, with graphql the frontend can say "backend, give me the users and include each favourites images". Even if the way to retrieve it from the database is the same for the backend, there is still reduced latency because it is only frontend->backend->db (users)->backend->db (images)->backend->frontend instead of frontend->backend->db (users)->backend->frontend->backend->db (images)->backend->frontend

devjab 3y ago

> maybe I'm just ignorant Never that, but maybe inexperienced? Nothing you say is wrong, but you need to look at it from the organizational point of view. The way we build (most, all of them where I work, but I'm sure people can point to places) "enterprise" apps today, is that we have a frontend that's build in Typescript, and then something behind it to move the data. Your frontend engineers are going to want a query language that allows them to pick and chose the data they need. You can do that with rest, but you really, really, don't want to build it yourself. Some frameworks have options for parts of it, but in general you're out of luck when it comes to things like inheritance trees on objects. So you have Odata, RPC, GraphQL, and while Odata is nice on the client side, it's not nice on the server side. RPC's work great, but they are also a lot of work, and then you have GraphQL. What GraphQL allows you to do is the combination of having an engine that makes your frontend engineers happy, while allowing your backend engineers a lot of visibility on resource drains. This means that you can work on the heavy load areas, and "leave" the others, more easily than you can with Rest where you're likely going to "over engineer" a lot of your backend. RPC is sort of like Rest in that department, but because it's intended to be like that, its rarely an issue because you chose it for that reason. Or to put it more simply. You use Odata and GraphQL and not Rest because they lessen the "working together" burden.