On the Mis-use of GraphQL

I've consumed GraphQL APIs from the client side and also worked with them from the API side for 4 years. Headless / composable / serverless frontend architectures have brought into the spotlight an alluring promise to those who build a GraphQL API – infinite freedom.

This hope of freedom from backend tyranny has led to frontend engineers (I am one, no shame) wanting to make the data fetching strategy simpler and more efficient. The problem is that these things, more often than not, can be (to some degree, at least) mutually exclusive.

Asking for GraphQL without realizing the trade-offs is a common anti-pattern. In the case of a narrow, highly standardized (for the most part) use case like the eCommerce space (where I work these days), I would say it’s about equally likely that a GraphQL API will present an opportunity to either improve your data fetching strategy — OR — unwittingly de-optimize your API interactions and queries.

APIs with a GraphQL interface often present an alluring, yet deceptive promise —

“You can have ALL the data. And you can have it in ONE FAST CALL!”

Some of the big questions to focus on here are data co-location, and monolith vs microservices architectures. In a monolith with a single DB, GraphQL is a great way to allow the client to optimize the query. Even then, table joins and traversal need to be considered, so there are trade-offs here as well.

The bigger concern is microservices architectures. It’s easy to write a GraphQL API Gateway and treat it as an orchestration layer, but unintentionally allow the verbose GraphQL query language to obfuscate and “hand wave” away the distance between these various services, the RTT (round trip time) bloat, and the problem of spatially disparate data.

In the case of a highly thought out API / DB storage scenario, for a specific use that is well-defined, the additional layers of REST API calls represent an intentional friction that reminds the client of the need to consider async data fetching strategies. Yes, GraphQL can save you a bit on the RTT of multiple serial API calls, but if that RTT is also a problem internal to the backend data structure / location itself, then attempting to get all of it at once is going to result in a UI that is slower than it would have been with a REST API and a correlating UI that is well thought out in terms of optimizing for fastest user interaction and usefulness.

GraphQL let’s frontend developers write queries directly in the client without being forced to understand the implications of those queries on the server, so it becomes a black box.

Where GraphQL shines is in a microservices use case for making calls to disparate backend APIs. The problem is this greatly increases complexity since you’ll likely want to add a Redis orchestration layer to help reign in that “API internal RTT bloat effect” I was mentioning. A lot of these don’t typically apply to eCommerce, as I’ve noticed working in the space.

In the end, the big question is whether these complexities and risks are eclipsed by the benefit. If your frontend team understands some of these deeper API architecture considerations, it can be a great fit. If they don’t, there’s likely a bumpy road ahead as that team adjusts to the responsibility of thinking like a backend engineer and carrying the weight of those decisions on their shoulders.

Originally posted here:

https://medium.com/@brian.feister/on-the-mis-use-of-graphql-6a300be58037