REST and GraphQL for small teams

This is one of those topics that looks small until it costs you something. Most advice about REST and GraphQL assumes a team that does not exist at your size. Here is the version that does not.

The question is rarely whether something can be built, but what it costs to keep running afterwards. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to keep

REST is simpler to cache and easier to reason about. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

Where to start

The right answer depends on your clients, not on fashion. That sounds obvious written down. It is still the thing most often skipped. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

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

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