[satvikpendem]

I wrote another comment the other day (https://news.ycombinator.com/item?id=37125685) about how GraphQL has true typing unlike bolted on solutions to REST, and that most people use GraphQL incorrectly then complain about how they're running into problems with N+1 and all that. Basically, the way Facebook originally designed it was in combination with Relay and its graph query optimizing compiler that can stitch your entire app's query data together so that you never over- or under-fetch, at all. If you just use it like REST, you're gonna have a bad time. The comment:

GraphQL is very useful, it removes whole classes of bugs. You can even use a Result/Either type where if you don't handle both the success and error cases, the GraphQL request won't even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema:

    type Error {
      message: String!
    }
    
    type Query {
      hello(name: String!): QueryHelloResult
    }
    
    union QueryHelloResult = Error | QueryHelloSuccess
    
    type QueryHelloSuccess {
      data: String!
    }

you can then query it with

    query {
      hello(name: "World") {
        __typename
        ... on Error {
          message
        }
        ... on QueryHelloSuccess {
          data
        }
      }
    }

If you forget `... on Error` the query will simply fail. I should also add that most people use GraphQL incorrectly, to get the benefits of not over/underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it's not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way.

[0] https://www.youtube.com/watch?v=yab6i9lrEv0

[1] https://pothos-graphql.dev/docs/plugins/errors

[2] https://alan.norbauer.com/articles/relay-style-graphql

[I_am_tiberius]

Doesn't the fragment (property selection) feature of graphql only solve the frontend network load part? I mean, I doubt anyone creates an SQL query based on the graphql query properties, right? That means the network load between backend and db server is consistent, independent from which fields are selected via graphql.

[satvikpendem]

You could use a backend framework that optimizes the SQL as well (I believe Hasura does this), or just have a string interpolated select statement in the SQL.