This is an awesome POC @alexbuijs.

Recursiveness:

it looks like you're recursively checking all the fields and types to gather the required permissions for nested resources, can you confirm that? For example in this query Project.environments would require not only read_project (defined in ProjectType) for the project, but also read_environments (defined in EnvironmentType).

Performance consideration:

Im curious of the performance of navigating the schema tree constantly, and instead if we're be able to pre-calculate the required permissions for types (IDK maybe like a hash map of the schema and required permissions instead of matching the name of the field against the schema and pulling the directive attributes off of it on the fly for every field) This is probably way out of scope of the POC but it did get me thinking about it.

Policy as code:

I like your simple implementation of AuthorizationChecker, its straight forward and gets the point across. Though I'm assuming in practice, especially in the new auth architecture that we'll want this portion to leverage policy as code. This is of course up for debate, but my guess is that as we move more authorization to pre-authorization (I mean before we the proxy accepts the request and sends it to workhorse/rails) we're going to want it to be manageable, standardized, and extendable. And these are attributes of a mature policy language.

This is an awesome POC @alexbuijs.

Thanks! Claude did most of the heavy lifting here though 😅

it looks like you're recursively checking all the fields and types to gather the required permissions for nested resources, can you confirm that?

Yes that's correct.

Im curious of the performance of navigating the schema tree constantly, and instead if we're be able to pre-calculate the required permissions for types

I didn't look into it directly, but we should be able to accomplish the same with the exported list of types and mutations with their required permissions, as described above.

What this PoC does not account for, is namespace extraction from the query. As tokens will be scoped to namespaces, a namespace is required to make authorization decisions. It could be easily modified to extract the path or id from the query variables though.