Before you invest in REST and GraphQL

The version of this that works is simpler than the version most people imagine. Before you spend anything on REST and GraphQL, it is worth confirming a few things are already true.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Doing this properly once is usually cheaper than doing it approximately three times.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• REST is simpler to cache and easier to reason about
• You have a way to tell whether it worked

Where it usually goes wrong

GraphQL shines when clients need wildly different shapes of data. The cost of getting this wrong is rarely visible on the day it happens. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The right answer depends on your clients, not on fashion. It is worth being explicit about, because assumptions differ quietly. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

Most development decisions are really maintenance decisions wearing a different hat. 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

Worth checking on your own setup before it becomes someone else's problem to fix.