@nomagick 运行时不按它来，如果是后端，会有多少安全的风险呀！

举个例子，你有一个用户表：

interface User {
  id: string,
  nickname: string,
  avatar: string, 
  // 余额：敏感字段
  money: number
}

然后你实现了一个，更新用户信息接口 UpdateUser，请求参数为：

interface ReqUpdateUser {
    id: string,
  	update: {
		nickname?: string,
  		avatar?: string, 
	}
}

接口实现为：

// 更新数据库
db.User.updateOne({
    where: {
	    id: req.id
	},
	set: req.update
})

在编译时刻，如果你在 UpdateUser 时传了 money，编译器会自动报错，OK 这当然没问题。

但问题在于，这个类型，在运行时是不安全的，这就埋下了很大的安全隐患。

如果前端构造了一个恶意的请求呢：

{
  id: 'xxx',
  nickname: 'xxx',
  money: 99999
}

由于在运行时缺少类型安全机制，则导致敏感字段没有被严格检查，用户可以直接更新自己的余额！ 今天一个小坑，明天一个小坑，串联起来就是系统性的风险。

当然，你可以手动编写逻辑代码，去保证类型安全，但是：

墨菲定律：可能出错的一定会出错

是人总会出错的，所以更好的办法是，在运行时也有一套自动运行的机制，确保输入、输出的类型一定安全。 这可以从根本上，无代价的规避很多系统性的风险。 这也是 TSRPC 出现的根本意义。

@ganshiqingyuan Vue 2.x 可以的哈，不用 TS，纯 JS 项目也能用哈 （只是少了代码提示而已），但仍然有运行时类型检测。

@nomagick

即程序员不能清楚地意识到何时何地，以何种方式进行了参数验证，这是一个巨坑。

只会在 RPC 的请求和响应时刻，针对输入输出做参数验证。

JS的动态性是优势而不是需要去除的缺点。

运行时类型检测并没有去除 JS 的动态性。

TypeScript 本身的类型系统就已经兼顾到了 JS 的动态性，例如 any 类型，又例如：

interface XXX {
    a: string,
	b: number,
	// 允许扩展任意字段
	[key: string]: any
}

TS 类型系统本身的灵活性，让你可以在需要动态的时候动态，需要严谨的时候严谨。运行时类型检测同样也遵循了这一规则。

像你回复的举例，是应用系统，是程序员需要解决的问题，而不是编译器和运行时，甚至通讯库需要解决的问题。再说，参数验证就说参数验证，但你项目不叫RPC么， 这完全就是两码事啊。

类型安全对于跨项目调用，确实是一个需要解决的问题。 例如 NestJS 通过 Decorator 来解决类似的问题。 是否应当在 RPC 框架内完成，这个可能见仁见智，对于二进制序列化的场景它会打包在框架内（例如 gRPC）。

这个RPC协议，不要为了二进制而二进制， 包括base128也好，压缩也好，都是为了提升性能，要么就是省点CPU时间要么省点流量。

您说的没错，没有必要为了二进制而二进制，当在游戏、金融等一些需要进行传输加密的场景会更有用。 所以序列化是一个可选项，它兼容 HTTP/JSON 调用。 但类型安全是刚需所以它是一个必选项。（否则现有的其它框架已经能很好的满足需要）

这些都是在超大规模实施的时候才会凸显出来的成本，但它们的代价却是需要在设计时支付的。而且二进制协议也没必要静态决定结构，静态结构就会涉及到协议版本，这都是处理起来很棘手的问题。

如果使用 ProtoBuf、Thrift 这样的第三方 IDL 静态类型语言定义，确实会引入相当的额外成本。 如果使用 Decorator 来注解类型，也会引入一些额外的成本。 但 TSRPC 不需要这些，只是需要通过 TS 源代码定义协议就可以（协议总是需要定义的）。 当然代价就是需要手动生成一下（也可以通过 watch 来自动生成更新），至于协议版本的问题，也在生成协议的工具里自动处理，大部分时间不需要关心的。 例如 ProtoBuf 中需要关心协议、接口的 ID 序号。 TSRPC 是不需要关心的这些细节的，已经由工具自动完成了。大部分情况下，只需要像没有序列化那样关注新旧类型本身是否兼容，而不需要考虑编码细节。

例如，旧协议：

interface Request {
    a: string,
	b: number
}
interface Response {
	m: string,
	n: number
}

新协议：

interface Request {
    a: string,
	b: number,
	c?: boolean,
	d?: string[]
}
interface Response {
	m: string,
	n: number,
	p: boolean,
	q: string[]
}

类似上面的例子，只要新旧协议在类型层面兼容，则编码层面是自动兼容的。 即便前端是旧版协议，也可以连接新版协议的后端服务正常使用。

一点点自动生成协议的成本，换来输入输出的类型安全，提升安全性并且可以放心的开发业务逻辑，这个交换是值得的。

非常感谢您的反馈，您的建议很具有代表性。 我们在推进的过程中也确实受到了很多类似的担忧和疑问，文档也不够详尽，对这些问题缺少足够的预见。 这也让我们思考，应该如何更好的包装概念，包括 “RPC” 是不是一个很适应的名词。

❤ 感恩的心 ❤

@netwjx 远端就是 NodeJS 上的一个异步函数。

@netwjx

调用远端是通过 HTTP协议/WebSocket? 为什么这么选型, 会有什么优劣

• HTTP 协议可以应付大多数 Web 场景。
• WebSocket 主要适用于有实时需求的场景
  • 例如实时游戏、股票实时行情、实时通知推送、实时聊天等
  • 对于一些后端之间频繁的微服务调用，WebSocket 长连接有更高的连接利用率，能承载更高的 QPS
• TSRPC 从一开始就设计为协议无关的
  • 可以实现一份 API 接口，同时支持短连接和长连接，这对于游戏非常实用
  • 想让它支持原生 TCP 甚至 UDP 都不需要太大的代价，只需要在二进制传输层做一点点改动。

类型检测 发现问题后, 如何做失败处理?

框架会自动返回类型错误信息给调用方（错误信息类似 TS 的类型错误信息），处理方式就跟处理普通网络错误、业务错误一致。

let ret = await client.callApi('XXX', { ... });

// 错误处理
if(!ret.isSucc){
  console.log(ret.err.message);   // 人类可读的错误信息
  console.log(ret.err.type);  // 错误类型：如网络错误、业务错误、还是类型错误等
}

body部分的编码形式?

可选择为 二进制（application/octet-stream） 或 JSON（application/json）

压缩比率? 定量对比?

• 没有进行压缩（即还可以自行通过例如 gzip 等方式进一步减少包体）。
• 编码算法参照了 Google 的 ProtoBuf，编码效率与 ProtoBuf 几乎一致。

编解码性能测试? 定量对比?

• 编解码性能与 Protobuf.JS 近似，没有进行过很详细的定量对比（受实际类型不同有所差异）。
• 阿里云低配服务器，纯编解码吞吐量测试，1 CPU 核在 2500 QPS 左右。
• Macbook Air 2020 M1 款，纯编解码吞吐量测试， 1 CPU 核 5000 QPS左右。
• 目前经过验证的最高并发的线上服务大概是 10 万QPS量级，有一些 MongoDB 和 Redis 的操作，压测结果稳定在 1000 QPS / CPU 以上。

如何在现有服务做小规模实验? 通过 npx create-tsrpc-app@latest 创建出的工程，已经带了一些简单例子。

https://github.com/k8w/tsrpc-examples 和文档里也有少量示例。

近期会整理一下我们的过往项目，公开一些较完整的项目例子（例如带权限验证的管理后台）

如何让现有服务平滑迁移?

就跟前端从 jQuery 过渡到 React 和 Vue 一样，旧项目对于新的技术框架总是一个包袱。 新框架往往最早是从新项目中开始使用的。

如果说衡量利弊后，真的要将旧的后台服务重构一份……

后端：

1. 按照 TSRPC 协议规范整理所有协议
2. API 实现部分
   • 修改获取输入、返回输出的部分
   • 移除类型保护的相关代码（框架会自动检测）
3. 为了旧的前端项目更好的兼容性，可以开启 JSON 兼容模式

前端：

1. 如果是 TS 项目，可以安装 tsrpc-browser 客户端，如此调用协议处有强类型代码提示，重构更容易
2. 对于纯 JS 项目，可以开启后端的 JSON 兼容模式，然后仍然使用 HTTP/JSON 的方式调用新接口

集群如何容灾 防止单点故障?

这个部署层面的问题，与使用其它框架如 ExpressJS、EggJS 一致。

如果服务是无状态服务，那么就非常简单：

• 单机部署，可以使用 PM2 来保证高可用
• 多机器部署，使用云厂商提供的负载均衡即可
• 我们更常用 Kubernetes 集群，更灵活的扩缩容和更自动化的运维，各种方案都比较成熟齐备
• 或者，部署到阿里云或腾讯云的 Serverless 平台也是可以的

有状态服务：

• 目前还有很大的发挥空间
• 云厂商的负载均衡基本都支持 HTTP 协议下的会话保持

上面这些都是基本功能, 还有什么吸引力特性/ 计划?

主要吸引力特性其实是 3 点：

1. 直接基于 TS 源码定义协议

• 支持 TS 复杂类型（例如 Union Type、Pick、Omit 等等），这对于减少类型冗余、避免低级错误非常有用
• 相比于 NestJS，不需要写 Decorator
• 相比于 ProtoBuf、Thrift，省去了第三方语言的学习和维护成本
• 相比于用文档定义协议然后各自实现，代码层面的协议带来的是类型安全，几乎不需要为了低级错误而联调了（如大小写、拼写错误等）
• 协议文件跨项目、跨端共享，全程代码提示

2. 运行时，自动校验参数类型

• 参数类型的校验，对于后端服务的安全性来说毋庸置疑
• TS 在编译时刻的类型检查，无法满足输入不可靠场景下的类型安全（例如 3 楼中的安全漏洞）
• 现在所有其它基于 Decorator 的校验方案，都只能校验简单的基础类型
• TSRPC 是目前唯一支持校验 Union Type、Intersection Type、Pick、Omit、Partial 等这些高级复杂类型的库，它们对于定义协议减少类型冗余非常实用

使用这些复杂 TS 类型，并自动校验类型，能带来什么收益？ 可以参考这个主题分享：

https://www.bilibili.com/video/BV1hM4y1u7B4 ↑↑↑ 跳转到 35:00 ：《以 MongoDB 下的 CRUD 为例，如何更高效的定义 TS 类型》 ↑↑↑

3. 二进制序列化

• 也是目前唯一的，不需要第三方 DTO 语言，并且支持 TS 复杂类型的序列化方案
• 序列化对于有减少包体大小需求（例如实时游戏、实时股票数据），以及有防破解需求（例如游戏、反爬虫）的场景非常实用
• 二进制序列化是一个可选项，可以关闭来实用传统的 JSON 方式

二进制序列化不只是为了减少包体，它比 JSON 支持更多类型，能满足更丰富的业务需要

• 二进制序列化比 JSON 支持更多的类型，这使你可以直接在请求/响应参数中，使用 Date、Uint8Array 等类型。
• 极大的便利就是实现上传文件这样的接口变得非常简单，跟普通 API 接口一样，而不需要关注传输协议细节。
• 例如实现一个 “按键发送语音” 的功能，如果是 Express 的话，需要涉及到 HTTP 处理 multipart/form-data 的繁琐细节；但如果你只是像调用一个本地异步函数一样，传递一个 Uint8Array、ArrayBuffer 呢？

例如：

export interface Req发送语音 {
	uid: string,
	time: Date,
	data: ArrayBuffer	
}

let ret = await client.callApi('发送语音', {
	uid: 'xxx',
	time: new Date(),
	data: buffer
})