[valenterry]

> What stops a frontend developer writing an ad-hoc query?

What stops them is that the "ad-hoc" query can only look like this:

    articlesWithComments($id) {
      title
      contents
      comment {
        author
        text
      }
    }

That's all. Now the only way to change this query is to remove fields but there is no way to make anything more complex. The only way to do more is to repeat the query. I.e. literally:

    article1: articlesWithComment(1) {
      title
      contents
      comment {
        author
        text
      }
    }
    article2: articlesWithComment(2) {
      title
      contents
      comment {
        author
        text
      }
    }

That will create two queries in the backend - that is the equivalent of just making two requests against the same REST route.

It _is_ possible to allow a user to change the query like this:

    articlesWithComments($id) {
      title
      contents
      comment {
        author {
          name,
          age,
          articles {
            ...
          }
        }
        text
      }
    }

But that is totally optional - you don't have to give your users this power.

[dmitriid]

> What stops them is that the "ad-hoc" query can only look like this:

What is "author" in that query and why can't the user do

  author {
          name,
          age,
          articles {
            ...
          }
        }

in that query?

And what you're basically saying is: let's create REST with extra steps for no particular reason. With extremely complex setups where author in one query has a different set of fields than in a different query etc.

[valenterry]

"author" would be the same as in the REST endpoint. So for example a string.

As for your question, why the user can't change the query (in this example) : because it violates the specifiction and will be rejected by the server.

Does it answer your questions?

[dmitriid]

So, you're basically proposing to create a poor imitation of REST.

What's the point of GraphQL in this case?

[valenterry]

I suggest you to take a step back and re-read the thread. Maybe the context got lost. I replied to the following post:

> https://news.ycombinator.com/item?id=25432655

In particular:

> Its much harder to make an efficient resolver than it is making an efficient REST endpoint.

As I showed, the claim is not true because it can be solved in the same way in both GraphQL and REST.

[dmitriid]

> I suggest you to take a step back and re-read the thread. Maybe the context got lost.

I've read the thread. And no, the context wasn't lost.

The whole point of GraphQL is flexible queries. And it is harder to make an efficient resolver in GraphQL than it is in REST.

And yes, your solution (and the solution everyone ends up arriving at) is reimplementing REST in GraphQL, poorly. Precisely because it is much harder to make an efficient resolver in GraphQL.

[valenterry]

I think I have proven my point and I'm not eager to discuss additional topics about GraphQL in this subthread.