Introduction: Three Paradigms, Three Kinds of “Who Gets to Decide”#

API design debates are rarely about technical superiority—they’re more about who holds the control:

• REST: The server decides. The server defines resource endpoints one by one, and the client can only fetch data in the shape of those endpoints—too much wastes bandwidth, too little requires another request.
• GraphQL: The client decides. The client submits a query tree, and the server returns data shaped exactly like that tree—not one field more, not one field less.
• tRPC: The type system decides. No IDL, no schema files—the server’s function signatures compile directly into the client’s type hints. Rename a field, and the frontend immediately fails to compile.

The latter two both solve REST’s most criticized problems—over-fetching and under-fetching—but they take two completely opposite paths: GraphQL trades a runtime interpreter for flexibility, while tRPC trades away cross-language capability for zero-cost type safety.

Below, the same business scenario is written out in all three paradigms.

Unified Scenario: Blog Detail Page#

The page needs to display an article’s title, body, author name, and the latest 3 comments. The data lives in three tables: posts, users, comments.

1
GET /api/posts/42 HTTP/1.1
2
Accept: application/json

1
{
2
  "id": 42,
3
  "title": "API design paradigm comparison",
4
  "body": "...",
5
  "authorId": 7
6
}

1
GET /api/users/7
2
GET /api/posts/42/comments?limit=3&sort=desc

1
// GET /api/post-page/42
2
app.get('/api/post-page/:id', async (req, res) => {
3
  const post = await db.posts.findById(req.params.id);
4
  if (!post) return res.status(404).json({ error: 'Not Found' });
5

6
  // Fetch authors and comments in parallel to avoid serial waiting
7
  const [author, comments] = await Promise.all([
8
    db.users.findById(post.authorId),
9
    db.comments.findByPost(post.id, { limit: 3, sort: 'desc' }),
10
  ]);
11

12
  res.json({
13
    id: post.id,
14
    title: post.title,
15
    body: post.body,
16
    author: { id: author.id, name: author.name },
17
    comments: comments.map(toCommentDTO),
18
  });
19
});

1
GET /api/posts/42?include=author,comments&fields=title,body&comments.limit=3

1
type User {
2
  id: ID!
3
  name: String!
4
}
5

6
type Comment {
7
  id: ID!
8
  body: String!
9
  author: User!
10
  createdAt: String!
11
}
12

13
type Post {
14
  id: ID!
15
  title: String!
16
  body: String!
17
  author: User!
18
  comments(limit: Int = 10, sort: SortOrder = DESC): [Comment!]!
19
}
20

21
enum SortOrder { ASC DESC }
22

23
type Query {
24
  post(id: ID!): Post
25
}

1
query PostPage($id: ID!) {
2
  post(id: $id) {
3
    title
4
    body
5
    author { name }
6
    comments(limit: 3, sort: DESC) {
7
      body
8
      author { name }
9
    }
10
  }
11
}

1
const resolvers = {
2
  Query: {
3
    post: (_, { id }) => db.posts.findById(id),
4
  },
5
  Post: {
6
    author: (post) => db.users.findById(post.authorId),          // Once per post
7
    comments: (post, { limit, sort }) =>
8
      db.comments.findByPost(post.id, { limit, sort }),          // Once per post
9
  },
10
  Comment: {
11
    author: (comment) => db.users.findById(comment.authorId),    // Once per comment ← N+1
12
  },
13
};

1
import DataLoader from 'dataloader';
2

3
const userLoader = new DataLoader(async (ids) => {
4
  const rows = await db.users.findByIds(ids);
5
  const byId = new Map(rows.map((u) => [u.id, u]));
6
  return ids.map((id) => byId.get(id) ?? null); // Order must match the input arguments
7
});

1
Comment: {
2
  author: (comment) => userLoader.load(comment.authorId),
3
}

1
import { initTRPC } from '@trpc/server';
2
import { z } from 'zod';
3

4
const t = initTRPC.create();
5

6
export const appRouter = t.router({
7
  postPage: t.procedure
8
    .input(z.object({ id: z.string() }))
9
    .query(async ({ input }) => {
10
      const post = await db.posts.findById(input.id);
11
      if (!post) throw new TRPCError({ code: 'NOT_FOUND' });
12

13
      const [author, comments] = await Promise.all([
14
        db.users.findById(post.authorId),
15
        db.comments.findByPost(post.id, { limit: 3, sort: 'desc' }),
16
      ]);
17

18
      return {
19
        title: post.title,
20
        body: post.body,
21
        authorName: author.name,        // Note: return a flat structure directly
22
        comments: comments.map((c) => ({ body: c.body })),
23
      };
24
    }),
25
});
26

27
export type AppRouter = typeof appRouter;

1
import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';
2
import type { AppRouter } from './server/router';
3

4
const trpc = createTRPCProxyClient<AppRouter>({
5
  links: [httpBatchLink({ url: '/api/trpc' })],
6
});
7

8
const page = await trpc.postPage.query({ id: '42' });
9
page.authorName;   // ✅ Auto-completed, type is string
10
page.author;       // ❌ Compile error: Property 'author' does not exist

Side-by-Side Comparison#

The Real Pitfalls of Each#

REST’s pitfall is evolution. Deleting a field is nearly impossible—you never know which caller is still reading it. Once the authorId returned by GET /api/posts/42 is public, it’s a de facto contract. In practice, the approach is “adding fields freely, deleting fields cautiously, breaking changes go through a new version.”

GraphQL’s pitfall is runtime cost. Clients can freely compose query trees, which means they can also compose a malicious one:

1
query Evil {
2
  post(id: 1) { comments { author { posts { comments { author { posts { ... } } } } } } }
3
}

Cyclic nested queries can bring down your database. In production you must do three things: query depth limiting, node-count-based complexity scoring (rejecting queries that exceed a threshold), and mandatory persisted queries (only allowing execution of pre-registered query texts). Additionally, GraphQL authorization is trickier—post(id: 1) { author { email } } needs permission checks in each field resolver, rather than a one-time check at the routing layer.

tRPC’s pitfall is boundaries. It assumes “same repo, same language for frontend and backend” as a default premise. Once you want to expose an API to external parties, you have to write a separate REST or GraphQL gateway alongside tRPC—and at that point you’ll start wondering whether you should have just gone with OpenAPI in the first place.

Choosing Your Approach#

Answer the following questions in order, and basically only one answer will remain:

1. Are the only consumers your own TypeScript frontend? → If yes, tRPC—the developer experience crushes the other two.
2. Are there non-JS consumers (mobile, third parties, partners)? → If yes, rule out tRPC.
3. Do client data requirements vary widely, or are there so many pages that aggregation endpoints can’t keep up? → If yes, GraphQL (typical scenarios: multiple clients sharing one API, frontend field requirements changing frequently).
4. Everything else → REST + OpenAPI. It’s the most boring and most stable choice: CDN caching works directly, debugging with curl is enough, any language, any era can integrate. Boring is a virtue here.

A pragmatic combination is layering: expose REST or GraphQL externally, use tRPC internally for the parts where frontend and backend are isomorphic; the GraphQL gateway then aggregates downstream REST microservices. These three paradigms are not mutually exclusive religions, but different tools at different boundaries.

Conclusion#

The point of divergence among the three paradigms is really just one: Who decides the shape of the returned data, and when? REST has the server decide at deploy time, GraphQL has the client decide at request time, and tRPC has the type system decide at compile time. Once you think clearly about “who best understands the data shape” in your system and “how frequently that shape changes,” choosing becomes less a matter of taking sides.

References#

• GraphQL Official Docs — Introduction to GraphQL
• GraphQL Official Docs — Security: Query Depth and Complexity Limiting
• DataLoader — Official GitHub Repository (solving N+1 queries)
• tRPC Official Docs — Introduction
• OpenAPI Specification 3.1
• Microsoft Azure Architecture Center — API design best practices
• GraphQL over HTTP Specification