还是看桥水的报告吧，帮机构管理财产得，分析有很大的参考价值

挺多 分叉 开源项目， 结果后面还是没有商业公司支持的好， 比如 es ，redis

macos 有强制退出快捷键

@glcolof 你要求太低了， 这种手机最好不要钱，gv 免费送大家。

@flamingooo 把公司换成大陆公司， 你说是不是炒作概念？

废了，浏览器炒作一波三折，跑路

@ios 兄弟 我只是业余玩玩 不是真的闲得慌。 这种需求最好自己动手 😀😀

@KiraMaple

grpc 在浏览器使用需要 grpc-web 或者 grpc-gateway , 不支持 http2.0 根本无所谓.

这算是美国版的讲故事 ?

@huayi2 哈哈, 业余时间开发的, 欢迎反馈.

@liuhaibin
老哥， 说一句公平的话。 你太年轻了。 和儿子亲还是女婿亲呢？ 儿子都搞不定的事儿， 你女婿能搞定吗？

最关键的是楼主老哥现在失业了。 这种情况明显是他儿子的优势更大， 更加有钱， 承担多一点的责任可能更好的。 一点都不承担肯定是部队的， 钱可以出， 但是人来了楼主老哥都是职工， 哪有那么多的时间处理家事。

@ios 只能秒

首先，大多数应用程序的架构是先有网页，再进行服务器交互，因此大部分接口都是基于 REST HTTP 的设计。为了让 gRPC 支持网页调用，通常需要使用 gRPC-Gateway 或 gRPC-Web 来实现 Web 和 gRPC 协议之间的转换。那么问题来了，为什么谷歌不将所有网页接口设计为使用 gRPC-Web 调用呢？为什么不将文件上传也改为使用 gRPC （这里打个比方，手动狗头，大家自行想象）？

如果我是架构师，我的项目从一开始就是这样设计的，我是否会直接选择 gRPC ？项目成员是否会对此提出异议？这是否会被视为一种不合理的设计？

使用 gRPC 带来了哪些好处？

项目的开发过程往往是先发现问题，再寻找解决方案。

那么架构师会发现哪些问题？

1. 双向通信太麻烦， 要么使用 websocket 要么使用 http2, 有没有替代品？
2. 对多语言适配 sdk 太繁琐了， 能不能为多语言混合直接生成 sdk, 增加请求体的约束减少人力投入文档和 sdk 的编写？
3. 对性能和带宽以后一定要求



架构师在这个时候考虑到，Protocol Buffers （ protobuf ）作为一种跨平台的交互协议，可以为每种语言生成不同的 schema ，并返回 protobuf 的流式数据。这样，即使使用 HTTP 也能实现高效的交互。谷歌正是看到了这一点，于是基于 protobuf 和 HTTP/2 开发了 gRPC 这一规范性框架。通过 CI 工具为不同平台生成各种语言的 schema ，同时为网页生成通用的库。


上面这些东西是不是太超前？


1. 大部分是小企业， 一般就会固定开发语言，不可能出现一家公司 go, java, nodejs, ruby, cpp, python 来相互调用 sdk .
2. 对外提供的接口太少，小公司可能连文档都没有，都是口头约定。 即是接口多，直接使用 swagger 之类的 openapi 生成一份 http 文档即可，根本不需要投入太多的人力去编写不同语言的文档和 sdk,
3. 业务也没有双向通信的场景。
4. 网关使用 gzip 、Zstd 也能够达到节省带宽。

我就问一问，你是架构师你会怎么选？ 没有需求强上需求？

因为有时间，你的同事一定会学会 Tauri ， 学会 protobuf ，学会 grpc ，那学会了是不是和你一样了？

大部分人以为用了新技术就觉得自己比别人牛了？

比如大家用 electron ， 你用 tarui ， 我技术比你牛。

大家用 http ，你用 protobuf 又觉得比别人牛了。


反正我会点新技术， 吊吊库， 就是比同事🐂。

屏幕是三星，自己对比发现，三星的屏幕要清楚一些， 软件就算了，三星的软件 bug 比 oppo 还多。

@vicya 搞文艺复兴了是吧。。

@Socrazy typec 耳机的坑 ， 电脑不支持，还用转接头， 有些耳机在某些手机上用不了。 最后还是入手入门款无线耳机了。

@lizy0329 ionic 一样的坑