自荐一个 js 通信的包

缘起

我的工作内容有写网页游戏，游戏涉及到前后端通信，没找到顺手的通信包，所以手写了一个通用的 js 通信包：remote。

feature

本地可以是浏览器、服务器，甚至一些受限的 js 子集
远端可以是任何终端，如 iframe / Java 服务器等
- 只要远端能跟 js 通信，就能使用该包
对远端响应的数据格式也不严格限制（可以集中解析）
已在公司游戏前后端通信中应用，极大地降低了通信成本（简化调用）
ts 类型严格

调用示意


// 远端
remote.register('something', async (params: Whatever) => {
  return WhatYouWant
})

// 本地
// res === WhatYouWant
const res = await remote._.something(xxx)

与 rpc 相比的优势

不局限于与服务端的通信，无论对方是任何端，只要能与 js 通信，就能使用该包；
相互通信，不存在“主从”的概念，通信双方是平等的；
类型严格；
包较底层，对项目整体的侵入较小，几乎不限制对方的响应的数据格式（因为可以自由解析对方的响应，即自由 emit ）；

协议

由于通信双方是平等的，所以 B 调用 A 的流程也是一样的

更多信息

详见 @zimi/remote/README.md

xiaoming1992

225 天前

@zangbianxuegu 普通的浏览器-服务端通信，倒降低不了什么成本，因为浏览器和服务器的通信，一般是单向的，且频率较低，所以成本本来就不高。

这个包的应用场合是，比如你有 main 页面和 iframe 页面，现在需要在 main 页面访问 iframe 中的一些函数，用了这个包，就可以在业务里写出诸如：`await remote._.xxx(anyData)`这样的代码，像使用本地函数一样，使用远端的函数，提高代码可读性，减少格式代码。

xiaoming1992

214 天前

@forty 目前原则上是不欢迎广播的，只能指定一个 targetId 。但应该可以通过 hack 的方式，把 targetId 当成 groupId 来使用，在 onEmit 函数中针对 groupId 来做群发

这个库是比较底层的，你在业务上可以声明发送给哪个 id ，至于针对这个 id ，如何发送、实际发送给谁，是你自己在 onEmit 函数中自定义的，所以应该是可以实现的

但是，这样子没法处理群发后的响应，例如，你在业务上把 `1+1` 群发给 5 个远端，结果 3 个远端响应值为 `2`，另外 2 个远端抛错了，那业务上应该返回成功还是失败呢？不好处理。

HongXinss

210 天前

不知道我的理解对不对，和 RPC 异曲同工，和业务通信的模块只要有类似收发的模块，就可以自定义适配器，然后双方之间的调用方式从事件触发模式变成了调用本地方法模式，两端互相暴漏方法，那么另一方就能直接调用，主要提升了可维护性，不需要再通过双方各定义事件和处理逻辑，只需要写好自己的业务并暴漏即可。