Five mistakes teams make with REST and GraphQL

Every audit we run turns up some version of this. These are the ones we run into repeatedly when we audit REST and GraphQL.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• REST is simpler to cache and easier to reason about
• GraphQL shines when clients need wildly different shapes of data
• Never checking whether the fix actually worked

The right answer depends on your clients, not on fashion. None of that requires a large budget, only a decision and someone to own it. Assume whoever inherits this will have half your context and none of your patience.

Turning this into a decision

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about REST and GraphQL before you move on:

• Someone can say what the current setup is without going to look
• REST is simpler to cache and easier to reason about — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.