How to get REST and GraphQL right
This is one of those topics that looks small until it costs you something. The short answer to REST and GraphQL is that it is mostly a sequence of small decisions, not one big one.
Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is the sort of thing that looks like polish right up until it costs you an enquiry.
What it costs to ignore
REST is simpler to cache and easier to reason about. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- GraphQL shines when clients need wildly different shapes of data
- The right answer depends on your clients, not on fashion
- Write down the decision so the next person does not re-litigate it
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. If it only works because one person remembers to do something, it does not work yet.
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
- 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
Pick the one that would hurt most if it failed, and start there.