Is There a Point to GraphQL?

I don’t like Facebook, sure.

But hear me out. I’ve no problem with admitting they made some great tools. React/JSX is a killer combo and Redux is amazing too.

The Facebook guys where on a serious roll which is why I think people expected, and some still think, that GraphQL was also a good idea.

I’d like to attempt to explain why it’s not. Now this description isn’t for the faint of heart. It’s a bit technical but give it a try and you might agree with my point…

Picture the following scenario.

At my company we have a frontend team and a backend team. Cool. The backend devs write a REST API using PHP. The frontend devs have a React app with GraphQL.

The frontend interacts with the REST API through AppSync, which is the AWS version of GraphQL middleware.

All the GraphQL “entities” (or type definitions) are defined in AppSync so AppSync controls the shape of every object pulled down from the API to the frontend.

The entities start out similar to the company’s database structure. They’re built to match most of the data as it comes from the API which, in turn, mostly matches the original data from the database.

Over time (about a year and a half) many of the entities in AppSync change, are updated and gradually move further and further away from the actual data stored in the database, which is what the backend PHP devs are most familiar with.

Now, the PHP guys have no reason to go anywhere near AppSync, they don’t code in JS anyway and it would be a relative waste of time to learn just so they can read some AppSync entities.

Up comes the need for a new feature and the backend devs start to work on it. A month or so into the work they meet with the frontend team to see how much work needs to be done to integrate the feature or if there are any breaking changes for them.

Now the frontend team have changed quite a bit since the app was first built, there’s new devs, the lead has left, one member has switched between other areas of the company and returned since, etc. Now no single dev is completely familiar with the full stack, many of the frontend devs have never even seen the database.

Similar changes have happened with the backend team, a new lead has been promoted, the dev who mostly managed AppSync has left, there’s a few new starters, etc.

By now the AppSync entities that the frontend team are familiar with are totally different to the database tables and columns the backend team are familiar with. It’s all the same data but it’s being joined, renamed, split out and mixed up not only by AppSync but also in the REST API, then even again in the frontend to some extent.

The resulting meeting is a total mess, everyone’s confused, no one knows what anyone else is talking about. The feature could break everything and leave the frontend devs having to make hot fixes to the release for the next three months, or everything could be fine and there’s no need to even have the meeting.

Who knows.

So what’s the actual problem here?

There’s way too much technology in this stack. Not only is there an AppSync middleware, there’s also a REST API. But this is kind of my point. GraphQL is just another technology that sits in the middle of your client and db that doesn’t actually do very much.

Graph! Q! L! What is it good for?

When I was first introduced to this query language, I thought: that looks sweet! We can miss out params we don’t need from the frontend, use a single endpoint and control the optimisation of queries without updating the API.

The major set-back though is that you still have to update your API… a lot. It’s not querying your db directly so you have to write a ton of code for every different scenario a frontend dev might use the query for.

Then there’s optimisation. If I miss out a few keys from my query string the API actually has to do more work to strip it out in the middleware. You’re still querying the same number keys from the db.

Finally the single endpoint boon is actually a total bust. If you ever use the Network tab in your browser inspector you’ll know that GraphQL breaks you being able to see what your requests are. They’re all just POSTs to the same endpoint! Totally unhelpful.

So why is GraphQL so popular? Well, the query strings look nice. The idea looks good on the face of things. And of course the major reason being… because Facebook made it (sorry I mean “Meta”).

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Learning Go Lang Days 8 to 12— Building an app that returns random Cat Facts 😸 #100DaysOfCode

What are Kubernetes and its relationship with Containers?

Enemy-Rain Update

Detect overspending by measuring idle Kubernetes resources

Android Development 101 — (Positivity Dose) : Tutorial 1: Hello World

Code Coverage Report (with JaCoCo) in Azure DevOps Pipeline

Google Summer of Code — Final Report

Creating a Video Processing Pipeline in AWS…Part 3

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sean

Sean

More from Medium

A Structured Approach to Designing Intent-Based APIs

Deno.js in production. Key takeaways.

Developers: Your Git will change in 2022, with Dura

Why I avoid async/await

Mark Twain