进一步阅读

这是给谁的？

¥Who is this for?

• tRPC 适用于全栈 typescript 开发者。它使编写 "endpoints" 变得非常容易，你可以在应用中安全地使用它。

  ¥tRPC is for full-stack typescripters. It makes it dead easy to write "endpoints", which you can safely use in your app.

• 它是为 monorepos 设计的，因为你需要从服务器导出/导入类型定义。

  ¥It's designed for monorepos, as you need to export/import the type definitions from/to your server.

• 如果你已经在一个混合语言的团队中工作，或者拥有你无法控制的第三方消费者，那么你应该创建一个与语言无关的 GraphQL-API。

  ¥If you already work in a team where languages are mixed or have third-party consumers over whom you have no control, you should create a language-agnostic GraphQL-API.

与 GraphQL 的关系

¥Relationship to GraphQL

如果你的项目已经有一个自定义 GraphQL 服务器，你可能不想使用 tRPC。GraphQL 太棒了；能够创建一个灵活的 API，让每个消费者都可以只选择他们需要的数据，这真是太棒了。

¥If you already have a custom GraphQL-server for your project, you may not want to use tRPC. GraphQL is amazing; it's great to be able to make a flexible API where each consumer can pick just the data they need.

问题是，GraphQL 并不那么容易做好 - ACL 需要按类型来解决，复杂性分析和性能都是重要的事情。

¥The thing is, GraphQL isn't that easy to get right - ACL is needed to be solved on a per-type basis, complexity analysis, and performance are all non-trivial things.

我们从 GraphQL 中获得了很多灵感。如果你之前构建过 GraphQL 服务器，你将熟悉输入类型和解析器的概念。

¥We've taken a lot of inspiration from GraphQL. If you've previously built GraphQL servers, you'll be familiar with the concepts of input types and resolvers.

tRPC 更加简单，并且将你的服务器和网站/应用更紧密地结合在一起（无论好坏）。它允许你快速移动，无需更新模式即可进行更改，并避免考虑可遍历的图。

¥tRPC is a lot simpler and couples your server & website/app more tightly together (for good and for bad). It allows you to move quickly, make changes without having to update a schema, and avoid thinking about the ever-traversable graph.