8 ms·

GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-produc

GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a human problems than a technical problems, if someone think there is no value in that and bare metal performance is paramount that person never worked in a big org. > RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. Unfortunately GraphQL way of working is very different from normal REST APIs and often requires more complex server-side caching. The N+1 problem needs to be figured out upfront for every data-storage system used in the backend.

dudeinjapan 2y ago
Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contract--can do it with OpenAPI/Swagger--here are the endpoints, here are the allowed parameters, here is the response you will get--and we will make sure this narrowly defined scope works 100% of the time!
- beeboobaa3 2y ago
  Not to mention the fact that GraphQL allows anyone messing with your API to also execute any query they want. Then you start getting into query whitelisting which adds a lot of complexity.
- RHSeeger 2y ago
  Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller; the same way it would be if they made multiple REST calls Do you have an example of a call to a GraphQL API that would be a problem, that wouldn't be using some other approach?
  - deleted 2y ago
    [deleted]
  - serpix 2y ago
    Then we just come back full round trip to REST where the backend clearly defines what is allowed and what is returned. So using GraphQL it is unnecessary complicated to safeguard against a caller querying for all of the data and then some. For example the caller queries nested structures ad infinitum possibly even triggering a recursive loop that wakes up somebody at 3am.
    - RHSeeger 2y ago
      But GraphQL doesn't allow for infinitely nested queries; the query itself has to include as much depth as it wants in the response. > Then we just come back full round trip to REST Except that GraphQL allows the back end to define the full set of fields that are available, and the front end can ask for some subset of that. This allows for less load; both on the network and on what the back end needs to fetch data for. From a technical perspective, GraphQL is (effectively) just a REST API that allows the front end to specify which data it wants back.
      - serpix 2y ago
        You are correct and I agree with you. GraphQL can be used effectively like this and I've seen one example where GraphQL is used like this. New endpoint can be defined very quickly and it is essentially like a REST API with the possibility of the client specifying what data it wants back (as you described). The other extreme end example is to expose by default the entire data model (PostGraphile) and then getting lost in the customisation and authorisation.
- DanielHB 2y ago
  > It is far better for the Backend to provide Frontend a contract It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3). > This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is true it can cause these kind of problems, but they take far, far, far less time than mundane contract agreement conversations. Although having catastrophic failures is usually pretty dire when they do happen, but there are a lot of ways of mitigating as well like good monitoring and staggered deployments. It is a tradeoff to be sure, there is no silver bullet.
  - jpalawaga 2y ago
    trying to solve org problems with tech just creates more problems, allthewhile not actually solving the original problem.
    - clintonb11 2y ago
      This is what I wanted to say too. If your backend team is incapable of rapidly adding new endpoints for you, they probably are going to create a crappy graphql experience and not solve those problems either. So many frontend engineers on here saying that graphql solves the problem they had with backend engineers not being responsive or slow, but that is an org problem, not a technology problem.
      - dudeinjapan 2y ago
        At TableCheck, our frontend engineers started raising backend PRs for simple API stuff. If you use a framework like Rails, once you have the initial API structure sketched out, 80% of enhancements can be done by backend novices.
    - smaudet 2y ago
      Yup. And the solution to that org problem is for the front engineers to slow down, and help out the "backend" engineers. The complexity issues faced by the back-end are only getting worse with time, the proper solution is not adding more complexity to the situation, but paying down the technical debt in your organization. If your front-end engineers end up twiddling their thumbs (no bugs/hotfixes), perhaps there is time (and manpower) to try to design and build a "new" system that can cater to the new(er) needs.
- gedy 2y ago
  > the Frontend is allowed to send any possible query to the Backend It's really not, it's not exposing your whole DB or allowing random SQL queries. > It is far better for the Backend to provide the Frontend a contract GraphQL does this - it's just called the GraphQL "schema". It's not your entire database schema.
- fire_lake 2y ago
  A GraphQL schema is a contract though. And the REST API can still get hammered by the client - they could do an N + 1 query on their side. With GraphQL at least you can optimize this without adding a new endpoint.
  - dudeinjapan 2y ago
    Yes, GraphQL is a "contract" in the sense that a blank check is also a "contract".
    - arcticfox 2y ago
      You can whitelist queries in most systems though. In development mode allow them to run whatever query, and then lock it in to the whitelist for production. If that type of control is necessary.
- chuckadams 2y ago
  Most REST APIs I've seen in the wild just send the entire object back by default because they have no idea which fields the client needs. Most decent REST API implementations do support a field selection syntax in the query string, but it's rare that they'll generate properly typed clients for it. And of course OpenAPI has no concept of field selection, so it won't help you there either. With my single WordPress project I found that WP GraphQL ran circles around the built-in WP REST API because it didn't try to pull in the dozens of extra custom fields that I didn't need. Not like it's hard to outdo anything built-in to WP tho...
afiori 2y ago
> In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. You should log deprecation warnings. But also if the client is composing urls/params manually then you are not doing REST, you are doing RPC. Rest APIs should mainly use HATEOAS hyperlinks to obtain a resource. that is clients almost always call links you have provided in other reponses (starting from a main entrypoint)
- vbezhenar 2y ago
  REST is just a short name for RPC over JSON. Nobody does real Fielding's REST.
  - deleted 2y ago
    [deleted]
  - afiori 2y ago
    I disagree, REST is still meaningfull even in the usual loosened sense, it still means that you are working with some kind of actions on resources
BiteCode_dev 2y ago
The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all request params.
- tomrod 2y ago
  I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?
  - BiteCode_dev 2y ago
    Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away. But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed. And even if it's not the case, you can now break the client at any time because they decide to use a feature you gave them, but that you actually can't deal with right now.
    - barrkel 2y ago
      To be clear, the main thing that's abstracted away are server round-trips and client-side joins. REST APIs can fetch data from different systems too.
      - BiteCode_dev 2y ago
        Sure but queries are crafted in the client, that may know nothing about this, while a rest api, the requests are restricted and the queries are more likely under control of the server, which mean the backend will likely decide what fetches what and when. It takes a lot of work to actually ensure all possible combinations of graphql params hit exactly what you want in the backend, and it's easy to mess with it in the frontend.
tuan 2y ago
> GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams) What do you mean by "backend developer" ? The one who creates the GraphQL endpoints for UI to consume ?

dudeinjapan 2y ago

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contract--can do it with OpenAPI/Swagger--here are the endpoints, here are the allowed parameters, here is the response you will get--and we will make sure this narrowly defined scope works 100% of the time!

beeboobaa3 2y ago
Not to mention the fact that GraphQL allows anyone messing with your API to also execute any query they want. Then you start getting into query whitelisting which adds a lot of complexity.
RHSeeger 2y ago
Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller; the same way it would be if they made multiple REST calls Do you have an example of a call to a GraphQL API that would be a problem, that wouldn't be using some other approach?
- deleted 2y ago
  [deleted]
- serpix 2y ago
  Then we just come back full round trip to REST where the backend clearly defines what is allowed and what is returned. So using GraphQL it is unnecessary complicated to safeguard against a caller querying for all of the data and then some. For example the caller queries nested structures ad infinitum possibly even triggering a recursive loop that wakes up somebody at 3am.
  - RHSeeger 2y ago
    But GraphQL doesn't allow for infinitely nested queries; the query itself has to include as much depth as it wants in the response. > Then we just come back full round trip to REST Except that GraphQL allows the back end to define the full set of fields that are available, and the front end can ask for some subset of that. This allows for less load; both on the network and on what the back end needs to fetch data for. From a technical perspective, GraphQL is (effectively) just a REST API that allows the front end to specify which data it wants back.
    - serpix 2y ago
      You are correct and I agree with you. GraphQL can be used effectively like this and I've seen one example where GraphQL is used like this. New endpoint can be defined very quickly and it is essentially like a REST API with the possibility of the client specifying what data it wants back (as you described). The other extreme end example is to expose by default the entire data model (PostGraphile) and then getting lost in the customisation and authorisation.
DanielHB 2y ago
> It is far better for the Backend to provide Frontend a contract It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3). > This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is true it can cause these kind of problems, but they take far, far, far less time than mundane contract agreement conversations. Although having catastrophic failures is usually pretty dire when they do happen, but there are a lot of ways of mitigating as well like good monitoring and staggered deployments. It is a tradeoff to be sure, there is no silver bullet.
- jpalawaga 2y ago
  trying to solve org problems with tech just creates more problems, allthewhile not actually solving the original problem.
  - clintonb11 2y ago
    This is what I wanted to say too. If your backend team is incapable of rapidly adding new endpoints for you, they probably are going to create a crappy graphql experience and not solve those problems either. So many frontend engineers on here saying that graphql solves the problem they had with backend engineers not being responsive or slow, but that is an org problem, not a technology problem.
    - dudeinjapan 2y ago
      At TableCheck, our frontend engineers started raising backend PRs for simple API stuff. If you use a framework like Rails, once you have the initial API structure sketched out, 80% of enhancements can be done by backend novices.
  - smaudet 2y ago
    Yup. And the solution to that org problem is for the front engineers to slow down, and help out the "backend" engineers. The complexity issues faced by the back-end are only getting worse with time, the proper solution is not adding more complexity to the situation, but paying down the technical debt in your organization. If your front-end engineers end up twiddling their thumbs (no bugs/hotfixes), perhaps there is time (and manpower) to try to design and build a "new" system that can cater to the new(er) needs.
gedy 2y ago
> the Frontend is allowed to send any possible query to the Backend It's really not, it's not exposing your whole DB or allowing random SQL queries. > It is far better for the Backend to provide the Frontend a contract GraphQL does this - it's just called the GraphQL "schema". It's not your entire database schema.
fire_lake 2y ago
A GraphQL schema is a contract though. And the REST API can still get hammered by the client - they could do an N + 1 query on their side. With GraphQL at least you can optimize this without adding a new endpoint.
- dudeinjapan 2y ago
  Yes, GraphQL is a "contract" in the sense that a blank check is also a "contract".
  - arcticfox 2y ago
    You can whitelist queries in most systems though. In development mode allow them to run whatever query, and then lock it in to the whitelist for production. If that type of control is necessary.
chuckadams 2y ago
Most REST APIs I've seen in the wild just send the entire object back by default because they have no idea which fields the client needs. Most decent REST API implementations do support a field selection syntax in the query string, but it's rare that they'll generate properly typed clients for it. And of course OpenAPI has no concept of field selection, so it won't help you there either. With my single WordPress project I found that WP GraphQL ran circles around the built-in WP REST API because it didn't try to pull in the dozens of extra custom fields that I didn't need. Not like it's hard to outdo anything built-in to WP tho...

afiori 2y ago

> In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. You should log deprecation warnings. But also if the client is composing urls/params manually then you are not doing REST, you are doing RPC. Rest APIs should mainly use HATEOAS hyperlinks to obtain a resource. that is clients almost always call links you have provided in other reponses (starting from a main entrypoint)

vbezhenar 2y ago
REST is just a short name for RPC over JSON. Nobody does real Fielding's REST.
- deleted 2y ago
  [deleted]
- afiori 2y ago
  I disagree, REST is still meaningfull even in the usual loosened sense, it still means that you are working with some kind of actions on resources

BiteCode_dev 2y ago

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all request params.

tomrod 2y ago
I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?
- BiteCode_dev 2y ago
  Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away. But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed. And even if it's not the case, you can now break the client at any time because they decide to use a feature you gave them, but that you actually can't deal with right now.
  - barrkel 2y ago
    To be clear, the main thing that's abstracted away are server round-trips and client-side joins. REST APIs can fetch data from different systems too.
    - BiteCode_dev 2y ago
      Sure but queries are crafted in the client, that may know nothing about this, while a rest api, the requests are restricted and the queries are more likely under control of the server, which mean the backend will likely decide what fetches what and when. It takes a lot of work to actually ensure all possible combinations of graphql params hit exactly what you want in the backend, and it's easy to mess with it in the frontend.

tuan 2y ago

> GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams) What do you mean by "backend developer" ? The one who creates the GraphQL endpoints for UI to consume ?