4 ms·

I spend about 3/4 of a full time job building, maintaining and improving a corporate GraphQL API, and have for the last few years. What you are describing is no

I spend about 3/4 of a full time job building, maintaining and improving a corporate GraphQL API, and have for the last few years. What you are describing is not my experience. In fact it is far easier than it was in the old days when each new requirement meant code changes to a REST API. Certainly there have been problems with queries that had unacceptable performance, even those that took down the whole API server and database. Of course that wasn't a novelty with our REST APIs either. It certainly is an issue with GraphQL, but it has been a managable one for us. Largely this is because the API is not public, and it doesn't have to simply handle anything that is thrown at it. When we see a frequent, slow GraphQL query in a report, we have many options to deal with it, including going to the front-end team and asking them to query in another way, and I have had to resort to that. Often I can optimize the code instead. But that hasn't been a huge problem, especially compared to the great benefits of pushing most of the data work to the front-end. And the size and complexity limitations we've built into the API handle such problems seemlessly most of the time. The caller gets a clear error message that specifies the problem, and they can usually compensate very quickly with an altered query. When they can't then I get involved and sometimes have to say, uh, we can't do that ... without scads of extra work. And the work on my plate today is for one of those scads. I was doing lots of REST API work before GraphQL APIs, and my own and our corporate experience is that GraphQL solves a lot more problems than it causes.

frosted-flakes 4y ago
> Largely this is because the API is not public, and it doesn't have to simply handle anything that is thrown at it. I think this is the key point.
- Aeolun 4y ago
  Can’t you just have a gql query abort the moment it takes too much time to retrieve the requested data?
  - Kaze404 4y ago
    You can. There's the concept of query complexity as well that lets you simply reject queries that are too complex and likely to cause trouble.
shroompasta 4y ago
The problem with GraphQL is on the front end. Suddenly, the FE team becomes responsible for understanding the entire data model, which resources can be joined together, by what keys, and what is actually performant vs what isn't. Instead of doing a simple GET /a/b/1/c and presenting that data structure, they now need to define a query, think about what resources to pull into that query etc. If the query ends up being slow, they have to understand why and work on more complex changes than simply asking the BE team for a smaller response with a few query params. I hit this problem when contemplating exposing the API of the application I work on to customers, to be used in their automation scripts. We quickly realized that expecting them to learn our data model and how to use it efficiently would be much more complicated than exposing every plausible use-case explicitly. We could do this on the "API front-end" by building a set of high-level utilities that would embed the GraphQL queries, but that would essentially double much of the work being done in the front-end (and more than double if some customers want to use Python scripting while others want JS and others want TCL or Perl). So, we decided that the best place to expose those high-level abstractions is exactly the REST API, where it is maximally re-usable.
- Aeolun 4y ago
  I think what you are basically saying is the people working on the front-end are a bunch of children that cannot be trusted to do the right thing. I’ve seen this a lot from backend teams, and it’s beyond frustrating. Because now my nice clean frontend code suddenly has to deal with a bunch of franken query logic simply because the backend team cannot be bothered to alter their “pristine” API. Never mind that this means a thousand requests where one graphql query would have sufficed.
- salawat 4y ago
  Can confirm. Getting developers (Nevermind QA's) to build data model savvy appears to be one of those things some have taken for granted right up until you realize other people really did mean it when they said you were nuts. I've never seen it as nuts and a bare pre-req ofodern computing. Apparently this view is the subject of widespread controversy amongst peers.

frosted-flakes 4y ago

> Largely this is because the API is not public, and it doesn't have to simply handle anything that is thrown at it. I think this is the key point.

Aeolun 4y ago
Can’t you just have a gql query abort the moment it takes too much time to retrieve the requested data?
- Kaze404 4y ago
  You can. There's the concept of query complexity as well that lets you simply reject queries that are too complex and likely to cause trouble.

shroompasta 4y ago

The problem with GraphQL is on the front end. Suddenly, the FE team becomes responsible for understanding the entire data model, which resources can be joined together, by what keys, and what is actually performant vs what isn't. Instead of doing a simple GET /a/b/1/c and presenting that data structure, they now need to define a query, think about what resources to pull into that query etc. If the query ends up being slow, they have to understand why and work on more complex changes than simply asking the BE team for a smaller response with a few query params. I hit this problem when contemplating exposing the API of the application I work on to customers, to be used in their automation scripts. We quickly realized that expecting them to learn our data model and how to use it efficiently would be much more complicated than exposing every plausible use-case explicitly. We could do this on the "API front-end" by building a set of high-level utilities that would embed the GraphQL queries, but that would essentially double much of the work being done in the front-end (and more than double if some customers want to use Python scripting while others want JS and others want TCL or Perl). So, we decided that the best place to expose those high-level abstractions is exactly the REST API, where it is maximally re-usable.

Aeolun 4y ago
I think what you are basically saying is the people working on the front-end are a bunch of children that cannot be trusted to do the right thing. I’ve seen this a lot from backend teams, and it’s beyond frustrating. Because now my nice clean frontend code suddenly has to deal with a bunch of franken query logic simply because the backend team cannot be bothered to alter their “pristine” API. Never mind that this means a thousand requests where one graphql query would have sufficed.
salawat 4y ago
Can confirm. Getting developers (Nevermind QA's) to build data model savvy appears to be one of those things some have taken for granted right up until you realize other people really did mean it when they said you were nuts. I've never seen it as nuts and a bare pre-req ofodern computing. Apparently this view is the subject of widespread controversy amongst peers.