Three myths about REST and GraphQL

There is no clever trick in this one, just a handful of decisions worth making deliberately. A few things about REST and GraphQL that get repeated more often than they get checked.

Most development decisions are really maintenance decisions wearing a different hat. If it only works because one person remembers to do something, it does not work yet.

“It only matters for big sites”

REST is simpler to cache and easier to reason about. The cost of getting this wrong is rarely visible on the day it happens. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

“We can deal with it after launch”

Sometimes true, usually expensive. Getting it slightly wrong is survivable. Ignoring it entirely is not.

“Our platform handles it”

The right answer depends on your clients, not on fashion. 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.

What this looks like day to day

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

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