A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me.
Of course there are ways to prevent data from being returned but that’s fragile.
Of course there are ways to prevent data from being returned but that’s fragile.
For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable.
Checking every field can also easily lead to performance issues, because it’s not uncommon for a large, complex graphql request to have hundreds or thousands of fields (particularly when displaying lists of data to a user).
A proper solution to security/privacy issues should have sensitive data never reach the outermost GraphQL layer.
So the problem is with the existing tooling that enables GraphQL implementations, but like anything else, if that tooling is deficient, the entire approach is on the shaky ground too.
At my current job, this was done before I was involved. It isn’t a deal breaker, but it throws away one of the best features of GraphQL.
In the end you just have every client implement the rules that should have been in an API tier (if they are competent), or worse no validation that gets you a giant mess.