(You missed a line break so my quote extended into your response).
> It seems like you are getting caught up in the name of "query language" which may be partially a misnomer. It's more like a data fetching protocol
Yes, I gave multiple definitions and that’s one of them (2). While that’s certainly true, is that how it’s used in practice and sold? All popular frameworks I’m aware of are selling themselves as having automatic db resolvers with SQL dbs. And thus fast frontend iteration. N+1 solution. Etc.
> It's the server code logic to implement permission check
Isn’t that very difficult to do? Resolvers have recursive relations that can be very tricky to secure, since it’s a high abstraction level. So you tend to rely on RLS or another system to be configured, no?
> Isn’t that very difficult to do? Resolvers have recursive relations that can be very tricky to secure, since it’s a high abstraction level. So you tend to rely on RLS or another system to be configured, no?
I really don't think it's any more difficult than if you're not using graphql. If you're hitting a db then you can store auth/permission context for the lifetime of the request. Each time you hit the db to resolve a node, you're going to use the same types of patterns you'd use when fetching objects from the db using sql or an orm. It's customary to have a request context object available in all of the resolvers for just this reason.
If you resolving by calling other services, auth scopes would typically be forwarded on in request headers.
> All popular frameworks I’m aware of are selling themselves as having automatic db resolvers with SQL dbs.
I think I agree if some frameworks for full stack aimed at prototyping where a solo frontend-focused developer needs a backend it abstracts too much, including the db. In these cases, it's probably unnecessary and if you're solo dev on a full stack framework and probably doesn't matter either way.
I've worked on graphql at scale as an frontend service that acted as an API gateway of sorts. The resolvers were not accessing the db but calling other services.
When working on a new application, I would probably use REST and probably would be a long while and would need to have a set of problems to solve with graphql. I think it's quite good at federating services.
> It seems like you are getting caught up in the name of "query language" which may be partially a misnomer. It's more like a data fetching protocol
Yes, I gave multiple definitions and that’s one of them (2). While that’s certainly true, is that how it’s used in practice and sold? All popular frameworks I’m aware of are selling themselves as having automatic db resolvers with SQL dbs. And thus fast frontend iteration. N+1 solution. Etc.
> It's the server code logic to implement permission check
Isn’t that very difficult to do? Resolvers have recursive relations that can be very tricky to secure, since it’s a high abstraction level. So you tend to rely on RLS or another system to be configured, no?