By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?

I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.

I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.

Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc.

I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.

https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.

This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1]

[1] https://graphql-ruby.org/authorization/visibility.html

> Tell me how you do the control/auth and allow certain users to access a resource while others

how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend.

> formulate complex queries where they ask for the kitchen sink

most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".