能否随协议提供 json-schema/proto/openapi 文件方便代码生成

[nnnewb]

主要目的是便于做代码生成，手动对接接口和参数容易出现人为失误，也很繁琐。如果用一些魔术方法写“不繁琐”的代码又容易让编辑器丢失类型或者符号信息，得单独维护一个描述文件，时刻与文档同步。

比如说 nonebot 的 api 是 getattr 套接的，类型单独写了一个 stub 。维护这种函数签名需要手工比较 onebot 协议的文档，一段时间不关注再回头看的话很容易出现 onebot 文档改了但代码里的签名还是旧的，想再跟上协议就又要手工比对一次文档和函数签名了。

希望是能提供协议的描述文件，便于在结构化的协议定义文件基础上做代码生成，方便框架作者维护框架，也能方便协议实现的作者写mock测试。

至于描述文件的格式，protobuf 或者 OpenAPI 我觉得都过得去，这俩原生的代码生成基本都没法直接用，基本还是要自己解析再按需定制生成。

grpc 目前支持的框架少，不过可以自己写脚本解析文件再生成自己需要的代码（比如 js/ts 可以用 protobufjs 自己 parse .proto 再用 mustache/ejs 之类的东西生成）

自己定义描述文件格式也ok，只要方便拿来做代码生成就行

[nnnewb]

此外还有定义数据类型时很容易出现因为协议实现方自己定义了新的字段枚举，结果对没有“正确处理”的框架造成暴击的情况。

例如最近 go-cqhttp 增加的 message_sent 事件没有配套的 message_sent_type （我没记错的话在老 nonebot 实现里叫 detail_type，f'{post_type}_type'这种方式拼出来的 key）

像这种框架作者偷个懒，协议实现者也偷个懒，结果就互相伤害的情况也会发生。我自己从头写的 corebot 就被这问题坑了一次。

[cleoold]

Open api 還不錯，yaml schema 自動化讀取還是挺方便的，而且可以用 swagger 生成還算看得過去（比目前 markdown 強）的 UI。

[klarkxy]

protobuf不就是为了它自己能够生成的一套（几乎）全语言通用的协议封装和解析功能嘛。

[nnnewb]

protobuf不就是为了它自己能够生成的一套（几乎）全语言通用的协议封装和解析功能嘛。

@klarkxy

主要是几个主流实现不支持 protobuf/grpc 的通信，不然直接从 protobuf 生成代码确实会省事一点。

但考虑现在主流的用法不是 http/websocket 么... 那 protobuf 直接生成的代码就基本没法用了。全是 json 硬套 pb 反而麻烦。从目前的生态出发，硬上 GRPC 的话，我个人看法是行不通的。

我自己的预期是能产生一套类似于 async function on(event: 'event1'|'event2'|'event3' ..., function()){} 这样的带类型标注的核心代码或者 stub 就差不多了，协议变化的时候可以在编译期就发现大部分错误。

[klarkxy]

protobuf不就是为了它自己能够生成的一套（几乎）全语言通用的协议封装和解析功能嘛。

@klarkxy

主要是几个主流实现不支持 protobuf/grpc 的通信，不然直接从 protobuf 生成代码确实会省事一点。

但考虑现在主流的用法不是 http/websocket 么... 那 protobuf 直接生成的代码就基本没法用了。全是 json 硬套 pb 反而麻烦。从目前的生态出发，硬上 GRPC 的话，我个人看法是行不通的。

我自己的预期是能产生一套类似于 async function on(event: 'event1'|'event2'|'event3' ..., function()){} 这样的带类型标注的核心代码或者 stub 就差不多了，协议变化的时候可以在编译期就发现大部分错误。

比如golang存在protobuf结构解析到json的库，我相信其他语言也应该存在类似的库。至于两端都用protobuf交互，感觉比较够呛，毕竟现行的大部分框架都是基于json的。