什么是 TypeScript Remote Procedure Call

tRPC 是一种用于构建类型安全、全栈应用程序的工具，近年来在开发社区中逐渐受到青睐。tRPC 强调使用 TypeScript 类型系统的强大功能来进行 API 开发，它允许前端与后端之间建立无缝、类型安全的通信。本文将通过系统的逻辑推导，逐步揭示 tRPC 的本质、其与其他 API 解决方案的对比，以及它如何改变开发者的 API 开发体验。

• 什么是 tRPC？

tRPC 全称为 TypeScript Remote Procedure Call，是一种基于 TypeScript 类型系统的远程过程调用 (RPC) 框架。与传统的 REST 或 GraphQL API 通信方式不同，tRPC 的设计目标是使前端与后端的通信完全类型安全，且不需要手动编写额外的类型定义或 Swagger 文档。

tRPC 的核心优势在于自动生成类型定义，这意味着前端开发者不再需要为 API 数据结构编写额外的类型。后端的数据结构和函数签名直接通过 TypeScript 类型系统推断到前端，这种自动推断带来了开发体验的提升，并大大减少了出错的可能性。

• tRPC 的设计理念与核心组件

tRPC 的核心理念是减少前后端的类型摩擦，使开发者能够更直接地表达和维护数据结构。它主要通过如下几个部分实现其功能：

1. 类型安全的数据流：tRPC 通过 TypeScript 的静态类型检查来确保前后端数据流的一致性。无论是前端请求参数还是后端返回数据，tRPC 都能利用 TypeScript 的类型检查，在编译时发现可能的类型错误。

2. 轻量级与无 API schema：传统的 API 通常需要一个独立的 schema 定义，例如 REST API 可能需要 Swagger，GraphQL 需要 SDL(schema definition language)。而 tRPC 则完全依赖 TypeScript 的类型系统，这意味着它不需要任何额外的 API 定义文件，减少了项目中的冗余代码。

3. 支持全栈类型共享：tRPC 强调全栈一致性，通过共享类型文件，实现前后端在数据结构上的统一。例如，一个后端的数据库模型可以直接通过类型推断被前端调用，这不仅减少了维护成本，也大大降低了前端获取数据的方式不匹配的可能性。

tRPC 的核心组件主要包括以下几个部分：

• Router：Router 是 tRPC 的基本结构，用于定义不同的 API 端点。每个 router 都包含一系列的 procedure，这些 procedure 定义了与前端进行交互的业务逻辑。
• Procedure：Procedure 是 tRPC 中的一个单元操作，它可以是查询（query）或变更（mutation）。查询用于获取数据，而变更用于修改数据。
• Context：Context 是 tRPC 服务器端的共享上下文，通常用于存储认证信息、数据库连接等。每个请求都能共享这个上下文，以保证相关的依赖可以在请求过程中被访问。

• tRPC 的基本工作原理

tRPC 的工作原理围绕着前端与后端的类型系统共享进行。在 tRPC 中，后端通过 Router 定义 API，然后暴露给前端进行消费。这种模式使得前端在调用 API 时可以直接从编译器中获取类型提示，而不再需要查看文档或者猜测参数的格式。

举例说明，可以考虑一个简单的 Todo 应用：

// backend/trpc.ts

import { initTRPC } from '@trpc/server';

const t = initTRPC.create();

export const appRouter = t.router({
  getTodo: t.procedure
    .input((input: number) => input) // 输入为 number 类型
    .query(({ input }) => {
      return { id: input, title: `Todo #${input}` }; // 返回一个对象，包含 id 和 title
    }),
});

上面的代码展示了如何通过 tRPC 定义一个简单的后端 API getTodo。getTodo 通过类型定义接收一个 number 作为输入参数，返回一个对象。这个对象包含 id 和 title 两个字段。

在前端，消费这个 API 的代码可以这样编写：

// frontend/client.ts

import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';
import type { AppRouter } from '../backend/trpc';

const trpc = createTRPCProxyClient<AppRouter>({
  links: [
    httpBatchLink({
      url: 'http://localhost:3000/trpc',
    }),
  ],
});

async function fetchTodo() {
  const todo = await trpc.getTodo.query(1);
  console.log(todo);
}

在这个示例中，前端通过 createTRPCProxyClient 创建了一个基于后端类型定义的客户端，这意味着在编写 trpc.getTodo.query(1) 的时候，前端开发者可以获得完整的类型提示，包括输入类型和返回类型。这个过程无需手动定义 API 类型，从而提高了开发效率。

• tRPC 与 REST 和 GraphQL 的比较

为了更好地理解 tRPC 的价值，可以将它与常见的 REST 和 GraphQL 进行比较。

• 类型安全：REST API 通常通过 JSON 数据进行通信，虽然可以结合 Swagger 或者 OpenAPI 来进行类型验证，但需要额外的维护工作。GraphQL 可以部分解决类型问题，但前端需要通过 SDL 文件或者 Apollo Codegen 之类的工具生成类型。而 tRPC 的类型系统完全依赖于 TypeScript，在开发者编写代码的时候就可以保证类型的一致性，且无需额外的 schema 文件。

• 开发体验：REST API 的开发体验在于自由和灵活，但缺乏类型安全和文档维护的痛点。GraphQL 在开发体验方面通过单一端点和灵活的查询能力取得了一定的平衡，但也有学习曲线。而 tRPC 通过将类型信息从后端直接暴露给前端，消除了 API 文档和类型不一致的痛苦，提升了开发体验。

• 性能：REST API 的性能在很大程度上取决于设计的 RESTful 原则。GraphQL 在客户端可以自由组合查询，但存在N+1查询的问题，需要使用 DataLoader 等工具来优化。tRPC 采用的是 RPC 远程调用的方式，基于 HTTP 底层协议，因此与 REST 类似，性能较好。由于类型直接在编译阶段进行验证，运行时的性能也更加简洁和直接。

• 灵活性与复杂度：REST API 适合简单的 CRUD 操作，并具有成熟的生态系统。GraphQL 更适合数据结构复杂、需要灵活查询的场景。tRPC 则介于两者之间，它利用 TypeScript 的类型系统减少前后端的类型摩擦，对于需要类型安全的应用场景尤其适合。

• 使用 tRPC 的场景与优势

在了解 tRPC 的工作机制后，可以从实际开发的角度来分析它在哪些场景中最为适用：

1. 全栈应用：tRPC 非常适合那些使用 TypeScript 技术栈的全栈应用。如果前后端都基于 TypeScript，那么使用 tRPC 就能充分发挥类型系统的优势，减少错误，提高开发速度。

2. 敏捷开发：在敏捷开发中，需求和 API 变化频繁。传统的 REST 或 GraphQL 需要不断地维护类型定义、文档等。而 tRPC 通过类型推断实现 API 类型的自动更新，能够有效地应对需求变化。

3. 代码复用：tRPC 允许前后端共享相同的类型定义，这大大降低了重复编写类型的工作量，并确保了类型的一致性，避免了因为类型不匹配导致的问题。对于那些重视代码复用和一致性的团队，tRPC 可以显著减少维护成本。

4. 降低学习成本：对于已经熟悉 TypeScript 的开发者来说，tRPC 并没有太多额外的学习成本。相比 GraphQL 复杂的语法和工具链，tRPC 更加轻量和易于上手。

• tRPC 的实际应用：案例研究

为更好地理解 tRPC 的优势，可以考虑一个较为复杂的案例：一个电子商务平台，包含产品列表、用户评论和订单管理功能。

• 产品服务：通过 tRPC，可以为产品服务创建一个 products 路由，包含查询产品详情、列出所有产品等 procedure。通过类型定义，前端在调用产品 API 时，能直接知道查询的参数和返回的数据类型。

  export const productRouter = t.router({
    listProducts: t.procedure.query(() => {
      return fetchProductsFromDatabase(); // 假设这是从数据库获取产品列表的函数
    }),
    getProduct: t.procedure
      .input((input: number) => input)
      .query(({ input }) => {
        return fetchProductById(input); // 获取指定产品的详细信息
      }),
  });
  

前端使用时，可以很轻松地调用这些 API：

const products = await trpc.productRouter.listProducts.query();
const productDetails = await trpc.productRouter.getProduct.query(5);

• 评论服务：tRPC 也可以处理产品评论服务，比如定义一个 comments 路由，提供 addComment 和 getComments 的功能。利用 tRPC 的类型推断，前端可以明确知道需要的评论数据格式，避免了可能的数据结构不匹配的情况。

  export const commentsRouter = t.router({
    addComment: t.procedure
      .input((input: { productId: number; comment: string }) => input)
      .mutation(({ input }) => {
        return addCommentToDatabase(input); // 将评论添加到数据库
      }),
    getComments: t.procedure
      .input((input: number) => input)
      .query(({ input }) => {
        return getCommentsByProductId(input); // 获取某产品的评论
      }),
  });
  

在上述的应用中，tRPC 带来的类型安全性和类型推断，使得前端开发者在进行 API 调用时，可以享受到与后端开发相同的类型检查，而不需要额外的文档查阅或者接口调试。这一优势在复杂应用中尤为明显，减少了前后端因为接口不匹配导致的 bug，也使开发流程更加高效。

• 使用 tRPC 需要注意的挑战

虽然 tRPC 带来了许多便利，但它也有一些限制和挑战。tRPC 并不是所有场景下的最佳选择，尤其是以下情况：

1. 非 TypeScript 技术栈：tRPC 非常依赖 TypeScript，如果你的项目并没有使用 TypeScript，或者团队对 TypeScript 并不熟悉，tRPC 的优势将大打折扣。

2. 跨语言通信：tRPC 目前是为 TypeScript 服务的，它假定前后端都是 TypeScript。如果你的项目需要和其他语言（例如 Python、Java 等）进行通信，REST 或 GraphQL 可能是更合适的选择，因为它们有更广泛的语言支持。

3. 复杂的 API 需求：在一些非常复杂的场景下，例如需要高度灵活的查询组合，GraphQL 提供的能力可能会比 tRPC 更加合适。tRPC 的 API 定义虽然类型安全，但它仍然遵循传统的 RPC 模式，无法像 GraphQL 那样自由组合查询。

4. SEO 和缓存支持：tRPC 作为 RPC 模式的一种实现，在 SEO 支持和 HTTP 缓存方面，和 REST API 相比存在劣势。传统的 REST API 更容易实现基于 URL 的缓存，而 tRPC 需要依赖一些特定的策略来实现类似功能。

• tRPC 的发展前景

在当前全栈开发的趋势中，tRPC 是一个非常值得关注的工具。它充分利用了 TypeScript 的类型系统，使前后端开发过程更加顺畅，并且减少了由于 API 类型不匹配而导致的错误。尽管它目前仍处于快速发展的阶段，但社区已经在不断丰富它的功能，并且逐步解决它在一些场景中的局限。

tRPC 的最大优势在于类型安全的简洁实现，这使得它非常适合用于中小型、全栈类型共享的应用程序。随着 TypeScript 越来越受欢迎，tRPC 可能会在更多的项目中找到合适的用武之地。