模块管理的问题

[lesismal]

模块管理的问题

[lesismal]

不是要搞大一统，也没办法搞大一统。因为http服务不是中心化的，没法做到一家发版全球更新。
所以这个资源浪费还会存在很多年，软硬件，能源，都浪费挺多的，很不环保

[lxzan]

可以使用go work管理多模块项目

[lesismal]

arpc核心功能是 zero dependency 的，不依赖三方，go.mod只是为了占位。
其他extesion、examples都主要是作为参考，因为关注较少、没有像nbio-examples那样单独拆成一个repo，后续可能会把extension、examples拆出去

[lesismal]

需要 extension examples 定制的，在extension examples 或者用户自己代码目录下的 go mod 就可以了，不污染 arpc 的 zero dependency

[lxzan]

感觉这样不太好, 没指定extension的版本, 如果某个extension变更比较大, 就编译报错了

[lesismal]

这是给用户做参考实现的，并不算是arpc本身的功能

[lesismal]

extension examples这些代码，用户直接拷贝到自己代码里去随意修改就可以了

[lxzan]

好吧

[lxzan]

看了下 extension/protocol/websocket , 感觉抽象开销太高, 直接TCP就行了, protocol下面应该放传输层协议而不是应用层协议. 一般来说, 翻墙软件才需要伪装成WebSocket

[lesismal]

扩展里只是示例，有性能需要的自己定制就行了。
而且你只考虑了rpc场景、性能敏感时的开销问题，但ws很多是针对h5，比如游戏，比如网站论坛推送之类的，简单的业务不是性能敏感的，主要是是方便易用。
其他的定制方式，比如使用ws，你可以看下nbio的定制，自己收到message去handler解析然后OnMessage就可以了：
https://github.com/lesismal/arpc/blob/master/examples/nbio/server/server.go

有特殊需要的场景，我都特殊定制的，比如对RPC有最高性能需求，那可以把arpc再裁剪一下，比如：

1. header可以再简化
2. 中间件那些for循环的逻辑都不需要
3. context也不需要handler结束后还保持生命周期
4. 去掉用户随意使用codec的便利、收到一个body就先解析出来然后再丢给逻辑协程，这样原来的buffer就更好地复用
5. 。。。。

很多细节可以极致，现在的方案是功能丰富且便利用户，并不是性能作为第一性的。有实际业务需要的地方，我都可以做比较极致的优化

[lesismal]

你不要把extension和examples当成定势，那只是我提供的一点示例

[lxzan]

我再看看源码吧, arpc功能比我的uRouter丰富很多, 基本抽象也有很大差异. uRouter仅支持请求-应答模式, 基本抽象是模仿http的Request和ResponseWriter, 抽象开销比较小.

[lesismal]

传统的游戏服务器，或者工业系统上下位机之类的通信协议，都是数值类型做命令号的，小系统1 byte足够，大系统2 bytes也足够，性能更友好，也不需要中间件之类的这些玩意。
只有web领域这些垃圾协议包括RPC采用字符串做router，中间件各种需求。

通信的本质是协议交互，http最早设计成request-response模式非常失误，因为设计得太垃圾，才需要websocket/socketio/webrtc这些去不停打补丁。

所以arpc这种我自己的框架，基本不是去向这些传统的垃圾协议靠拢

[lxzan]

字符串对人友好，二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象，根本原因还是方便，请求应答模式足以应对大多数web/app的交互，不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket

[lesismal]

字符串对人友好，二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象，根本原因还是方便，请求应答模式足以应对大多数web/app的交互，不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket

这都是扯淡的说法，不要人云亦云拿别人整理好的文章思考问题。你上面这些说法是因为已经这样了才这样强行说好。
看二进制内容浏览器和ide一样都能可视化，keepalive一样是长连接复用，反倒是纯短链接几乎没人用，而且框架或者协议在七层提供的用户接口提供这些机制就可以了，谁整天去tcpdump wireshark抓包分析字节流啊？
别听那帮谬论，要懂得自己思考

[lxzan]

经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗

[lxzan]

字符串对人友好，二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象，根本原因还是方便，请求应答模式足以应对大多数web/app的交互，不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket

这都是扯淡的说法，不要人云亦云拿别人整理好的文章思考问题。你上面这些说法是因为已经这样了才这样强行说好。 看二进制内容浏览器和ide一样都能可视化，keepalive一样是长连接复用，反倒是纯短链接几乎没人用，而且框架或者协议在七层提供的用户接口提供这些机制就可以了，谁整天去tcpdump wireshark抓包分析字节流啊？ 别听那帮谬论，要懂得自己思考

如果KeepAlive就能应对一切场景谁还玩心跳啊

[lesismal]

经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗

这个比较是不合理的，tcp pb你是自定义协议，不具备rfc或者统一标准，如果有统一标准，工具里一样可以做到方便修改。json本身是自释义的，你如果http pb一样不方便修改pb，但是工具可以去做导入pb定义然后你只改结构体之类的。

[lesismal]

如果KeepAlive就能应对一切场景谁还玩心跳啊

你搞混了http keepalive 和tcp心跳的含义和用途，这俩没有直接的可比性

[lxzan]

经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗

这个比较是不合理的，tcp pb你是自定义协议，不具备rfc或者统一标准，如果有统一标准，工具里一样可以做到方便修改。json本身是自释义的，你如果http pb一样不方便修改pb，但是工具可以去做导入pb定义然后你只改结构体之类的。

多了一些步骤调试就不如json便捷了, 很多人重视简便胜过性能

[lesismal]

经验之谈, 没看什么技术文章

得出这个结论是因为你以前的主要工作是花在这些curd上了，以自己的舒适区去对比其他没有被广泛优化工具链的场景，但如果早期的http rfc就是二进制，现在的浏览器和社区工具链也一样完善。
考虑现有的东西是否够好，要加上想象，去想想如果不这样可以做哪些可以做到哪些，然后用各自的好来对比。
你再想想如果文本那么好，为什么还要搞2.0和3.0？
2.0这个垃圾就不说了，3.0很优秀

[lxzan]

如果KeepAlive就能应对一切场景谁还玩心跳啊

你搞混了http keepalive 和tcp心跳的含义和用途，这俩没有直接的可比性

HTTP自带的KeepAlive很方便啊, 对用户无感知.

[lxzan]

考虑现有的东西是否够好，要加上想象，去想想如果不这样可以做哪些可以做到哪些，然后用各自的好来对比。

应用层是文本还是二进制对我业务开发流程没有影响, 基本无感知, 日常工作接触最多的是IDL. 考虑到历史进程, HTTP1设计得还不错, XML做IDL是垃圾.

[lxzan]

经验之谈, 没看什么技术文章

得出这个结论是因为你以前的主要工作是花在这些curd上了，以自己的舒适区去对比其他没有被广泛优化工具链的场景，但如果早期的http rfc就是二进制，现在的浏览器和社区工具链也一样完善。 考虑现有的东西是否够好，要加上想象，去想想如果不这样可以做哪些可以做到哪些，然后用各自的好来对比。 你再想想如果文本那么好，为什么还要搞2.0和3.0？ 2.0这个垃圾就不说了，3.0很优秀

就算是同一类协议的不同版本使用场景也不一样, 搞大一统有点费力不讨好了
H3适合API Server不适合CDN

[lxzan]

很多劣质的东西照样流行 😂
例如伪JWT, Restful...
每个人的品味和分辨能力都不一样

[lesismal]

很多劣质的东西照样流行 😂
例如伪JWT, Restful...
每个人的品味和分辨能力都不一样

就是最早的时候没有，一些先驱设计出一些不完善的东西，其他人跟风，就流行了，没办法，大规模的这种就只能交给时间去慢慢替换掉。但咱们不能因为这些东西还算好用就不去追求更好了，单从优劣分析的角度该批评缺点的就批评它，不批评就没有进不了。说不定几十年后AI大一统了很快就把这些糟粕替换掉了:joy:

[lxzan]

流量多吸引新人去尝试, 然后糟粕流行了起来