Как улучшить разработку gRPC? - PullRequest
Новая
       10

Как улучшить разработку gRPC?

0 голосов
/ 05 мая 2019

Я считаю утомительным снова определять protobuf message в файле .proto после того, как модель сущности будет готова.

Например, чтобы подвергнуть операции CRUD через gRPC, вам необходимо определить файлы table schema в .proto message, потому что это требуется для gRPC.

В традиционной restful разработке API нам не нужно определять messages, потому что мы просто возвращаем json, и объект json может быть произвольным.

Есть предложения?

P.S. Я знаю, что gRPC более эффективен, чем restful API во время выполнения. Однако я считаю, что он гораздо менее эффективен, чем restful API во время разработки.

Прежде чем я нашел элегантный способ повысить эффективность, я в настоящее время использую некрасивый способ: определите JSON message type: 

syntax = "proto3";
package user;
service User {
    rpc FindOneByJSON(JSON) returns (JSON) {}
    rpc CreateByJSON(JSON) returns (JSON) {}
}
message JSON {
    string value = 1;
}

Это ужасно, потому что ему нужен вызывающий JSON.stringify() аргументы и JSON.parse() ответ.

1 Ответ

2 голосов
/ 05 мая 2019

Поскольку gRPC и REST придерживаются разных концепций.

В REST сервер поддерживает состояние, и вы просто управляете им с клиента (для этого вы используете типы запросов GET, POST, PUT, UPDATE, DELETE). Напротив, вызов процедуры имеет четко определенный тип возврата, который является надежным и самоописываемым. gRPC не следует концепции сервера как единственного источника правды относительно состояния объекта; вместо этого - концептуально - вы можете взаимодействовать с сервером с помощью обычных вызовов, как при локальной настройке.

Кстати, в хорошем дизайне RESTful вы используете схемы для своих возвратов JSON, так что на самом деле это , а не произвольно, даже если вы можете злоупотреблять им. Например, проверьте спецификацию OpenAPI 3 для определения объекта ответа : они обычно содержат ссылки на схемы.

...