将proto缓冲区转换为ProtoRPC

Question

在Python脚本中，mylibrary.py，我使用协议缓冲区使用以下方法来建模数据：

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

我想在appengine上实现Cloud Endpoints框架，该框架导入，并使用前面提到的Python脚本，但是Cloud Endpoints使用ProtoRPC，而不是“标准”协议缓冲区。

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

from protorpc import messages
from protorpc import remote

消息不使用. proto文件定义。相反，类被定义，继承自protorpc.messages.Message：

class MyMessageDefinition(messages.Message)

Proto缓冲区可以转换为Proto-RPC等价物吗？我真的不想改变我的图书馆。py使用ProtoRPC，因为它没有协议缓冲区那么通用。

Answer 1

我找到了一个叫pyprotobuf的项目(http://pyprotobuf.readthedocs.io)它可以生成一个模块，其中包含从proto文件开始的protorpc类。

根据文件(http://pyprotobuf.readthedocs.io/topics/languages/protorpc.html)你需要执行：

格式pythonexample.proto

Answer 2

经过八个月和大量的实验，我将补充我的观点。我希望这能节省一些时间。

首先选择你的框架

谷歌云有不同的云endpoint产品。所有这些都可以用于JSON/REST应用编程接口。我还不清楚。云endpoint是一个非常高级的短语，涵盖了多个谷歌云后端上应用编程接口的开发、部署和管理。

这里的重点是，在决定使用云endpoint后，您仍然必须决定为您的应用编程接口服务的后端技术。留档感觉有点隐蔽，但我强烈建议从谷歌云endpoint文档开始。

您可以选择：

1. OpenAPI规范

选择第二个实现

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

OpenAPI规范-用于JSON/REST API实现：

• Google App Engine灵活的环境
• 谷歌计算引擎
• Google容器引擎
• 库伯内特斯

endpoint框架——用于在以下平台上实现的JSON/REST API：

• 使用Java的Google App Engine标准环境

gRPC-对于在以下平台上实施的gRPC API：

• 谷歌计算引擎
• Google容器引擎
• 库伯内特斯

在这里发布问题时，我使用了运行在谷歌应用引擎标准环境中的endpoint框架和Python。然后我将我的应用编程接口（服务）迁移到谷歌计算引擎上的gRPC。

观察者可能会注意到，OpenAPI规范和endpoint框架都可以用于JSON/REST API，而gRPC只公开gRPC API。那么，我是如何将REST API从endpoint框架移植到gRPC的呢？答案是将HTTP/JSON代码转换为gRPC（我在这一过程中了解到了这一点，现在还不清楚）。所以，不要因为想要REST/HTTP就排除gRPC。

答案是

那么这和我最初的问题有什么关系呢？

我试图在之间转换。proto文件和gRPC注释意味着我一路上走错了方向。

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

如果您的代码已经在应用引擎上，并且您希望以最少的努力将其公开为REST应用编程接口，并且仍然获得良好的应用编程接口管理功能，请选择endpoint框架。警告：我离开了这个，因为它太贵了（我每月的账单是100美元左右）。

如果您想完全避免。原型，那么请使用OpenAPI规范。

最后，如果您想提供编程集成、客户端库，或者您想提供微服务，那么确实要考虑GRPC。移除ESP（代理）并在几乎任何机器上运行gRPC服务器都很容易（只要安装了协议缓冲运行时）。

最终，我决定与Docker一起在计算引擎上使用gRPC。我还有一个ESP，可以向gRPC提供HTTP转码，反之亦然。我喜欢这种方法有几个原因：

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

避免这些错误

>

实现你找到的第一个框架/架构。如果我可以重新开始，我不会选择endpoint框架。它很昂贵，并且使用注释而不是。proto文件，在我看来，这使代码更难移植。

在决定框架和实现之前，请务必阅读免费使用限制。Endpoints框架使用后端应用程序引擎实例，几乎没有免费配额。令人困惑的是，前端应用程序引擎实例有一个非常慷慨的免费配额。

考虑当地的发展。官方不支持云endpoint本地开发服务器（至少在我提出问题时不支持）。相反，在运行本地可扩展服务代理方面有一整页的内容。