Structuring for Authorization

Implementation of authorization

Some authorization concerns can be handled by the very structure of the data within our application, and we can use this when we design our schema.

The idea is that a single field can authenticate for fields deeper down in our query. After all, a GraphQL document is a tree; if we can have a single field act as a gatekeeper for any data that requires authorization, it could simplify our code. It would also reduce the amount of mental overhead involved in trying to remember what is and isn’t public.

A good example of some data in our application that is structured this way is the orders associated with a particular customer’s record. Based on what we’ve done so far, if we’re logged in as a customer and want to get our orders as well as the current menu, we might expect to use a document like this: