Choosing Between REST and GraphQL in 2026

Subject: REST vs GraphQL: the answer changed

Hey there,

In 2020, I recommended GraphQL for every new SaaS API. In 2026, I recommend it for about 20% of them. The technology didn't get worse. The ecosystem around REST got dramatically better, and the hidden costs of GraphQL became clearer at scale.

Here's how the decision tree actually works now.

●This Week's Decision

The Situation: You're designing the API layer for a new product (or refactoring an existing one). Your frontend team wants GraphQL for flexibility. Your backend team wants REST for simplicity. Both have valid arguments, and the wrong choice costs 6-12 months of rework.

The Insight: The deciding factor isn't technology preference ... it's your read pattern. Specifically: how many different shapes of the same data does your frontend need?

Choose REST + OpenAPI when:

• Your API serves 1-3 frontend clients with predictable data needs
• Your responses are mostly flat or shallow-nested (2 levels deep or less)
• You need aggressive HTTP caching (REST's URL-based caching is trivial; GraphQL caching requires Apollo or Relay)
• You're hiring ... the REST talent pool is 5x larger than GraphQL specialists

Choose GraphQL when:

• Your frontend renders deeply nested data from 4+ related entities
• You have a dashboard-heavy product where every user configures different views
• Your mobile and web clients need fundamentally different response shapes from the same data
• You're building a platform where third-party developers query your data in unpredictable patterns

Decision Tree:
                    ┌─────────────────────┐
                    │ How many data shapes │
                    │ does your frontend   │
                    │ need per entity?     │
                    └─────────┬───────────┘
                    ┌─────────┴───────────┐
                    │                     │
                 1-3 shapes          4+ shapes
                    │                     │
              ┌─────┴──────┐       ┌──────┴──────┐
              │ REST +     │       │ Do clients  │
              │ OpenAPI    │       │ need deeply  │
              │            │       │ nested data? │
              └────────────┘       └──────┬──────┘
                                   ┌──────┴──────┐
                                   │             │
                                  Yes            No
                                   │             │
                              GraphQL      REST + BFF

The cost people underestimate with GraphQL: N+1 query prevention (DataLoader is required, not optional), query complexity limiting (without it, a single query can take down your database), and schema evolution (adding @deprecated is easy; removing fields requires client coordination).

One client I advised migrated from GraphQL to REST after 18 months. Their reason: the 3 engineers maintaining the GraphQL layer could instead build features. Their API surface was 40 endpoints ... REST with OpenAPI auto-generated SDKs covered every use case.

When to Apply This:

• Teams making the API architecture decision for a new product or major version
• Organizations evaluating GraphQL adoption where fewer than 20% of queries use nested data
• Companies where API maintenance consumes more than 10% of backend engineering time

●Worth Your Time

1. Shopify: API Design at Scale ... Shopify runs one of the largest GraphQL APIs. Their N+1 solutions are production-tested at millions of queries per hour. If you're going GraphQL, study their DataLoader patterns before writing a line of code.

2. Zalando RESTful API Guidelines ... The gold standard for REST API design. Zalando's guidelines cover versioning, pagination, error handling, and naming conventions. Adopt these wholesale and your REST API will be better than 90% of GraphQL implementations I've reviewed.

3. Vercel: Why We Moved Away from GraphQL ... Vercel's engineering team documented their shift toward tRPC and REST for internal services. The reasoning: type safety without the schema overhead. Relevant for teams considering alternatives to both REST and GraphQL.

●Tool of the Week

Scalar ... Modern API documentation and testing from OpenAPI specs. If you choose REST, Scalar generates interactive docs that rival GraphQL's playground experience. The "try it" feature lets frontend engineers explore your API without Postman, which was the workflow advantage GraphQL had over REST for years.

That's it for this week.

Hit reply with your API's read patterns and team size ... I'll tell you which direction to go. I read every response.

– Alex

P.S. For the complete architecture decision framework covering APIs, databases, and infrastructure: SaaS Architecture Decision Framework.