原生相
基于JSON的双向传输不可知信息.
状态 : 实验性,可以更改.
要点
- * 运输不可知性
- QQ 完全输入域、 方法和事件
- 依据
airtight计划
导言
在软件工程通信协议中被定义为传输信息的正式规则. 现代系统倾向于处理应用级别的协议,如HTTP,这些协议已经被认为是高水平的 OSI 堆栈然而,在实践中,往往需要在现有协议之外执行更多的具体应用或领域协议.
一个广为人知的例子是典型的RESTful API,它实际上是提供功能的应用程序服务器与使用这种功能的前端应用程序之间的协议.
协议不便宜。 良好的协议试图解决很多关注,必须处理相当数量的取舍. 这推动了许多举措,使其他应用协议之上所写的应用协议(如Swagger/OpenAPI,JSON-RPC,gRPC-over-HTTP等)进一步标准化. 此类举措往往具有不同的目标、限制和影响.
该图书馆是一项此类举措,主要考虑如下:
- 它为用TypeScript书写的现代网络应用程序所设计.
- 这类应用可能由许多不同的组件"交谈"相接而成.
- 此类组件可能存在也可能不存在在同一运行时间/进程/节点. 它们可能或可能没有联网层来沟通.
- 来文的一些实例:
- 前端应用程序通过 HTTP 与后端交谈( 即您典型的 Webapp)
- 前端应用程序通过 WebSocket 向后端发送请求并同步接收回复和事件
- 从孤立的iframe发送和接收信件的网页
- 使用 IPC 进行多个进程相互通信
- 两个不同的系统通过TCP互相交谈
- 协议必须具有运输不可知性。 迁移被抽象为可读/可写流. Protocomm将负责将有效载荷进行序列化和去序列化.
- 协议应在通信的两侧完全保密。 我们依靠TypeScript为客户端和Handler提供编译时间类型安全保障.
- 议定书的信息和有效载荷需要在运行时间得到验证。 运行时间验证应当与编译时间验证完全对应.
- 协议信息应当有合理的策略来处理协议的演变.
- 应当有可能从议定书的定义中生成文件.
Protocomm是松散的基于 JSON-RPC 软件公司 并受到 Chrome DevTools 协议 财务报告和审定财务报表 普罗托布夫。 。 。 .
概念
-
通信总是发生在 客户端 (单位:千美元) 处理器。 。 。 .
他们在特定通信中的角色并不相等:客户端总是发起人,通常期望处理者处理多个客户端(尽管这并没有以任何方式执行).
-
议定书 是客户端和汉德勒都需要遵守的接口。 由一个或多个组成 域。 。 。 .
-
域名 是定义 方法 财务报告和审定财务报表 事件。 。 。 .
-
每个域都需要相应的 域定义 ——一个静态JSON对象,在运行时可以获得元数据. 它描述了方法和事件的计划,用于自动生成客户端,验证有效载荷,并用于其他元目的(如文件等).
-
协议索引 是域定义对象的集合,对应特定协议.
协议一般作为双方共享的独立同位素包执行,包含通信中使用的所有实体和DTO的类型定义,计划及域定义. 然后,在"后端"一边使用这种软件包来实施必要的功能,在"消费者"一边生成客户端.
使用量
请参考虚构服务实例的测试设置.
WebSocket 客户端
使用 WsClient 从 @flexent/protocomm 用于输入的 WebSocket 传输.
import { ProtocolIndex, WsClient } from '@flexent/protocomm';
class ApiWsClient extends WsClient<MyProtocol> {
protected get url() {
return 'ws://127.0.0.1:8080/ws';
}
protected get protocol() {
return new ProtocolIndex(myProtocol);
}
protected override shouldReconnectOnClose() {
return true;
}
}
const wsClient = new ApiWsClient();
await wsClient.connect();
await wsClient.client.system.ping({});
WsClient 支持:
- 协议类型d
client由RpcClient - 通过抽象获取器强制协议和 URL
- 重试/重接和套接字创建的绝对默认值