The real cases when you should avoid GraphQL
A critical perspective: 3 situations where GraphQL isn’t really for you
So, you already know what GraphQL is, you already ran into the book-author-topic example and also the social network one. You are evaluating if GraphQL will simplify your life or will give you a lot of pain. This article could be for you.
Confession: GraphQL is cool and I’m a great supporter of it. It’s good to work with it, and nowadays it’s even common to find it in a frontend-backend stack. The developer experience is a key factor in software development and GraphQL could be great for this. And, nevertheless it’s a growing trend.
But I warn you… I would be careful to make an indiscriminate use. Here are 3 cases in which I really suggest you to avoid it.
In this article I won’t take into account performances and caching issues, lots of people already discussed about this. I will just analyze the standards and the language at a higher level.
If you’re curious about the standard, I invite you to read the specification: https://spec.graphql.org
Case 1
Tables. Those are the most popular tool for visualization since the 90s.
The main issue with tables: they get big fast. Trust me, like the universe, like the node_modules, they tend to expand in all directions.
And then, one day…
- your customer asks you to add filtering and pagination
- your product owner asks you to add sortable columns
- your boss suggests to select a subset of columns
Some years ago we used OData for solving these issues. And nowadays? Sorry, but GraphQL is not the answer.
Its standards don’t describe how to query data in a particular selective way. You don’t have the same expressive power of SQL when you write your GraphQL query.
Hasura, and many other similar products, have extended GraphQL syntax, adding many filtering, ordering capabilities, and that’s great!
The GraphQL queries are magically translated into SQL queries. Be careful, these queries are often dirty heavy long queries. And the truth is that you often end up writing many views and stored procedures. However, in many cases it could be a great solution for tables.
Case 2
GraphQL seems perfect for a new blog or your personal e-commerce. You only get the data you want in a page, for example the data about a product, its vendor, the user settings and so on…
The problem in these situations is the search bar. In GraphQL you haven’t got a way to express “searching” a product or a post.
Let me explain it better…
The user text is not an exact match. A person might misspell a letter or make other typos. And you likely would need to search this text into many fields of many different entities. You may need fuzzy search.
How the hell you could do this with GraphQL?
Well, GraphQL doesn’t natively support search. GraphQL is perhaps more suitable for “sharp” queries, like for example “get the book no. 43 with its author details”.
Even here, some provider extended the raw GraphQL interface with custom results filtering. We can mention, for example AWS App Sync. The issue is that: it’s not in the standard, so everyone can implement this in a custom way. And everyone does it!
Case 3
Imagine you want to perform an action which will not change the Graph state.
For example: the user forgets the password and you want to send him a mail with the reset link. You don’t want to bother yourself adding a mail_recovery node/table. In this case you ask yourself: Shall I use a Query, a Mutation or a Subscription?
None of the previous…
Other similar cases are when your application will be connected to third party APIs, or when you want to change data outside of your graph but you have just a single GraphQL endpoint.
For example files. GraphQL does not describe any standard for file uploading or file handling, so you have to make do.
Other aspects
Other people blame the language for being complex and its learning curve is steep. I really don’t agree, these two factors are irrelevant.
I found GraphQL easy to learn and to use. If you are familiar with JSON it will be a child’s game to master GraphQL, trust me.
The Alternatives
REST? RESTful? Yes, sure, but what about all the network requests?
Well, this is an old misconception. HTTP 2.0 allows us to perform as many* parallel connection we want, so maybe it’s not worth worrying too much about network traffic.
* Keep in mind that we always have limitations. In Firefox the limit of parallel connections is typically 100.
In my opinion, the best way to transcend GraphQL limits could be the hybrid approach: We might build an e-commerce in GraphQL with a REST API just for searching products. But of course you would need to develop, test, deploy, mantain and authenticate two endpoints.
Conclusions
Maybe the GraphQL standard is deliberately light, or maybe it’s still a bit raw. Anyway, we notice that it’s not as expressive as others standards.
I really suggest you to make an open choice. Don’t be too strict with interface coherence, because sometimes it can harm. To choose a hybrid solution is not so bad in the end.
