When GraphQL earns its place in an enterprise application, and when it doesn’t

The value of GraphQL emerges for a specific type of enterprise screen, one that brings together highly interdependent data across multiple sources. In all other cases, there is a price to pay, which is bound to come out after you have already made the decision. I build internal access-governance applications, with React front ends that talk to both REST and GraphQL back ends. Using the two side by side has shown me where each earns its keep and where each gets in the way. The article is divided into three sections. The first section covers areas in which GraphQL eliminates round trips and front-end work. The second section highlights the underestimated costs involved. Finally, there are a few questions you can ask yourself before implementing the GraphQL approach.

GraphQL helps most on screens built from connected data

Imagine the details screen for one client. On this screen, you see the client, his/her accounts, permissions for these accounts, owners of these accounts and some related objects for each. Data is highly interrelated, and your screen requires some portion of each layer at once. There are two scenarios for working with REST API. In the first scenario, the front end makes several requests – first for the client, then for his accounts and then for permissions of each of those accounts. Each request in the chain waits for the preceding request to be finished. Another scenario is when the back end creates a specific endpoint in the desired format. The first one becomes very inefficient whenever the network has some issues. The second one works well as long as the information that is to appear on the next screen appears in the same format as before, but then you get many endpoints nobody cares about maintaining. With the help of GraphQL, it becomes possible to change the decision-maker of the shape. The client asks for the query with the specific fields and receives the response in the specific format. This is how it is described in the GraphQL documentation on queries: you ask for specific fields, and one query can traverse related objects in a single request instead of several round trips. It was here that I noticed its relevance. With the access governance application I am developing now, each screen requests data about the account, account owner, systems the account is linked to, credential state and the history of reviews. These data are connected first of all, so I decided to store them in the graph database and then use GraphQL to query it. The front end requests whatever it requires from the backend, while introducing a new screen means creating a new query rather than another endpoint. The true value here is reducing backend development effort each time the front end changes its mind. I will not be able to quantify this benefit in any way, but the benefit I know for sure is a reduced number of endpoints to develop and fewer sequential queries on screens requiring more connected data. Notice the conditions under which this happens. Data is connected, screens require different data and the same team or two teams talking to each other daily manages both parts.

The costs are caching, query limits and field-level access

GraphQL is used by teams to make things easier for themselves on the front-end side, but, along with it, they end up paying three more costs which they did not have in mind while preparing for their projects. The first of these is caching. Since the URL represents the resource in REST, there are lots of options for automatic caching. But GraphQL is served via one endpoint only, and this makes caching harder. Indeed, the caching guide for GraphQL states that since there is no URL-like way of identifying the object, the API should generate a globally unique identifier for each object type. The second factor is the cost of the query. Because it’s the client who determines the format of the query, there is absolutely no reason why the client should not be making demands for a large amount of data. The query that is nested ten layers deep or the query that fetches everything from an extensive list can be detrimental to your back end, whether it was done in malice or stupidity. OWASP GraphQL Cheat Sheet suggests to limit the depth of queries, do cost analysis and define max query cost, paginate and disable introspection in production. The third and the one that gives companies the most problems is authorization. Endpoint-level authorization is simpler when using REST; securing your endpoint covers a lot of it, although REST also needs object-level checks. However, when using GraphQL, it only requires one query for the user to get to the customer and his account, and then he will access a field of the referenced object that he should not have access to. You need to perform your access control on a per-object and per-field basis. What OWASP says you need to do is to check whether the requester has access to all the objects and the fields returned. 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. This is not my default choice in all cases and even in all the places in which I use it. For operations which have command characteristics such as kicking off a credential rotation and verifying whether an account is needed, REST endpoints should be used because they do one thing, they are easily authorized, easily logged and easily retried, and no one gains from allowing the client to mold the results. Here is something that you can put into practice during this week. You can make a list of the five most used screens in your application and see how many distinct calls are made through them. If one or two are connected and chatty, then that is where your GraphQL can earn its keep.