REST and GraphQL: what to get right first

The gap between knowing this and actually doing it is where most teams lose ground. If you only fix one thing about REST and GraphQL this quarter, make it the first item below.

Most development decisions are really maintenance decisions wearing a different hat. Budget a little time for it every quarter and it never becomes a project of its own.

Start here

REST is simpler to cache and easier to reason about. The cost of getting this wrong is rarely visible on the day it happens. Check it against what you would want a competitor's site to get wrong.

Then this

GraphQL shines when clients need wildly different shapes of data. None of that requires a large budget, only a decision and someone to own it. If two people in the business would answer this differently, that gap is the actual problem.

Eventually

The right answer depends on your clients, not on fashion. That sounds obvious written down. It is still the thing most often skipped. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

In practice

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about REST and GraphQL before you move on:

• Someone can say what the current setup is without going to look
• The right answer depends on your clients, not on fashion — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.