If you had asked me for my opinion on GraphQL in 2019, I would have told you it was the future of working with data. Like many developers, I got caught up in the hype and believed that GraphQL would kill REST and other forms of data endpoint representation.
Fast-forwarding to 2022, my opinion has changed on GraphQL. REST is still very much alive and the preferred approach for API design.
There is a lot to like with GraphQL, and the things it promises on paper are incredible.
- No longer having to create new controllers and routes to expose data on the front-end? Check
- Shifting the power from the server-side to the front, allowing developers to query for what they need? Check
- Precise queries allowing you to query for data you need resulting in smaller payloads? Check
- Type checking and schema introspection? Check
Maybe it’s because I am a front-end developer and my perspective on things is warped. But, having implemented GraphQL quite a few times over the years (especially for blockchain-based projects), you eventually realise that GraphQL is a lot of work.
Now, this is subjective. Some of you using GraphQL might disagree. Perhaps you’ve found a solution that minimises the time it takes to implement GraphQL, and you’re thinking, “Takes more work. What are you on about?”
Using the route/action/controller paradigm found in the traditional REST approach at first seems like more work than the query approach GraphQL promises until you start encountering issues long-resolved in the REST world like caching, security and performance.
For every project I used GraphQL on, there was a recurring theme. I would seemingly get caught up on things long solved in traditional HTTP land. With Apollo Client, you get their hokey-pokey caching solution, but it’s more of a hack. It is possible to use GraphQL over HTTP where the POST requests become GET requests.
Don’t get me started on the rabbit hole of batched queries and rate-limiting (especially when you throw auth into the mix). At this point, you will start delving into persistent queries and data management layers to avoid repetition or recursion. Then you have constraints around depth and query complexity to stop an end-user or developer in your team from writing queries that melt your server or spin up one too many EC2 instances.
While it’s possible a lot has changed in the GraphQL world since I last used it, and many of these problems have been long solved, to set it up correctly, you needed to put a lot of effort in to get a result that is indistinguishable from a standard REST API.
I didn’t give up on GraphQL because I thought it was terrible. I gave up on it because I felt like I was spending more time configuring and running through a checklist of items you don’t have to account for with REST. Once you get GraphQL working, it is fast, efficient and fun, but getting to that point is not fun and burned me out.
Maybe one day, I will revisit GraphQL and see if any of these downsides have been addressed.
