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
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article:
When GraphQL earns its place in an enterprise application, and when it doesn’t