写了个轮子 fast-grpc，用 Python 轻松开发 grpc 接口

[yatao]

简介

Fast-GRPC 旨在为开发者提供更轻松快捷的 Python gRPC 接口开发方式，受到 FastAPI 的启发，用更 human 的方式编写 gRPC 接口，通过使用 Python schema 直接定义 gRPC 接口，然后自动生成 grpc proto ，从而省去了在 proto 文件中再次定义接口的繁琐工作；框架简化了 Python gRPC 开发流程，同时提供与 FastAPI 类似的接口编写风格，接口可以支持同步和异步写法，并且还可以使用 Middleware （代替 grpc 拦截器，自带的拦截器感觉不太好用）。个人认为，在 Python 微服务实践中，结合 FastAPI 和 gRPC 并利用流行的微服务基础设施（比如微软 dapr ），将是一个不错的选择。

安装

需要 python 3.7+

pip install python-fast-grpc

快速上手

下面是一个简单的 Fast-GRPC 示例，展示如何创建一个 gRPC 服务

from fast_grpc import BaseSchema, FastGRPC, ServicerContext, method

app = FastGRPC()

class HelloRequest(BaseSchema):
    name: str

class HelloReply(BaseSchema):
    message: str

class Greeter:
    @method("SayHello", request_model=HelloRequest, response_model=HelloReply)
    async def say_hello(self, request: HelloRequest, context: ServicerContext) -> HelloReply:
        return HelloReply(message=f"Greeter SayHello {request.name}")

app.add_service(Greeter)  # 添加 Greeter 服务
# 启动 gRPC 服务。无需手动编写 proto 文件，Fast-GRPC 会根据你的 Python 代码自动生成 proto 文件，并编译为 Python gRPC 代码，最后启动 gRPC 服务
app.run()

在上面的示例中，我们首先使用 FastGRPC 创建了一个 gRPC 应用。接下来，定义了一个 gRPC 服务 Greeter，使用 method 装饰器标记了一个 RPC 方法 say_hello。method 接受三个参数：RPC 方法名、请求模型 HelloRequest 和响应模型 HelloReply。say_hello 方法可以支持同步和异步代码，对于同步代码，会使用线程来模拟异步执行。

最后，我们将 Greeter 服务添加到 gRPC 应用中，并通过 run 方法启动 gRPC 服务器。Fast-GRPC 会根据添加的 Greeter 服务的接口定义自动生成 .proto 文件和 Python gRPC 代码，简化了 Python gRPC 的开发步骤，更符合 Python 的使用习惯。

接下来，我们通过一个客户端调用来演示效果：

import grpc
import greeter_pb2 as pb2
import greeter_pb2_grpc as pb2_grpc

channel = grpc.insecure_channel("127.0.0.1:50051")
stub = pb2_grpc.GreeterStub(channel)
response = stub.SayHello(pb2.HelloRequest(name="fastGRPC"))
print("Greeter client received: ", response)

相关链接

Fast-GRPC GitHub 仓库

下一步计划

目前，Fast-GRPC 支持的功能还比较简单，未来将继续改进和完善。如果您有任何建议或意见，欢迎提交 issue 或者 PR 。

[hauzerlee]

赞，我 fork 一个来搞搞。unix system-v rpc 已经是这种方式了，以前搞过

[akaHenry]

https://github.com/bali-framework/bali

可以看看 Bali 框架, 基于 fastapi + grpc, 360 的团队开源的.

[yatao]

@akaHenry 感谢推荐，但我觉得不是一个东西，抽象 django 那一套理论对于简单的增删改查确实方便不少，实际开发使用场景并不简单，尤其使用微服务架构之后，并且这种设计导致开发的代码都是和框架的思想深度绑定的，个人更喜欢整洁架构设计那套思想，我们实践中也是按照这套理论来实施的

[akaHenry]

@yatao 嗯. bali 仿 django-rest-framework 设计了 API 层. 熟悉 drf 的用起来, 很方便.

另外, 其实 bali 也可以常规方式定义 route, 也就是可以不使用这套.

灵活性还是有的. (这项目和我无关, 碰巧看你这个轮子, 刚好匹配)

当然, 轮子还是自己造的香. (毕竟也很简单, 用啥都 OK)

[yatao]

@akaHenry 嗯，特地去看了下这个项目，说下我的个人看法
从架构设计的角度来看，bili 做的是业务的抽象层，它在业务层抽象了一层标准，开发按照这个标准去写，然后它会将业务代码转换为相应的基础框架（如 FastAPI 和 gRPC ）所需的代码。这不是我想要的东西，我们也有自己通用的业务脚手架，比如标准的 REST 处理 handler ，如果是一些简单的增删改也很方便。这取决于公司的开发规范和标准，我估计 bili 想做的也是这个事，毕竟 python 在工程方面也没统一标准。
相比之下，FastgRPC 的目标是仅提供 gRPC 框架，就像 FastAPI 封装了 Starlette 一样。我个人也比较看好 typing 的风格，也是一个很好的方向。

[akaHenry]

嗯. 都行. 👌🏻️