# REST vs GraphQL vs tRPC: which API style to choose in 2026

*By Roberto Lazar, founder of Dock30 · Published 2026-08-02 · Updated 2026-08-02 · 6 min read*

A practical guide to REST, GraphQL, and tRPC for founders and technical leads: what each style is, where each wins, and which one to pick in 2026.

For most teams shipping in 2026, REST is still the right default, tRPC is the stronger pick when your frontend and backend live in one TypeScript codebase, and GraphQL only earns its complexity once several different clients read from a genuinely tangled data graph. REST still powers about **93%** of the APIs teams report shipping, per [Postman's 2025 State of the API report](https://www.postman.com/state-of-api/2025/). The other two solve real problems. Neither is a free upgrade, and choosing on hype instead of on how your clients actually read data is the most expensive mistake in this decision.

We have built backends on all three since 2021, across dashboards, ecommerce, and mobile apps. The pattern that holds up is unglamorous: match the API style to who is calling it, not to the framework with the best conference talks.

## Start with what each one is

REST is the one you already know. You model your data as resources, you act on them with HTTP verbs (GET, POST, PATCH, DELETE), and each endpoint returns a fixed JSON shape. Every language, proxy, browser, and monitoring tool understands it without help, which is most of why it refuses to die.

GraphQL is a query language that sits behind a single endpoint. Instead of the server deciding what each URL returns, the client sends a query describing the exact fields it wants, and gets back that shape and nothing else. You define a typed schema once, and every client reads from it. That flexibility is the whole point, and also the whole cost.

tRPC is the odd one out, because it is not a wire format at all. It is a TypeScript library that lets your frontend call backend functions as if they were local, with the argument and return types inferred straight from the server code. No schema file, no code generation. The catch is in the name: it only works when both sides are TypeScript. A Swift app or a partner's Python service cannot speak it.

## When REST is the right default

Reach for REST when anyone outside your own codebase will call the API: a public endpoint, a partner integration, a webhook receiver, or a mobile app you might rewrite in a different language later. The tooling and the OpenAPI documentation conventions mean a new consumer can be productive in an afternoon, without you handing over a custom client.

A REST call is about as legible as an API gets:

```http
GET /api/invoices/42
Authorization: Bearer <token>
```

The honest weakness is over-fetching and under-fetching. That endpoint returns the whole invoice even when a list view only needs the total and the status, and a screen that wants an invoice plus its customer plus recent payments makes three round trips. For most apps that waste is small, and the fix is dull but effective: add a couple of purpose-built endpoints for your heaviest screens. You start eyeing GraphQL when you are doing that on every screen, not on two of them.

## When tRPC wins

If your frontend and backend are one TypeScript project, usually a monorepo, tRPC is the least friction you can buy. You get end-to-end type safety with no schema language and no build step. Rename a field on the server and the client stops compiling until you fix it.

```ts
// server
export const appRouter = router({
  invoiceById: publicProcedure
    .input(z.object({ id: z.number() }))
    .query(({ input }) => db.invoice.findUnique({ where: { id: input.id } })),
});

// client: fully typed, no codegen
const invoice = await trpc.invoiceById.query({ id: 42 });
```

That `invoice` is typed from the database query all the way to the component, and nobody wrote a type by hand. tRPC v11, released in March 2025, added prefetch helpers that fit the Next.js App Router and React Server Components, and the project now clears 700,000 weekly npm downloads, per its [release announcement](https://trpc.io/blog/announcing-trpc-v11). It pairs naturally with the [Next.js and NestJS stack](/blog/fullstack-nextjs-nestjs-postgres-railway) we deploy most often. The limit is real, though. The moment a non-TypeScript client shows up, tRPC has nothing to say to it, and you are back to REST or GraphQL for that surface.

## When GraphQL earns its complexity

GraphQL is worth its weight when you have many different clients reading from one complex, interconnected data graph, and each client wants a different slice. Picture a web dashboard, an iOS app, an Android app, and a partner API, all hitting a data model where a customer has orders that have line items that have products that have suppliers. Letting each client ask for precisely the fields it needs, in a single request, genuinely beats maintaining a dozen bespoke REST endpoints.

```graphql
query {
  invoice(id: 42) {
    total
    status
    customer { name }
  }
}
```

One request, exactly those fields, across as many nested relationships as you want. That is the over-fetching problem solved at the protocol level. Gartner expects more than 60% of enterprises to run GraphQL in production by 2027, up from under 30% in 2024, per the [report Apollo republishes](https://www.apollographql.com/resources/gartner-when-to-use-graphql-to-accelerate-api-delivery), and most of that is GraphQL sitting in front of existing REST and gRPC services, not replacing them.

What the tutorials skip is the bill. You now own a schema, a resolver layer, query-depth and cost limits so a client cannot ask for the entire database in one query, and a caching story more involved than REST's because every request hits the same URL. On a small team with one client, that is a lot of machinery guarding against a problem you do not have. REST still shows up in about 93% of API stacks and GraphQL in 33%, again per Postman, which tells you most teams add it selectively rather than switch.

## The tradeoffs in one table

| | REST | GraphQL | tRPC |
|---|---|---|---|
| Best fit | Public, partner, and mobile APIs | Many clients, one complex data graph | One TypeScript codebase, internal API |
| Client support | Every language and tool | Any language with a GraphQL client | TypeScript only |
| Typing | Manual, or generated from OpenAPI | Generated from the schema | Inferred automatically, no codegen |
| Over-fetching | Possible, fixed per endpoint | Solved by design | Not an issue, you write the query |
| Main cost | Extra endpoints for heavy screens | Schema, resolvers, caching, query limits | Locked to TypeScript on both ends |

No row here is a knockout. Each is the actual trade you are making, and the right answer moves with who your callers are.

## What we reach for, and when

Our default stack is TypeScript end to end, so on a new product where we own both the frontend and the backend, we usually start with tRPC and add a thin REST layer for webhooks, third-party callbacks, and anything public. That covers the large majority of what founders come to us for. We only pull in GraphQL when a client genuinely has the surface area to justify it: several distinct consumers, a deep data graph, and a team that will maintain the schema after we hand it over. Picking GraphQL before you have those clients is how a two-person team ends up maintaining infrastructure built for Netflix.

If you are early, the cheapest correct answer is almost always REST or tRPC, and you can migrate a busy screen to GraphQL later without rewriting the app. We scope this the same way we scope everything: fixed-scope [custom development](/services/custom-development) projects start at **EUR 350**, with the exact price and delivery date in writing before any work begins ([project pricing](/pricing/project)). The API-layer decision is usually an hour of the first conversation, and getting it right early saves the rewrite a wrong pick forces a year in. If you want a sense of what the surrounding build costs, we broke that down in [what custom software costs in 2026](/blog/custom-software-cost-2026).

If you are staring at this decision for your own product and want a second opinion before you commit, book a [free 15-minute call](https://calendly.com/dock30/15min) or reach us through the [contact page](/contact). Tell us who will call your API and what your data looks like, and we will tell you which of the three we would use, and when one of them is plainly overkill. Sometimes the right answer is the boring one, and we will happily say so.

## Frequently asked questions

**Should I use REST, GraphQL, or tRPC in 2026?**

Default to REST for public and third-party APIs, use tRPC when your frontend and backend share one TypeScript codebase, and reach for GraphQL when several different clients query a complex data graph. REST still powers about 93% of the APIs teams report shipping. Most products want one primary style plus a small REST layer for webhooks and integrations.

**Is tRPC better than REST?**

For an internal app where the client and server are both TypeScript, tRPC removes a lot of boilerplate and gives you end-to-end type safety with no code generation. It is not better for public APIs or for any client written in another language, because tRPC is not a language-neutral standard. Many teams run tRPC internally and expose REST at the edges.

**What is the over-fetching problem with REST?**

A REST endpoint returns a fixed shape, so a screen that needs three fields from a large object still downloads the whole object, and a screen that needs data from three resources makes three requests. GraphQL fixes this by letting the client ask for exactly the fields it wants in one request. For most apps the waste is small enough that REST plus a couple of tailored endpoints is fine.

**When is GraphQL worth the extra complexity?**

GraphQL earns its cost when you have many different clients, such as web, mobile, and partners, reading from a complex, interconnected data graph with varying needs. It adds a schema, a resolver layer, caching work, and query-cost limits that a small team with one client does not need. Gartner expects more than 60% of enterprises to run GraphQL in production by 2027, mostly alongside REST rather than instead of it.

**Do I have to choose only one API style?**

No, and most production systems do not. A common 2026 setup is tRPC or GraphQL for the internal frontend and a small REST surface for webhooks, third-party integrations, and public endpoints. Picking a primary style matters more than picking a single one.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact