Dev Note

Introduction
“What API technology should we use?” remains one of the most debated architecture decisions in software engineering. In 2026, the answer is no longer simply “REST”—organizations are increasingly running heterogeneous API architectures: REST for external-facing APIs, gRPC for internal service communication, and GraphQL Federation for unified client data access.
This post cuts through the hype to give you a practical decision framework. We’ll cover the real strengths and weaknesses of each approach, the specific scenarios where each wins, and the patterns for combining them effectively in a modern distributed system.
Photo by imgix on Unsplash
The Landscape in 2026
All three paradigms are mature. The tooling story:
Paradigm
      Key Tools 2026
      Adoption Trend
    
REST
      OpenAPI 3.1, Hono, FastAPI, Spring Boot
      Stable, default choice
    
gRPC
      gRPC-Web, Connect, buf.build
      Growing in internal services
    
GraphQL
      Apollo Federation 2, Grafbase, The Guild
      Growing for unified APIs
    
The new contender worth watching: tRPC for TypeScript-to-TypeScript type-safe APIs (full-stack monorepos). Not covered in depth here but worth a look if your stack is TypeScript end-to-end.
REST in 2026
REST is not dead—it remains the lingua franca of the web. Every HTTP client can consume it. Every developer understands it. Its limitations are well-known and manageable.
When REST Wins
1. Public/Partner APIs
If third-party developers will consume your API, REST is the right answer. The ecosystem of documentation tools (OpenAPI → Swagger UI, Redoc, Scalar), client generation, and debugging tooling is unmatched.
2. Simple CRUD Operations
For services that map cleanly to resources with standard CRUD operations, REST is simple to implement, test, and reason about.
3. HTTP Caching
REST is the only paradigm with native HTTP caching semantics (ETag, Cache-Control, Last-Modified). For read-heavy APIs with cacheable responses, this is a significant operational advantage.
4. Browser Clients Without a BFF
REST works directly in browsers without client libraries. fetch() is all you need.
REST Pain Points in 2026
Over/under-fetching: Clients receive either too much data or need multiple requests
API versioning: /v1/, /v2/ proliferation is messy
Type safety across services: Without strict schema enforcement, drift happens
Modern REST: OpenAPI-First Development
The best practice in 2026 is OpenAPI-first development:
# openapi.yaml - define first, generate code second
openapi: 3.1.0
info:
  title: Order Service API
  version: 1.0.0
paths:
  /orders/{id}:
    get:
      operationId: getOrder
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Order found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Order'
        "404":
          $ref: '#/components/responses/NotFound'
components:
  schemas:
    Order:
      type: object
      required: [id, customerId, status, items]
      properties:
        id:
          type: string
          format: uuid
        customerId:
          type: string
        status:
          type: string
          enum: [pending, confirmed, shipped, delivered, cancelled]
        items:
          type: array
          items:
            $ref: '#/components/schemas/OrderItem'
Generate server stubs and client SDKs from this spec. The schema becomes the contract, not an afterthought.
gRPC in 2026
gRPC has found its niche: internal service-to-service communication where performance, strong typing, and bidirectional streaming matter.
When gRPC Wins
1. High-Throughput Internal Services
Protocol Buffer serialization is 3–10x more efficient than JSON. For services processing millions of messages per day, this compounds into meaningful cost and latency savings.
2. Streaming APIs
gRPC supports four call types: unary, server streaming, client streaming, and bidirectional streaming. These map naturally to real-time data feeds, file uploads, and interactive protocols.
// events.proto
service EventStream {
  // Unary: single request, single response
  rpc GetEvent(GetEventRequest) returns (Event);
  
  // Server streaming: single request, stream of responses
  rpc SubscribeToEvents(SubscribeRequest) returns (stream Event);
  
  // Bidirectional streaming: interactive protocol
  rpc ProcessEvents(stream EventCommand) returns (stream EventResult);
}
3. Polyglot Microservices
Protobuf schemas generate clients in Go, Python, Java, TypeScript, and more—all type-safe and consistent. No more “what does this JSON field mean?” discussions.
4. API Contract Testing
Proto files are your contract. Breaking changes are detectable at compile time with buf breaking:
# buf.yaml
version: v1
breaking:
  use:
    - FILE  # Detect breaking changes
# In CI:
buf breaking --against '.git#branch=main'
gRPC Pain Points
Browser support: gRPC-Web adds overhead; the Connect protocol (from Buf) is the better 2026 answer
Observability: gRPC error codes are less intuitive than HTTP status codes for operators
API exploration: No browser-native tooling (Postman/Insomnia helps, but friction exists)
Connect Protocol: gRPC for the Modern Web
The Connect protocol from Buf deserves special mention. It’s compatible with gRPC but also works natively over HTTP/1.1 and is directly callable from browsers:
// TypeScript client - works in browsers AND Node.js
import { createClient } from "@connectrpc/connect";
import { EventStreamService } from "./gen/events_connect";
const client = createClient(EventStreamService, transport);
// Works directly in browsers without proxy layer
const event = await client.getEvent({ id: "evt_123" });
// Streaming also works
for await (const event of client.subscribeToEvents({ topic: "orders" })) {
  console.log(event);
}
GraphQL Federation in 2026
GraphQL Federation is the answer to a specific problem: when you have many microservices and need clients (especially web and mobile) to access data across them without building a custom aggregation layer for every new feature.
Apollo Federation 2 and Grafbase are the mature options. The concept: each service owns its slice of the schema and defines how it connects to other services’ types.
The Federation Model
# order-service subgraph
type Order @key(fields: "id") {
  id: ID!
  status: String!
  customerId: String!
  # Reference to User type owned by user-service
  customer: User!
  items: [OrderItem!]!
}
# user-service subgraph
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
  # Reference to orders owned by order-service
  orders: [Order!]!
}
# product-service subgraph
type Product @key(fields: "sku") {
  sku: String!
  name: String!
  price: Float!
  inventory: Int!
}
The Router (Apollo Router or Grafbase Gateway) automatically composes these schemas and generates an optimized query plan:
# Client makes ONE query
query GetOrderDetails($orderId: ID!) {
  order(id: $orderId) {
    id
    status
    customer {        # Fetched from user-service
      name
      email
    }
    items {
      quantity
      product {       # Fetched from product-service
        name
        price
      }
    }
  }
}
The Router figures out which services to query, in what order, and how to combine the results. The client doesn’t need to know about the service boundaries.
When GraphQL Federation Wins
1. Multiple Clients with Different Data Needs
Mobile clients need minimal data (preserve bandwidth). Web needs richer data. Federation with per-client query optimization handles both without building multiple API endpoints.
2. Rapid Frontend Development
Frontend developers can query exactly the data they need without backend changes. This unblocks frontend iteration cycles significantly.
3. Cross-Domain Data Access
When features naturally span multiple domains (an order page showing order status + customer info + product details + shipping status), federation eliminates the need to build and maintain custom aggregation endpoints.
GraphQL Federation Pain Points
N+1 problems: Without DataLoader or Federation’s @provides/@requires hints, naive implementations generate explosion of downstream queries
Caching complexity: GraphQL’s POST-based queries don’t benefit from HTTP caching (though persisted queries help)
Operational complexity: Debugging a query that spans 4 services is harder than debugging REST
Schema governance: With multiple teams owning subgraphs, breaking change detection and schema review processes are essential
The 2026 Decision Framework
Is this a public or partner API?
└── YES → REST with OpenAPI 3.1
Is this internal service-to-service?
├── High throughput / need streaming → gRPC (or Connect)
└── Lower volume / CRUD / simple → REST (lighter weight)
Do you have multiple clients (web, mobile, partner) needing 
different views of cross-domain data?
└── YES → GraphQL Federation
Is your entire stack TypeScript (frontend + backend)?
└── Consider tRPC for type safety across the boundary
The Realistic Architecture
In practice, most modern organizations run all three in their stack, each playing to its strengths:
External clients (web, mobile, third-party)
         │
         ▼
  [GraphQL Federation Router]
  (unified API for client-facing needs)
         │
    ┌────┴────────────────┐
    │                     │
    ▼                     ▼
[REST APIs]          [gRPC services]
(external-facing     (high-perf internal
 partner APIs,        service mesh:
 simple CRUD)         events, search,
                       ML inference)
The key insight: these aren’t competing choices—they’re complementary layers serving different needs in the same system.
Practical Migration: Moving from REST to Federation
If you’re adding Federation to an existing REST architecture, you don’t have to migrate everything at once. The Subgraph Wrapper pattern:
// Wrap an existing REST service as a Federation subgraph
import { ApolloServer } from '@apollo/server';
import { buildSubgraphSchema } from '@apollo/subgraph';
import { gql } from 'graphql-tag';
const typeDefs = gql`
  extend schema @link(url: "https://specs.apollo.dev/federation/v2.0", import: ["@key"])
  
  type Order @key(fields: "id") {
    id: ID!
    status: String!
  }
  
  type Query {
    order(id: ID!): Order
  }
`;
const resolvers = {
  Query: {
    order: async (_, { id }) => {
      // Delegate to existing REST API
      const response = await fetch(`http://order-service/api/orders/${id}`);
      return response.json();
    }
  },
  Order: {
    __resolveReference: async ({ id }) => {
      const response = await fetch(`http://order-service/api/orders/${id}`);
      return response.json();
    }
  }
};
This lets you incrementally add Federation capabilities while keeping existing REST contracts intact.
Conclusion
The API architecture debate of 2026 isn’t “which one wins”—it’s understanding the specific strengths of each paradigm:
REST: Default choice for simplicity, public APIs, HTTP caching
gRPC: Internal services needing performance, streaming, or polyglot type safety
GraphQL Federation: Client-facing unified API layer across multiple domains
The winning architecture for most organizations combines all three, with clear guidelines for engineers on when to use each. Invest in the governance and tooling (OpenAPI enforcement, buf lint, Federation schema checks) to keep each layer healthy as your system evolves.
What API architecture does your organization use? Have you adopted Federation? Would love to hear about your experiences in the comments.
References:
Apollo Federation Documentation
Buf Build (Protocol Buffers tooling)
Connect Protocol
OpenAPI 3.1 Specification
tRPC

GraphQL Federation vs REST vs gRPC: Choosing Your API Architecture in 2026

댓글