REST vs GraphQL, architecture and API design
Back to Blog
Engineering Jan 30, 2026 · 7 min read

Why We Switched From REST to GraphQL (And Then Switched Back)

A candid retrospective on API architecture decisions, tradeoffs, and what we'd recommend for new projects in 2026.

GraphQL shines when clients need flexible aggregates and you are willing to invest in schema design, caching strategy, and operational tooling. For our dashboard-heavy product, it eliminated a lot of over-fetching and version churn on mobile.

Where we struggled: complexity at the edge. CDN caching is straightforward with REST URLs; with GraphQL, you need disciplined patterns (persisted queries, GET for safe operations) or you lose simplicity gains.

We moved back to REST for public third-party integrations and kept GraphQL for our first-party apps. Hybrids are underrated, pick the interface that matches the consumer.

For greenfield APIs in 2026, we still like REST with OpenAPI for public contracts, and optional GraphQL internally when product teams iterate fast on read models. Dogma helps no one.