3 ms·

No. It contains only a subset of the rest routes and allows to combine them efficiently. That is what avoids the explosion. You don't have to add any new "rest

No. It contains only a subset of the rest routes and allows to combine them efficiently. That is what avoids the explosion. You don't have to add any new "rest route" equivalent in graphQL if some user just wants a new combination of data but doesn't want to make 10 requests to get it.

GordonS 6y ago
That's the theory. But I've only seen it work in practice if there is a single backend data source, and that data source is a database. In which case, we've been able to achieve similar results using OData for several years. Often in reality, you end up with specialised GraphQL queries for performance reasons, because they are reading and combining data from a plethora of backend data sources - cloud-based APIs, on-premise APIs, external APIs, databases...
- valenterry 6y ago
  That's the theory and it can very well be practice. It has worked very well for the teams where I used it or have seen it being used. And I'm talking about a service that provides an API to a frontend (or other backend services) and aggregating data from multiple datasources of different kinds into one graphQL API. > Often in reality, you end up with specialised GraphQL queries for performance reasons Ah, is that so? And with REST you don't? You seem to have _a lot_ of experience with GraphQL. I wonder why your previous post has the form of a question. Or was that just a sneaky way of giving your opinion without backing it up?
  - GordonS 6y ago
    > Ah, is that so? And with REST you don't? No, that's exactly what you end up with using REST; I'm pointing out that, at least with deployments I've seen, GraphQL ends up with the same problems, only hidden behind a single URL. > You seem to have _a lot_ of experience with GraphQL I didn't (and wouldn't) say that I have a lot of experience with GraphQL (I have far more with REST/HTTP-based APIs), but I've seen it used enough times to know it's not a panacea, and doesn't always solve the expected problems, especially when it's fronting dozens of (sometimes painfully slow) backend data sources. > I wonder why your previous post has the form of a question It doesn't? I was proffering an opinion, based on my observations when GraphQL is fronting many data sources. > Or was that just a sneaky way of giving your opinion without backing it up? I would politely and respectfully point you towards HN's comment guidelines[0] [0] https://news.ycombinator.com/newsguidelines.html#comments https://news.ycombinator.com/newsguidelines.html#comments
    - valenterry 6y ago
      > I'm pointing out that, at least with deployments I've seen, GraphQL ends up with the same problems, only hidden behind a single URL. Cool, let me give you a mini example, you'll immediately understand it. Two endpoints: 1. users, which contain video-ids and can efficiently be queried by user-id (index in database) 2. videos, which contain video data can efficiently be queried by video-id (index in database) How do I get all uploads of a user? I get the user by id (request 1) then all his videos by making one request per video (n requests). No big problem for the database (it's all indexed) and sure, we can improve the performance, but for now the bottleneck here is the number of requests that goes over the network if we use REST. This doesn't work. You need to make a new endpoint or change an endpoint to make this work in a performant way. In GraphQL we have one endpoint with two different queries. So the same problem can happen if someone queries naively. But, they can also write one nested query that says "give me user for id X and for each video id, give me the video data". It will be one request from frontend to backend, but still multiple selects to the database, unless we use some "smart" GraphQL framework that does magic for us. But we already solved a big part of the problem. And maybe that is already performant enough for what we need and we don't have the need to improve the database query part. Lot's of time and code saved on the backend and frontend. Yay. You might say "but we didn't have indexes". Then my answer is: well, you are not worse off with GraphQL and still gain the benefits for all the cases where you have indexes in place. If you have non of these, you seem to be doing something wrong. > It doesn't? I was proffering an opinion, based on my observations when GraphQL is fronting many data sources. Yeah, seems you edited your post. When I read it, there was 100% a question-mark in it. ;)
      - KronisLV 6y ago
        > How do I get all uploads of a user? I get the user by id (request 1) then all his videos by making one request per video (n requests). No big problem for the database (it's all indexed) and sure, we can improve the performance, but for now the bottleneck here is the number of requests that goes over the network if we use REST. This doesn't work. You need to make a new endpoint or change an endpoint to make this work in a performant way. The answer to this problem is resource expansion. Dylan Beattie actually has a nice and somewhat humorous presentation about how to address this with REST interfaces: https://youtu.be/g8E1B7rTZBI https://youtu.be/g8E1B7rTZBI Here's the part that addresses such data access in particular with a social media site example (people who have photos, which have comments etc.): https://youtu.be/g8E1B7rTZBI?t=1807 https://youtu.be/g8E1B7rTZBI?t=1807 Sadly, approaches like that and even HATEOAS are not awfully widespread, mostly because of the added complexity and the support by frameworks simply not being quite there.

GordonS 6y ago

That's the theory. But I've only seen it work in practice if there is a single backend data source, and that data source is a database. In which case, we've been able to achieve similar results using OData for several years. Often in reality, you end up with specialised GraphQL queries for performance reasons, because they are reading and combining data from a plethora of backend data sources - cloud-based APIs, on-premise APIs, external APIs, databases...

valenterry 6y ago
That's the theory and it can very well be practice. It has worked very well for the teams where I used it or have seen it being used. And I'm talking about a service that provides an API to a frontend (or other backend services) and aggregating data from multiple datasources of different kinds into one graphQL API. > Often in reality, you end up with specialised GraphQL queries for performance reasons Ah, is that so? And with REST you don't? You seem to have _a lot_ of experience with GraphQL. I wonder why your previous post has the form of a question. Or was that just a sneaky way of giving your opinion without backing it up?
- GordonS 6y ago
  > Ah, is that so? And with REST you don't? No, that's exactly what you end up with using REST; I'm pointing out that, at least with deployments I've seen, GraphQL ends up with the same problems, only hidden behind a single URL. > You seem to have _a lot_ of experience with GraphQL I didn't (and wouldn't) say that I have a lot of experience with GraphQL (I have far more with REST/HTTP-based APIs), but I've seen it used enough times to know it's not a panacea, and doesn't always solve the expected problems, especially when it's fronting dozens of (sometimes painfully slow) backend data sources. > I wonder why your previous post has the form of a question It doesn't? I was proffering an opinion, based on my observations when GraphQL is fronting many data sources. > Or was that just a sneaky way of giving your opinion without backing it up? I would politely and respectfully point you towards HN's comment guidelines[0] [0] https://news.ycombinator.com/newsguidelines.html#comments https://news.ycombinator.com/newsguidelines.html#comments
  - valenterry 6y ago
    > I'm pointing out that, at least with deployments I've seen, GraphQL ends up with the same problems, only hidden behind a single URL. Cool, let me give you a mini example, you'll immediately understand it. Two endpoints: 1. users, which contain video-ids and can efficiently be queried by user-id (index in database) 2. videos, which contain video data can efficiently be queried by video-id (index in database) How do I get all uploads of a user? I get the user by id (request 1) then all his videos by making one request per video (n requests). No big problem for the database (it's all indexed) and sure, we can improve the performance, but for now the bottleneck here is the number of requests that goes over the network if we use REST. This doesn't work. You need to make a new endpoint or change an endpoint to make this work in a performant way. In GraphQL we have one endpoint with two different queries. So the same problem can happen if someone queries naively. But, they can also write one nested query that says "give me user for id X and for each video id, give me the video data". It will be one request from frontend to backend, but still multiple selects to the database, unless we use some "smart" GraphQL framework that does magic for us. But we already solved a big part of the problem. And maybe that is already performant enough for what we need and we don't have the need to improve the database query part. Lot's of time and code saved on the backend and frontend. Yay. You might say "but we didn't have indexes". Then my answer is: well, you are not worse off with GraphQL and still gain the benefits for all the cases where you have indexes in place. If you have non of these, you seem to be doing something wrong. > It doesn't? I was proffering an opinion, based on my observations when GraphQL is fronting many data sources. Yeah, seems you edited your post. When I read it, there was 100% a question-mark in it. ;)
    - KronisLV 6y ago
      > How do I get all uploads of a user? I get the user by id (request 1) then all his videos by making one request per video (n requests). No big problem for the database (it's all indexed) and sure, we can improve the performance, but for now the bottleneck here is the number of requests that goes over the network if we use REST. This doesn't work. You need to make a new endpoint or change an endpoint to make this work in a performant way. The answer to this problem is resource expansion. Dylan Beattie actually has a nice and somewhat humorous presentation about how to address this with REST interfaces: https://youtu.be/g8E1B7rTZBI https://youtu.be/g8E1B7rTZBI Here's the part that addresses such data access in particular with a social media site example (people who have photos, which have comments etc.): https://youtu.be/g8E1B7rTZBI?t=1807 https://youtu.be/g8E1B7rTZBI?t=1807 Sadly, approaches like that and even HATEOAS are not awfully widespread, mostly because of the added complexity and the support by frameworks simply not being quite there.