yatao 最近的时间轴更新 yatao 最近的时间轴更新 |
yataoV2EX 第 628920 号会员，加入于 2023-05-15 01:00:45 +08:00 |
yatao 最近回复了
2023 年 6 月 9 日 回复了 yatao 创建的主题 › Python › 写了个轮子 fast-grpc，用 Python 轻松开发 grpc 接口 |
@akaHenry 嗯，特地去看了下这个项目，说下我的个人看法
从架构设计的角度来看，bili 做的是业务的抽象层，它在业务层抽象了一层标准，开发按照这个标准去写，然后它会将业务代码转换为相应的基础框架（如 FastAPI 和 gRPC ）所需的代码。这不是我想要的东西，我们也有自己通用的业务脚手架，比如标准的 REST 处理 handler ，如果是一些简单的增删改也很方便。这取决于公司的开发规范和标准，我估计 bili 想做的也是这个事，毕竟 python 在工程方面也没统一标准。
相比之下，FastgRPC 的目标是仅提供 gRPC 框架，就像 FastAPI 封装了 Starlette 一样。我个人也比较看好 typing 的风格，也是一个很好的方向。
从架构设计的角度来看，bili 做的是业务的抽象层，它在业务层抽象了一层标准，开发按照这个标准去写，然后它会将业务代码转换为相应的基础框架（如 FastAPI 和 gRPC ）所需的代码。这不是我想要的东西，我们也有自己通用的业务脚手架，比如标准的 REST 处理 handler ，如果是一些简单的增删改也很方便。这取决于公司的开发规范和标准，我估计 bili 想做的也是这个事，毕竟 python 在工程方面也没统一标准。
相比之下，FastgRPC 的目标是仅提供 gRPC 框架，就像 FastAPI 封装了 Starlette 一样。我个人也比较看好 typing 的风格，也是一个很好的方向。
2023 年 6 月 1 日 回复了 yatao 创建的主题 › Python › 写了个轮子 fast-grpc，用 Python 轻松开发 grpc 接口 |
@akaHenry 感谢推荐，但我觉得不是一个东西，抽象 django 那一套理论对于简单的增删改查确实方便不少，实际开发使用场景并不简单，尤其使用微服务架构之后，并且这种设计导致开发的代码都是和框架的思想深度绑定的，个人更喜欢整洁架构设计那套思想，我们实践中也是按照这套理论来实施的
Select Language