Graphql: hipster or helpful

Barry Hennessy

I find myself embarking on a brand new, quite sizeable, project. At it’s core it’s got to have a ‘web-app’. Not the usual use case either (an overcomplicated way to render static pages). This will be a resonably complicated application on the backend, rendered and driven using a web based UI.

I’m usually very skeptical of ‘hip’ new technologies. Particularly on the frontend; frameworks can come and go faster than their docs can be written1.

GraphQL has caught my attention however. This blog post is my attempt to figure out if I’m dangerously close to falling into a trap, or if there really is something to the new technology.

So, what’s all the fuss about?

GraphQL, as far as I understand it, purports to provide a single, unified, format for getting data from a server. Or, for that matter, many servers. Clients specify what they want, so it’ll be more efficient when, ineviatably your backend models get just a little bit too fat. It also shifts the N+1 problem onto the client. Which should dramatically reduce the roundtrips needed to render a page.


  1. Never write an endpoint manually again
  2. Request all your data in one go. (Push the roundtrips to the datacenter)
  3. Use any service that speaks GraphQL, not just the clone written in that language you chose at the start
  4. Clients just get the data they want. More efficiency.

What’s the fuss not about?

I am, of course, doing my investigation from my point of view. So there are some arguments I won’t be focussing on, or more to the point: avoiding.

“The big company uses it so I should use it too”

Big companies have big company problems. Scale is great and all, but with great scale comes great headaches2. My preference is strongly for little company problems, little company speed and medium company money.

“Hey guys! GraphQL is the future

I like to believe that the change to define our future will be significantly more profound. Like figuring out how we can all just get along3. GraphQL may certainly help prototype and build Apps, but it won’t fix the world. This is all to say that I’ll do my best to keep my feet on the ground.

Arbitrary measurements

Metrics are important, and I’ll be measuring. But I’ll be focussing on things like gauging how good the documentation is or how the workflow… flows as much as how fast the frameworks are.

Performance of Engineers is a huge factor in a project’s health. Low performance practices yield low performing engineers. And you don’t get high performance products with low performing Engineers.

Scope creep

Nobody likes a creep.

This won’t be exhaustive. There will be guesstimates. Trying to nail down every variable that could apply to writing software is a fools errand4.

I’m focussing on how GraphQL will work for my (reasonably common) use cases. If there are any architectural ‘gotchas’. How long a common setup would take me. How easily it can be automated. How (in)accurate the docs are. Whether or not the selling points we’re being sold on are held up, or as useful as we’re being lead to believe. That kind of stuff.

That kind of thing.

The battle plan

Here are the questions I’ll be asking5. They’ll each get their own post.

  1. I’ll do a good, thourough search of the thoughts already out there before I begin. If there are any big issues lying in wait let’s spot them ASAP.
  2. How quickly can I get a basic server set up and deployed? If their docs don’t get me smoothly through the basics we’re in trouble.
  3. How easy is it to model a reasonably complex setup? I’m interested to know how well this meshes with different data technologies.
  4. How well does it handle writes? Particularly complex, interdependent writes. By GraphQL’s own admission “Most discussions of GraphQL focus on data fetching”.
  5. How well does the interoperability work between languages. I mostly write Go and PHP with a smattering of others, so it’ll be very valuable to be able to mix and match when I need to reach for either software speed or framework speed.

Come along for the ride

Come back in the next few days when I’ll have the first update ready for you.

If you don’t trust your memory, then sign up here and I’ll send you a mail first thing when I publish.

Or, if blow by blow updates are more your thing, follow me on Twitter where I’ll be dropping the most interesting links I find (roughly) daily.

  1. At least, I think that’s their excuse. 

  2. Pro tip: they mostly stem from how to coordinate thousands of engineers performing heart surgery on the same patient at the same time. 



  5. Like the very best of plans, expect it to change at a moments notice.