[BenjieGillam]

[PostGraphile author here, and I wrote that page of documentation.]

Firstly, GraphQL does not allow for infinite recursion; it is literally not possible to do infinite recursion in GraphQL; the GraphQL spec even has a section on this: https://spec.graphql.org/draft/#sec-Fragment-spreads-must-no...

Secondly, it's extremely easy to add a GraphQL validation rule that limits the depth of queries; here's an example of one where it takes just a single line of code: https://github.com/stems/graphql-depth-limit . This isn't included by default because there are plenty of solutions you're free to choose between, many of which are open source, depending on your project's needs. For most GraphQL APIs, persisted queries/persisted operations is the tool of choice, and is what Facebook have used internally since before GraphQL was open sourced in 2015. (Unlike what you state, this does not turn your API into a "REST API," it acts as an optimisation on the network layer and once configured is virtually invisible to client and server.)

[dmitriid]

> Firstly, GraphQL does not allow for infinite recursion; it is literally not possible to do infinite recursion in GraphQL

It's literally impossible to do infinite recursion anywhere because it's physically impossible to write down an infinite recursion.

However, if you look at the very example you provide on that page, you will see what I mean by infinite recursion. Moreover, you link to the Apollo page which literally has this example:

--- start quote ---

This circular relationship allows a bad actor to construct an expensive nested query like so:

  query maliciousQuery {
  thread(id: "some-id") {
    messages(first: 99999) {
      thread {
        messages(first: 99999) {
          thread {
            messages(first: 99999) {
              thread {
                # ...repeat times 10000...
              }
            }
          }
        }
      }
    }
  }
  }

--- end quote ---

Is 10000 infinite? No. Does it illustrate my point? Yes. Have you missed the point? Also yes.

> Secondly, it's extremely easy to add a GraphQL validation rule that limits the depth of queries

1. This statement is not even remotely true in general sense

2. It is not the default behaviour of any GraphQL implementation (because it's inherent in GraphQL)

3. The "extremely easy" solution for this particular case relies on an external package that needs to be added on top of something else. In your case it's not even added to postgraphile. It's added as an extra middleware to some other graphql library.

And that covers only one dimension: potentially infinite recursion. The other dimension is potentially unbounded complexity. For which the following is true:

1. It's inherent in GraphQL

2. Is not even solved by PostGraphile, except in an experimental paid package

3. The primary mode of mitigating this is disallowing arbitrary queries by providing only a whitelists of allowed queries (so, basically falling back to REST)

So in the end you end up piling more and more complexity on top of other complexities to arrive at a whitelist of allowed queries, ... which is basically just poorly implemented and over-engineered REST (well, REST-ish).

Honestly, no idea why you're fighting the facts of life that you yourself even document on your own product's pages.

[lyxsus]

So you gave me an example of a nested query that is not infinitely recursive and even admitted it. The one that as I said before you have an ability to easily identify before execution, just as any possible variations both in width and depth, from which I conclude that you lack some basic algorithmic knowledge or have troubles to apply them.

I know I’m arrogant, but yours is off the charts. Thanks for confidence boost!