[hobofan]

This, to me, doesn't sound believable, as conceptually, it such a trivial problem, that I don't believe Meta can not handle it. Maybe in 2016 when that article was written that was the case, but even then I doubt it.

Yes, for your average small team that hasn't figured out how to do resource- and subresource-level permissions, this will be tricky. That will also be tricky regardless of whether you are using GraphQL or REST (though with REST, the "solution" is often to write permission checks on a more coarse level and hope that they align correctly with the data you are querying).

However with the advent of Zanzibar and derivative solution and policy languages (Rego for OPA or Polar for Oso), it has gotten quite easy to do (sub)resource permissions without that being a huge burden on complexity and your codebase.

[Kwpolska]

It is trivial to verify Meta is doing this. If you go to Facebook or Instagram and look at the network traffic, you might find requests to /api/graphql, with a lot of weird values in the request payload, but no GraphQL query text — one of the fields is an ID of the query from the allowlist, and GraphQL becomes a glorified RPC mechanism.

[hobofan]

I'm not disputing that Meta is doing build-time query->query ID replacement. I'm disputing the that they are doing that(/have to do that) because it's the only way to satisfy security requirements.

It makes sense for many more reasons to do that, e.g. to validate/automatically optimize your database schema and indices. Especially if your base database is quite schemaless (such as the TAO system, which they used for a long time), that can be crucial for performance.