Comment by darqis

3 days ago

I don't understand why no one or barely anyone is using graphql. It's the evolution of all that REST crap.

  query ($name: String!) {
    greeting(where: {name: $name}) {
      response
    }
  }

or

  mutation ($input: CreatePostInput!) {
    createPost(input: $input) {
      id
      createTime
      title
      content
      tags {
        id
        slug
        name
      }
      
    }
  }

and so on, instead of having to manually glue together responses and relations.

It's literally SQL over the wire without needed to write SQL.

The payload is JSON, the response is JSON. EZ.

I've not done much with GraphQL myself, but a lot of my colleagues have and have all sworn off it except in very specific circumstances.

My impression is that it's far too flexible. Connecting it up to a database means you're essentially running arbitrary SQL queries, which means whoever is writing the GraphQL queries also needs to know how those queries will get translated to SQL, and therefore what the database structure/performance characteristics are going to be. That's a pain if you're using GraphQL internally and now your queries are spread out, potentially just multiple codebases. But if you exclude the GraphQL API publicly, now you don't even know what the queries are that people are going to want to use.

Mostly these days we use RPC-style APIs for internal APIs where we can control everything and be really precise about what gets called when and where. And then more "traditional" REST/resource-oriented endpoints for public APIs where we might have more general queries.