REST and GraphQL: the questions we get asked most

This is one of those topics that looks small until it costs you something. The questions about REST and GraphQL that come up most often on our calls.

Most development decisions are really maintenance decisions wearing a different hat. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Do we need to care about this?

REST is simpler to cache and easier to reason about. In practice this is a scheduling problem more than a technical one. If it only works because one person remembers to do something, it does not work yet.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. In practice this is a scheduling problem more than a technical one.

How do we know it is working?

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

How to tell if yours is fine

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

If any of that sounds like a description of your current setup, it is fixable.