---
title: "tRPC vs Hono RPC vs ts-rest: Choosing Type-Safe APIs in 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2029-05-26"
category: "Technology"
tags:
  - tRPC vs Hono RPC vs ts-rest
  - type-safe APIs TypeScript
  - tRPC 2026
  - Hono RPC edge API
  - ts-rest contract-first API
excerpt: "REST and GraphQL aren't going anywhere, but TypeScript-first API layers are quietly replacing both for teams that want end-to-end type safety without the ceremony. Here's how tRPC, Hono RPC, and ts-rest actually stack up."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/trpc-vs-hono-rpc-vs-ts-rest"
---

# tRPC vs Hono RPC vs ts-rest: Choosing Type-Safe APIs in 2026

## Why TypeScript-First API Layers Exist

If you've ever changed a REST endpoint's response shape and then spent an hour hunting down the three frontend components that broke, you already understand the problem. Traditional REST gives you zero compile-time guarantees that your client and server agree on data shapes. GraphQL improves this with schemas, but it adds a query language, a resolver layer, code generation steps, and a runtime that parses and validates every request.

TypeScript-first API layers take a different approach entirely. Instead of generating types from an external schema, they share types directly between your server and client through TypeScript's own type system. You define a procedure or endpoint on the server, and the client knows the exact input and output types at compile time, with no codegen step, no schema file, no build pipeline to maintain.

Three tools dominate this space in 2026: **tRPC**, **Hono RPC**, and **ts-rest**. They solve the same core problem but make very different tradeoffs around runtime overhead, framework coupling, OpenAPI compatibility, and deployment targets. Picking the wrong one can lock you into architectural decisions that are painful to reverse six months later.

![Developer writing TypeScript code for a type-safe API layer on a laptop screen](https://images.unsplash.com/photo-1555949963-ff9fe0c870eb?w=800&q=80)

This guide breaks down each tool's strengths, weaknesses, and ideal use cases so you can pick the right one before you write your first endpoint.

## tRPC: End-to-End Type Safety With Zero Schema

tRPC pioneered the idea of removing the API boundary altogether. You write a function on the server, and the client calls it as if it were a local function. The types flow automatically through TypeScript's inference, meaning you never write a single type annotation for your API contract.

### How It Works

On the server, you define "procedures" using a router. Each procedure is either a query (read), mutation (write), or subscription (real-time). You attach input validation with Zod, and tRPC infers the output type from whatever your function returns. The client imports the router's type and gets full autocompletion, error types, and input validation, all without generating any code.

In practice, this means you can rename a field in your database query, and your IDE immediately shows red squiggles in every component that references the old name. That feedback loop is measured in milliseconds, not in "run the codegen script and hope it catches everything."

### Where tRPC Excels

tRPC is unmatched in monorepo setups where your frontend and backend live in the same TypeScript project. Next.js App Router, T3 Stack, and Turborepo projects all benefit enormously. The developer experience is the best in class: autocomplete works across the full stack, refactoring is fearless, and there is genuinely zero boilerplate for adding a new endpoint.

The v11 release (stable since late 2025) brought significant improvements. Procedure-level middleware, better error handling with typed error codes, and a new streaming API for server-sent events made tRPC viable for more complex applications. Bundle size dropped to roughly 12KB gzipped on the client side.

### Where tRPC Falls Short

The biggest limitation is that tRPC is not HTTP. It uses HTTP as a transport, but your procedures don't map to REST endpoints. There are no GET /users or POST /orders URLs. This means you can't generate an OpenAPI spec, you can't use standard API testing tools like Postman without workarounds, and third-party consumers who aren't running your TypeScript client are out of luck.

If you ever need to expose your API to mobile apps built in Swift or Kotlin, to partners, or to any non-TypeScript consumer, tRPC becomes a wall. You'll end up building a separate REST or GraphQL layer alongside it, which defeats the purpose.

tRPC also couples you to its ecosystem. The client is tRPC-specific, the server adapter ties into your framework, and the patterns don't transfer to other API paradigms. For teams that value portability, this is a real concern.

## Hono RPC: Lightweight, Edge-Native, and OpenAPI Compatible

Hono started as a lightweight web framework for Cloudflare Workers, but it's grown into one of the most versatile server frameworks in the TypeScript ecosystem. Its RPC feature takes a different approach from tRPC: instead of replacing HTTP semantics, it layers type safety on top of standard HTTP routes.

### How It Works

You define routes using Hono's standard routing API with Zod validation. Hono infers the types from your route definitions and exposes them through a client helper called **hc** (Hono Client). The client calls look like regular HTTP requests, but the input and output types are fully inferred from the server definition.

The key difference from tRPC is that every Hono RPC endpoint is a real HTTP endpoint. GET /api/users/123 actually exists. You can hit it with curl, test it in Postman, and document it in an OpenAPI spec. The type safety is a compile-time bonus, not a runtime requirement.

### Where Hono RPC Excels

Hono's runtime footprint is tiny. The core framework is under 14KB, and the RPC client adds roughly 2KB. For edge deployments on Cloudflare Workers, Deno Deploy, Vercel Edge Functions, or AWS Lambda@Edge, this matters. Cold start times stay under 5ms in most benchmarks, compared to 50ms or more for heavier frameworks.

The OpenAPI compatibility is a major advantage for teams that need to support multiple consumers. The **@hono/zod-openapi** package lets you generate a full OpenAPI 3.1 spec from the same route definitions that power your RPC client. One codebase, two interfaces: typed RPC for your TypeScript frontend and a standard REST API with documentation for everyone else.

Hono also runs everywhere. The same code deploys to Cloudflare Workers, Deno, Bun, Node.js, AWS Lambda, and Fastly Compute. No framework-specific adapters, no platform lock-in. If you're building a service that might move between runtimes, Hono gives you that flexibility without sacrificing type safety.

### Where Hono RPC Falls Short

Hono's type inference is shallower than tRPC's. Nested objects, union types, and complex Zod schemas sometimes lose type information at the client boundary. The hc client doesn't support subscriptions natively, so real-time features require additional tooling like WebSocket libraries or SSE helpers.

The ecosystem is also younger. tRPC has years of community patterns, middleware libraries, and integration guides. Hono's RPC feature is well-documented but has fewer battle-tested patterns for complex scenarios like optimistic updates, infinite scroll pagination, or offline-first architectures.

![Server infrastructure dashboard showing edge computing nodes across global data centers](https://images.unsplash.com/photo-1504868584819-f8e8b4b6d7e3?w=800&q=80)

## ts-rest: Contract-First With REST Semantics

ts-rest takes a philosophically different approach from both tRPC and Hono RPC. Instead of inferring the contract from server code, you define the contract first as a standalone TypeScript object. Both the server and client then implement that contract, and TypeScript enforces that neither side deviates from it.

### How It Works

You create a contract using ts-rest's **initContract** function. The contract defines every endpoint's method, path, path parameters, query parameters, request body, and response shapes. This contract is a plain TypeScript file with no runtime dependencies. It can live in a shared package that both your server and client import.

On the server side, you implement the contract using ts-rest's adapters for Express, Fastify, Next.js, or Nest.js. The adapter enforces that your implementation matches the contract. On the client side, ts-rest generates a typed client from the same contract. If you add a required field to an endpoint's response, both the server implementation and every client call will show type errors until they're updated.

### Where ts-rest Excels

The contract-first approach shines in distributed teams. When your frontend and backend are owned by different teams, or when multiple services need to agree on an API surface, having a single source of truth that's enforced by the compiler eliminates entire categories of integration bugs. The contract can be versioned, reviewed in pull requests, and published as an npm package.

ts-rest generates OpenAPI specs directly from the contract, making it straightforward to produce API documentation, generate SDKs for non-TypeScript consumers, and integrate with API management platforms like Kong or AWS API Gateway. The generated spec is complete and accurate because it comes from the same contract that your code compiles against.

For teams migrating from REST, ts-rest is the easiest on-ramp. Your endpoints keep their REST semantics (GET, POST, PUT, DELETE with proper status codes), so existing API knowledge, tooling, and patterns transfer directly. You're adding type safety to REST, not replacing REST with something else.

### Where ts-rest Falls Short

The contract definition is boilerplate. For every endpoint, you're writing the path, method, request schema, and response schema before you write any implementation code. In a large API with hundreds of endpoints, this contract file becomes its own maintenance burden. tRPC achieves the same type safety with significantly less code.

Performance overhead is slightly higher than Hono RPC. ts-rest's runtime validation layer adds 1 to 3 milliseconds per request in benchmarks, which is negligible for most applications but relevant for high-throughput services handling thousands of requests per second. The client bundle is approximately 8KB gzipped, sitting between Hono (2KB) and tRPC (12KB).

## Head-to-Head Comparison: Performance, DX, and Ecosystem

Numbers matter more than narratives when you're choosing infrastructure. Here's how the three tools compare across the dimensions that actually affect your project.

### Bundle Size and Runtime Overhead

Hono RPC wins on raw size: roughly 2KB for the client, and Hono's server core is 14KB. tRPC's client weighs about 12KB gzipped, with the server adding 20 to 30KB depending on adapters. ts-rest's client is approximately 8KB, with server adapters ranging from 5 to 15KB. For most web applications, these differences are irrelevant. For edge functions with strict size limits (Cloudflare Workers caps at 1MB compressed), Hono's size advantage becomes meaningful.

Request processing speed follows a similar pattern. Hono handles roughly 120,000 requests per second on a single Node.js core in benchmarks, compared to 85,000 for ts-rest's Fastify adapter and 70,000 for tRPC with its Fastify adapter. These numbers shift depending on middleware chains and validation complexity, but the relative ordering is consistent.

### Type Inference Depth

tRPC's inference is the deepest. Discriminated unions, recursive types, and complex Zod transforms all flow correctly from server to client. Hono RPC handles most common cases well but can lose inference on deeply nested response objects or union types with more than four variants. ts-rest's inference is limited by whatever you put in the contract, so depth depends on how detailed your Zod schemas are.

In practical terms, tRPC catches more bugs at compile time. If your API returns **{ status: "active" | "suspended" }** and you check for **"inactive"** on the client, tRPC flags it immediately. Hono RPC and ts-rest catch this too if your Zod schema is specific enough, but the experience is less seamless.

### Framework Compatibility

tRPC integrates deeply with Next.js, Nuxt (via community adapters), and SvelteKit. Its React Query integration is mature and widely used. However, tRPC is essentially tied to the React ecosystem for first-class support.

Hono RPC is framework-agnostic on the server and runtime-agnostic for deployment. The client works with any frontend because it returns standard fetch Promises. You can use it with React, Vue, Svelte, or vanilla JavaScript without special adapters.

ts-rest has official adapters for Express, Fastify, Next.js, and Nest.js, plus community adapters for most other server frameworks. The client integrates with React Query, Vue Query, and Angular's HttpClient, giving it the broadest official framework coverage of the three.

### OpenAPI Generation

This is the clearest differentiator. tRPC has **no native OpenAPI support**. The community **trpc-openapi** package exists but requires manual annotations and doesn't cover subscriptions. Hono RPC generates OpenAPI 3.1 specs through the **@hono/zod-openapi** middleware with minimal extra configuration. ts-rest generates OpenAPI specs directly from the contract with full coverage, including path parameters, query strings, request bodies, and response types.

If external API consumers or auto-generated documentation are requirements, tRPC is the wrong choice. Full stop.

![Code comparison on a monitor showing API endpoint definitions across different TypeScript frameworks](https://images.unsplash.com/photo-1461749280684-dccba630e2f6?w=800&q=80)

## Migration Paths: Getting From REST or GraphQL to Type-Safe APIs

Most teams aren't starting from scratch. You have an existing REST API with dozens of endpoints, or a GraphQL server with resolvers you've been maintaining for years. The migration path matters as much as the destination.

### Migrating From REST

ts-rest is the smoothest migration from an existing REST API. Your endpoints keep their paths, methods, and status codes. You define a contract that describes your current API surface, implement the contract on the server (which is mostly wiring up your existing handlers), and gradually move clients to the typed client. You can migrate one endpoint at a time, running old and new implementations side by side.

Hono RPC requires rewriting your route handlers in Hono's style, but the endpoints remain standard HTTP routes. If your existing API is in Express, the migration is mostly mechanical: swap **app.get** for **app.route** patterns and add Zod validation. The resulting API is backward-compatible with existing consumers.

tRPC requires the most invasive migration. Your REST endpoints become procedures, your URL structure disappears, and existing non-TypeScript clients break. For internal APIs where you control all consumers, this is fine. For public APIs, it's a non-starter without maintaining a parallel REST layer.

### Migrating From GraphQL

All three tools replace GraphQL's flexibility with simpler, more constrained patterns. If your frontend heavily relies on [GraphQL's ability to query exactly the fields it needs](/blog/graphql-vs-rest-api), you'll need to create purpose-built endpoints for different views. This is actually a good thing for performance and maintainability, but it requires rethinking your data fetching strategy.

tRPC's procedure model maps well to GraphQL resolvers. Each resolver becomes a procedure, and your React Query hooks barely change. The T3 community has extensive guides for this migration path, and many teams report completing it in one to two sprints for mid-sized applications.

ts-rest and Hono RPC require more upfront design work because you're defining explicit endpoints instead of resolvers. The tradeoff is a simpler, more predictable data layer that's easier to cache, monitor, and debug in production.

### Gradual Adoption Strategies

All three tools support incremental adoption. tRPC can run alongside your existing API server using its standalone adapter. Hono can mount sub-applications, letting you add type-safe routes to an existing Express or Fastify server. ts-rest's contracts can describe a subset of your API, leaving the rest as untyped endpoints until you're ready to migrate them.

The key is to start with new features. Build your next endpoint with the type-safe tool, validate the developer experience with your team, and then decide whether to migrate existing endpoints. Rewriting a working API just for type safety rarely justifies the risk.

## When to Use Each Tool: Decision Framework

After working with all three tools across client projects, here's the honest recommendation for each scenario.

### Choose tRPC When

- Your frontend and backend are in the same TypeScript monorepo

- You're building with Next.js, especially the App Router

- You control all API consumers and they're all TypeScript

- Developer experience and iteration speed are your top priorities

- You don't need OpenAPI specs or external API documentation

The classic example is a SaaS application built by a small team (2 to 8 developers) using the T3 Stack. tRPC eliminates so much boilerplate that it noticeably accelerates feature development. Teams consistently report shipping features 20 to 30 percent faster compared to REST with manual type definitions.

### Choose Hono RPC When

- You're deploying to edge runtimes like Cloudflare Workers or Deno Deploy

- Bundle size and cold start times are critical constraints

- You want type safety but need standard HTTP endpoints underneath

- Your API serves both TypeScript clients and external consumers

- You're building microservices that might move between runtimes

Hono is the right pick for [API-first architectures](/blog/api-first-development) where the service layer needs to be fast, portable, and accessible to multiple consumer types. It's also the best choice for serverless functions that serve as standalone API services, where every kilobyte of bundle size and every millisecond of cold start time affects cost and user experience.

### Choose ts-rest When

- Your frontend and backend are owned by different teams

- You have an existing REST API and want to add type safety incrementally

- OpenAPI documentation and SDK generation are hard requirements

- You need to support multiple server frameworks or might switch frameworks

- Your organization values contract-first API design

ts-rest is ideal for larger organizations where the API contract serves as a communication tool between teams. The contract file becomes a living document that's versioned, reviewed, and published, similar to how [TypeScript itself provides guardrails](/blog/typescript-vs-javascript) for large codebases.

### When to Stick With REST or GraphQL

None of these tools make sense if your API consumers aren't primarily TypeScript. A mobile app built in Swift talking to a Python backend gets zero benefit from tRPC, Hono RPC, or ts-rest. Similarly, if your team has heavy investment in GraphQL tooling (Apollo Federation, Hasura, or similar) and it's working well, switching for type safety alone isn't worth the disruption.

These tools solve a specific problem: eliminating the gap between what your server sends and what your client expects in TypeScript-to-TypeScript communication. If that gap isn't causing you pain, you don't need any of them.

## Making the Call for Your Team

The TypeScript-first API layer you choose will shape your development workflow for years. tRPC gives you the fastest developer experience in a monorepo at the cost of HTTP portability. Hono RPC gives you the lightest runtime with real HTTP endpoints at the cost of shallower type inference. ts-rest gives you the most structured, team-friendly API design at the cost of more upfront boilerplate.

All three are production-ready in 2026. All three are better than manually syncing types between your client and server. The right choice depends on your team size, your deployment targets, and whether external API consumers are on your roadmap.

If you're unsure which direction fits your stack, or if you're planning a migration from REST or GraphQL to a type-safe API layer, we can help you evaluate the options against your specific constraints. Our team has shipped production applications with all three tools and can save you weeks of experimentation.

[Book a free strategy call](/get-started) and we'll walk through your architecture together.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/trpc-vs-hono-rpc-vs-ts-rest)*