Why We Moved Off REST

Our REST API had grown the way most REST APIs grow: one endpoint per screen, then one endpoint per screen variant, then a scattering of ?include= query params trying to claw back some flexibility.

The over-fetching problem was real

Mobile clients on slow connections were pulling down full user objects to render a single avatar and a name. Multiply that across a feed of fifty items and the bandwidth cost was significant, especially outside major markets.

query FeedItem {
  post(id: "123") {
    title
    author {
      name
      avatarUrl
    }
  }
}

GraphQL let each client ask for exactly what it needed, and nothing else. That part worked as advertised.

What it cost us

• Caching got harder. REST's per-URL caching model doesn't map cleanly onto a single /graphql endpoint — we had to build persisted queries to get CDN caching back.
• N+1 queries moved, they didn't disappear. Without a disciplined dataloader layer, a nested query can trigger a database call per resolver per item.
• Query cost became a security question. A sufficiently nested, sufficiently aliased query can do real damage; we now enforce query complexity limits at the gateway.

None of these are reasons to avoid GraphQL. They're reasons to budget for the operational half of the migration, not just the schema design half.