How should we choose between REST and GraphQL for internal API with caching?

[Riley70]

I’m trying to decide between using a RESTful design or GraphQL for a new internal service API, and I’m stuck on how to handle future changes without breaking existing clients. The flexibility in querying seems great, but I’m worried about the complexity of implementing things like caching and rate limiting properly.

[James70]

We built the internal API with standard HTTP endpoints and versioned paths. It kept contracts clear, and a gateway could cache responses and enforce rate limits without much drama. When something changed, we marked endpoints deprecated and left them alive for a quarter as teams migrated, which helped avoid breaking users all at once.

[JohnTM]

We tried GraphQL for flexibility, and the idea of asking for just the fields you need sounded great in theory. In practice the caching got hairy because caches at the endpoint level couldn’t tell apart which fields mattered, and we wound up a tangle of persisted queries and hand-tuned cache keys. We did a few weeks of tuning and some teams dropped back to the old style because it slowed dev velocity.

[BrandonAM]

I wonder if the real problem is the API surface or the way teams coordinate changes. Maybe we’re fighting over contracts more than data needs. We’ve had talks where a single broken client forces a suppression across many teams, and it makes me wonder if governance and contract testing would help more than picking a tech?

[John64]

We ran a small prototype mixing both ideas: keep the old endpoints for stability while exposing a new path that handles common use cases with more flexible payloads. Measured latency stayed flat, but the new path added dev toil when teams tried to use it for exotic queries. We decided to ship with a narrow scope and watch adoption before expanding.