@
coderxy #37
> 比如不只是 server 之间可以用、client 也可以请求 server
> -你这个指的是 grpc 编译生成 client?
不是。
是指用户直接访问，比如 web 前端直接请求：
https://github.com/lesismal/arpc/blob/master/examples/webchat/chat.html#L81> 比如 server 也可以直接推送数据给 client 、client 也可以只推送数据不需要 server response
> -grpc 的双向数据流模式
> -grpc 一样做吧，这个业务场景跟协议没啥关系。IM 都可以用 grpc 的双向数据流模式写，如果你想的话。
> 比如可以做的业务类型也不限于微服务，游戏、IM 、推送各种业务都可以做
这倒确实是可以，但使用起来更麻烦，普通的推送服务还好。
复杂点的业务比如游戏，每个协议包也都可能是不同的 CMD/Method/Router ，你可能需要在 stream 基础上再二次封装一道 router handler 的逻辑
> 比如 arpc 不限制序列化方式，相同或者不同的 method 的每次请求都可以是不同的序列化，甚至也可以直接使用一段 buffer
> -grpc 的自定义编码集
> 中间件之类的也都支持，而且是支持两个维度的中间件：编解码、路由，用户可以自己定制、扩展更多东西
> -grpc 的 Interceptor?
你说的这些，很多需要再扩展之类的，像我这种不熟悉它们的"小白"去研究怎么扩展就已经很难受了，而 arpc 里这些默认是开箱即用了，另外还有性能因素。
> 或者这么说吧，正常大家能想到的常用的场景，grpc thrift 这种级别的项目基本上都已经有了，都不用想的。 所以，切勿闭门造车。
闭门造车这个词，建议也先对比下，如果造出来的比原来的差，那确实没必要，如果造出来的比原来的好，那就不叫闭门造车了。
反倒是建议你，不要闭关锁国、多开眼看看世界比较好吧
另外，百度、腾讯、字节各种大厂，也都有开源自己的 rpc ，就像你前面举例大厂都用 api gateway 来做论点一样，我想以彼之道问你一句：这些大厂自己造 rpc 而不是直接用 google 家的、它们算不算是闭门造车？
请不要说它们是大厂有资格闭门造车，我个人太弱没这个资格。还是前面的论点：不要虚空用 xxx 在做这种逻辑来辩论，要用实际的好坏来做逻辑
再另外，我还真就喜欢造车，但造的东西肯定也不是为了瞎折腾，而是为了能解决一些痛点：
https://github.com/lesismal/nbiohttps://www.v2ex.com/t/945827