This is where I’m most adamant. Don’t spread permission checks around across your resolvers, the pieces of code that fetch each field. The official authorization best practices document from the GraphQL project advises you to put the rule in the business logic layer, and then let the resolver just request the answer. But if the rule is living in resolvers, one day you’ll find yourself with a second route into the same data, be it a REST API, a batch process, some other service—and you’ll end up with two slightly different versions of the rule, and two users will get different data based on which door they walked in through. In a system that controls access, this is the worst bug there could ever be because it behaves like a feature.
Five questions to ask before you adopt it
They won’t decide things for you, but they’ll show you which side of the fence the weight of evidence points to.
- How many clients/screens need different shapes of the same data? If the answer is one or two, maybe a few carefully designed REST endpoints will get the job done for you.
- How interconnected is the data? The more interdependent, the greater the gain from GraphQL. From customers to accounts to permissions to owners is a great deal of interdependence.
- Who owns the schema and the layer above the schema? When there is no owner of the contract, drift will occur.
- What are your authorization rules? And how are they currently implemented? If they are spread around, GraphQL will expose that. If they are currently implemented in your business logic layer, you’re in great shape.
- Do you need more than a REST endpoint? That’s the truth you need to be asking yourself here. “Probably” is a fine answer.
Reading the responses is easy. If there are multiple clients with needs for different slices of highly interconnected data, you have the ability to take ownership of the schema and you have a centralized authorization mechanism, use this response and start by using the screens with the most pain. In case your answer was “one client, flat data, no schema owner”, then hold your horses. You have just paid for something you do not need. If you have mixed responses, try GraphQL with one read-heavy screen and start off with depth and authorization controls.
