DEV Community

Andrew Lee
Andrew Lee

Posted on

3 Reasons Why GraphQL Can Be a Pain

I love GraphQL but it’s not perfect. Here are the three main reasons why it can be a pain.

1. Extra layer of abstraction (more code)

We are adding more code by adding another abstraction layer for the database. We also need to invest time in tooling for both the front-end and back-end as well as learn up on the best practices such as API design and authorization. GraphQL takes more time and more lines of code and the end user will probably not notice the difference...is it worth it?

Counterargument

GraphQL can actually reduce the amount of code written. Instead of managing custom routes, we just have to manage the graph API. Even if GraphQL results in more code and more time, it can actually save us time in the long run. By having a common query language that front-end and back-end can share, the team will be able to iterate faster.

2. Disregard of Traditional HTTP

GraphQL does not follow the rules of HTTP and status codes. For example, making a query in GraphQL is making a POST request with the query as the body. Oh and it's common practice to use 200 status code for all GraphQL requests and use the errors field to propagate any errors that have occurred. This means that we cannot use tools that were designed with the traditional web in mind.

Counterargument

GraphQL is a new technology and it is unfair to write it off because it might be incompatible with tools made for traditional APIs. New technology requires new solutions, and the GraphQL community is continuing to develop tools to handle things such as caching, security, and monitoring.

3. Inefficient querying

While GraphQL is a dream for front-end engineers, it's very hard to optimize for back-end engineers. By allowing flexible queries, we are sacrificing optimization.

If we are comparing data fetching for a specific page, a highly optimized SQL query will be faster than querying the graph. While we can mitigate some inefficiencies of GraphQL by using tools to batch queries, it will always be inferior to an optimized query.

Counterargument

GraphQL is not for every project. GraphQL was initially created to fetch information for network constrained devices. GraphQL allows the front-end to specify data requirements of an entire page and fetch just what it needs in one query. It depends on what we are optimizing for, GraphQL performs better than existing alternatives in certain dimensions.

Top comments (0)