GraphQL is not necessarily a "query language for your API". Public and partner APIs don't control or even know their clients, can't control or even anticipate usage patterns, and therefore would benefit from a flexible query language, and yet there are few public and partner GraphQL APIs. Anecdotal evidence suggests that the security criticisms of GraphQL listed above constitute the main barrier to GraphQL adoption for public APIs. While there do exist GraphQL security measures that can blunt attacks, we should remember that the market for public APIs may be small and may be getting smaller as enthusiasm for public and even partner APIs wanes. That leaves private APIs. Yet private APIs typically own their clients, know their usage patterns, and don't need a flexible query language. So, what then even is GraphQL in this setting?

GraphQL is a development tool. An emerging rebuttal to the criticisms of GraphQL listed above is to use persisted queries, allow-lists, and RESTified-endpoints. That blunts the security criticism against GraphQL APIs largely by removing GraphQL APIs and substituting them with good old-fashioned REST. GraphQL becomes a way to define API endpoints. It's an alternative to defining API endpoints in code, but code is a development tool, so then what is GraphQL but a development tool? If GraphQL is a development tool, then what are its benefits (and its drawbacks)?

The benefits of GraphQL over code as a development tool for defining API endpoints accrue to its original strengths: flexibility, efficiency, and discoverability. GraphQL is a lingua-franca, a ubiquitous-language to mediate conversations among front-end developers, back-end developers, data modelers, and product owners, but it's also an implementation language for the outcome of those conversations. It covers 80% of what code is being asked to do when building APIs–data marshaling–better than code can do it.

The drawbacks of GraphQL over code as a development tool for defining API endpoints lie in that remaining 20%: "business-logic". API server code is a convenient if far from ideal arena for implementing business logic. Business logic–unlike data marshaling–really does benefit from the power of code, and if you're using code to write your API server, you might as well just use the same code to implement the business logic right in the API server. Never mind that this mixes concerns and leads to tight coupling, it at least has the virtue of being obvious. But, these drawbacks can be overcome by building a GraphQL server that has no intrinsic business logic, but instead offers channels for injecting business logic:

input-validation

synchronous RPC into the language of your choice for the simple but common case of validating input data

remote-actions

synchronous RPC into the language of your choice for the less simple but less common general business-logic case

event-triggers

asynchronous event processor in the language of your choice for the common case of exhibiting side-effects

authorization

elegant strategy for the common but thorny problem of access control

Not only do these features equal the "obvious" strategy for business-logic of writing it right into the server code, they exceed it by freeing it from the language of the server and by separating it from the concerns of the server.

Rethinking what GraphQL is by thinking of it as a development tool frees us from a major impediment to GraphQL's progress into the future. The other major impediment is removed as we will see by rethinking how GraphQL is implemented.

query GetOnePost {
  post(limit: 1) {
    id
    content
    comments(limit: 1) {
      id
      content
      replies(limit: 1) {
        id
        content
      }
    }
  }
}

GET https://renewed-manatee-36.hasura.app/api/rest/getonepost

{
  "post": [
    {
      "id": 1,
      "content": "This is my first post!",
      "comments": [
        {
          "id": 1,
          "content": "I love your post! Can't wait for more.",
          "replies": [
            {
              "id": 1,
              "content": "Thank you! I'm glad you enjoyed it."
            }
          ]
        }
      ]
    }
  ]
}

GraphQL need not necessarily be implemented by "providing functions for each field on each type." Those functions are typically called resolvers. They are units of composition in how servers typically execute GraphQL operations. Their granularity and composability fulfill the promise of GraphQL flexibility. Yet they also are to blame for the performance criticisms of GraphQL listed above. Not all servers GraphQL or otherwise are over SQL databases, but many are, and if we use SQL databases as a representative case, the granularity and composability of resolvers also gives rise to the N+1 Problem: a query graph whose node number grows exponentially with every level leads to a call graph whose resolver function calls grow exponentially, which leads to a batch of SQL statements that grows exponentially. Never mind that the retrieved data volume also grows exponentially with every level, which imposes a natural limit on how far this can go, this is still a problem. And yet the leading solution to this problem–the data-loader pattern–only diminishes the problem without banishing it, sacrifices much of GraphQL's flexibility, and contributes to the complexity which is the third criticism listed above. Confronted with this Gordian knot, it's worth asking another foundational question. Can we implement GraphQL in some other way, and if so, how?

GraphQL can be implemented with a compiler. GraphQL is a general-purpose query language which often (if not always) is over data that ultimately comes from database engines with their own general-purpose query languages. If those engines happen to process their queries with a network of operators that bear more than a passing resemblance to resolvers, that's their business. All we have to do is compile (or translate, or transpile) our query into theirs and let them handle the rest. Some people in the GraphQL community are finally getting around to this idea. Some of us have been here all along.

The benefits of a compiler approach to GraphQL are many. It eliminates the N+1 problem. It paves the way for a powerful strategy for implementing authorization as discussed above. And, by generating the GraphQL schema from the database schema, it eliminates tedious repetitive boilerplate data modeling that serves high-minded ideals that are impractical at scale.

The drawbacks of a compiler approach to GraphQL are legendary, but in that word's first meaning rather than its second: "of, relating to, or characteristic of legend or a legend", i.e. folklore. The fear is that by generating the GraphQL schema from the database schema, the database is exposed and the data modeler's hands are tied. That would be a problem if it were true, but it isn't. The GraphQL schema can be curated as much or as little as needed via SQL views, SQL functions, and affordances and configurations within the GraphQL server. Moreover, the proposed alternative isn't as different as one might think. Deliberately, thoughtfully, lovingly "designing" a GraphQL data model by meticulously writing resolvers is just making the same choices in code as we recommend through configuration, albeit by taking the long way around.

Rethinking how GraphQL is implemented by thinking of it as a compiler opens up new strategies for addressing old problems. It may not be possible in every case. In Facebook's OG use-case for creating GraphQL, it had a high-performance object-based data model many layers of abstraction away from any databases. That's a blessing and a curse. There may be no query language to compile to, but on the other hand you can string together resolvers to your heart's content and sleep easy at night knowing the high-performance object-based data model's vast reserves of optimized performance will absorb or neutralize any N+1 performance problems thrown at it. For the rest of us with our puny SQL databases? Let's just generate our GraphQL schema, compile our GraphQL queries, and call it a day.

query GetOnePost {
  post(limit: 1) {
    id
    content
    comments(limit: 1) {
      id
      content
      replies(limit: 1) {
        id
        content
      }
    }
  }
}

SELECT
  coalesce(json_agg("root"), '[]') AS "root"
FROM
  (
    SELECT
      row_to_json(
        (
          SELECT
            "_e"
          FROM
            (
              SELECT
                "_root.base"."id" AS "id",
                "_root.base"."content" AS "content",
                "_root.ar.root.comments"."comments" AS "comments"
-- ...
-- ...