将原型缓冲区转换为 ProtoRPC

Question

在 Python 脚本 mylibrary.py 中，我使用 Protocol Buffers 通过以下方法对数据建模：

在 .proto 文件中定义消息格式。
使用协议缓冲区编译器。
使用Python协议缓冲区API在.py模块中写入和读取消息。

我想在 App Engine 上实施 Cloud Endpoints Framework imports 并使用上述 Python 脚本，但是 Cloud Endpoints 使用 ProtoRPC，而不是 'standard' Protocol Buffers。

我的 App Engine Python 模块 main.py 从 protorpc 导入而不是使用 'offline' protoc 编译器生成序列化和反序列化代码：

from protorpc import messages
from protorpc import remote

消息是未使用.proto文件定义的。相反，类被定义为继承自 protorpc.messages.Message:

class MyMessageDefinition(messages.Message)

可以将 Proto Buffers 转换为 Proto RPC 等价物吗？我真的不想更改 mylibrary.py 以使用 ProtoRPC，因为它不如 Protocol Buffers.

通用

Answer 1

我找到了一个名为pyprotobuf（http://pyprotobuf.readthedocs.io）的项目，它可以从proto文件开始用protorpc类生成一个模块。

根据文档（http://pyprotobuf.readthedocs.io/topics/languages/protorpc.html）你需要执行：

原型--格式pythonexample.proto

Answer 2

经过八个月的大量实验，我将添加我的意见。我希望它可以节省一些人的时间。

首先选择你的框架

Google Cloud 提供了不同的 Cloud Endpoint 产品。都可以用JSON/REST API秒。这对我来说不是很清楚。 Cloud Endpoints 是一个非常高级的短语，涵盖多个 Google 云后端上的 API 的开发、部署和管理。

这里的重点是，在决定使用 Cloud Endpoints 之后，您还必须决定后端技术来为您的 API 服务。文档感觉有点隐藏，但我强烈建议从 Google Cloud Endpoints doc.

开始

您可以选择：

其次选择您的实施方式

在每个 API 框架中，可以选择云实现，您的 API（服务）可以运行:

OpenAPI Specification - JSON/REST APIs 实现于：

Google App Engine 柔性环境
Google 计算引擎
Google容器引擎
Kubernetes

Endpoints Frameworks - JSON/REST APIs 实现于：

Google App Engine 标准环境 Java
Google App Engine 标准环境 Python

gRPC - 对于 gRPC APIs 实施于：

Google 计算引擎
Google容器引擎
Kubernetes

在此处发布问题时，我在 Google App Engine 标准环境中使用 Endpoints Frameworks 运行ning 和 Python。然后我将 API（服务）迁移到 Google Compute Engine 上的 gRPC。

细心的你可能会注意到 OpenAPI Specification 和 Endpoints Frameworks 都可以用于 JSON/REST APIs，而 gRPC 只公开了一个 gRPC API。那么我是如何将 REST API 从 Endpoints Frameworks 移植到 gRPC 的呢？答案是 Transcoding HTTP/JSON to gRPC （这是我一路学到的，我不是很清楚）。所以，不要仅仅因为你想要 REST/HTTP.

就排除 gRPC

答案

那么这与我原来的问题有什么关系？

我试图在 .proto 文件和 gRPC 注释之间进行转换，这意味着我在这个过程中走错了路。

如果您想使用纯 .proto 文件编写应用程序，请在 Compute Engine 上选择 gRPC。如果您需要它成为 REST API，可以这样做，但您需要在后端配置中添加一个 ESP。它几乎是一个 NGINX 服务器设置作为反向代理。这里唯一的缺点是您需要一些 Docker 知识来确保 ESP（代理）和您的 gRPC 服务器可以通信（Docker 网络）。

如果您的代码已经在 App Engine 上，并且您希望以最小的努力将其公开为 REST API 并且仍然获得良好的 API 管理功能，请选择 Endpoints Frameworks . 警告：我放弃了这个，因为它太贵了（我每月要支付大约 100 美元的费用）。

如果你想完全避免 .protos，那就选择 OpenAPI Specification。

最后，如果您想提供编程集成、客户端库，或者您想提供微服务，那么请务必考虑 gRPC。在几乎任何机器上删除 ESP（代理）和运行 gRPC 服务器都很容易（只要安装了 Protocol Buffer Runtime。

最终我选择了 Docker Compute Engine 上的 gRPC。我还有一个 ESP，用于向 gRPC 提供 HTTP 转码，反之亦然。我喜欢这种方法有几个原因：

你学到了很多东西：Docker、Docker 网络、NGINX 配置、协议缓冲区、ESP（云代理）、gRPC 服务器。
服务（核心业务）逻辑可以用普通的 gRPC 编写。这允许服务在任何没有 Web 服务器的机器上运行。你的业务逻辑，就是服务器:)
协议缓冲区/gRPC 非常适合将业务逻辑隔离为服务……或微服务。它们也很适合提供定义明确的接口和库。

避免这些错误

正在实施您找到的第一个框架/架构。如果可以重新开始，我不会选择Endpoints Frameworks。它很昂贵，并且使用注释而不是 .proto 文件，在我看来，这使得代码更难移植。
阅读始终免费使用限制。 Endpoints Frameworks 使用 backend App Engine 实例 - 几乎没有免费配额。令人困惑的是，前端 App Engine 实例有一个非常慷慨的免费配额。
考虑本地开发。官方不支持 Cloud Endpoints 本地开发服务器（至少在我提出问题时不支持）。相反，在运行 a Local Extensible Service Proxy.

将原型缓冲区转换为 ProtoRPC

Converting proto buffer to ProtoRPC

python

google-app-engine

protocol-buffers

protorpc