Intro Thoughts

I’ve been mostly avoiding GraphQL and watching from the sidelines. I’d been forming an opinion but wanted to actually understand it a bit better before really deciding.

Well I’ve just gone through a course on it, and I am very sad to say that my impression has not changed.

GraphQL is, in most cases, a way for teams within your company to avoid discussing their needs with each other. Resulting in massive inefficiencies that are plastered by yet another layer requiring additional maintenance and code. For bonus points, it’s pretty much guaranteed to break because you’re plastering over human communication and coordination problems with technology.

The exception to all this is when you’re building a GraphQL layer to plaster over other companies’ APIs you have no ability to influence. Honestly though, that’s rarely how people are using it.

Promises

Only Retrieve The Data You need

Translation: don’t bother to discuss your needs with the team creating the primary API so that they can create an endpoint that only produces the data you need. Instead do lots of unnecessary calculations in the original API, marshall, and then ship unwanted data over the wire, unmartial, process, and filter that data, to get just the bits you care about.

Fewer requests

Example: Instead of hitting one endpoint, getting a list of objects, and then retrieving each of those objects in separate requests, you can use one GraphQL request.

Translation: don’t bother discussing your needs with the team creating the primary API. Instead, insert additional processing and latency into the system, and convert N requests into N+1.

Get Data in the appropriate shape

Example: The API returns data in structure A, but you need structure B.

Translation: don’t bother discussing your needs with the team creating the primary API. Instead, insert additional processing and latency into the system, and convert N requests into N+1.

Your query’s shape will match the shape of the response

Why is that a good thing? Are you suggesting that It would be better to somehow draw a matrix of values when querying a database instead of using SQL?

How about using query languages that are specific to the domain instead of having no bearing on the domain but having a passing resemblance to the shape of the data coming back.

Moves much of the data filtering and parsing back to the server

Translation: don’t bother discussing your needs with the team creating the primary API. Instead, insert additional processing and latency into the system, and convert N requests into N+1.

An API reference document for people using it

Great, but that’s not unique to GraphQL, and there’s no need to use GraphQL to get that.

Combine data from multiple systems in 1 response

This isn’t bad. However, it does raise a lot of questions around “why” and if it really is a good thing to pretend that it’s one homogeneous thing. I can imagine a number of cases where this is good. I can imagine a number of situations where this is good. They mostly involve lots of microservices which is a thing that lots of companies talk about, few companies do, and most companies that do do regret for a variety of reasons that are mostly not communicating and not thinking about implications of choices in context of the full system.

Subscriptions

Cool. My initial question was “Why is this better than WebSockets?” Turns out, it isn’t. Subscriptions are usually implemented with WebSockets. The “usually” part of that is disturbing as 💩 to me, and raises all sorts of warning flags.

(Implied Promise) Look Ma, it’s almost JSON

1. Either use JSON or don’t. Don’t use some half-assed quasi-JSON thing that promises familiarity via JSON and then promptly kicks you by leaving out commas and colons half the time. Not all the time… just some of the time.
2. The Java geeks thought XML was pretty hot back in 2010. They tried rewriting everything in it too. Look how well that worked out.
3. Use the right tool for the job, not the popular tool. As query languages go JSON, and JSON-like things, are kinda crap.

Counterargument

Yes, but sometimes those other teams can’t give us what we want when we want it.

That’s a human problem that needs human solutions not technology solutions: planning, coordination, prioritization, working together, and being smart enough to not introduce unnecessary tech debt.

If you company’s internal communications are that dysfunctional you should be spending energy on fixing them, not plastering over them with yet another layer of technology that will never solve the fundamental problem. Ditto if the problem is an inability to work together in a coordinated fashion.

Talk to each other. Work together. Don’t try and convince yourself that that’s ever something you can work around with technology.