Выпущен gRPC-Web, а REST вот-вот снова убьют?

задняя часть внешний интерфейс сервер gRPC
Автор ｜ Люк Перкинс Переводчик｜Невежество

Сегодня Cloud Native Computing Foundation (CNCF) официально выпустил общедоступную версию gRPC-Web, клиентской библиотеки JavaScript, которая позволяет веб-приложениям напрямую взаимодействовать с внутренними службами gRPC, не требуя, чтобы HTTP-сервер выступал в качестве посредника.

Это означает, что теперь вы можете легко создавать настоящие сквозные архитектуры приложений gRPC с помощью файлов .proto для определения типов данных и интерфейсов служб на стороне клиента и сервера. gRPC-Web предоставляет альтернативу REST для веб-разработки.

Введение в gRPC-Web

gRPC-Web позволяет вам использовать .proto для определения «контракта» службы между веб-приложением на стороне клиента и внутренним сервером gRPC, а также для автоматического создания JavaScript на стороне клиента (вы можете выбрать компилятор Closure или использовать более широко используемый CommonJS).

Вы можете перестать беспокоиться об этих вещах: создании пользовательской логики сериализации и десериализации JSON, обработке кодов состояния HTTP (могут различаться в зависимости от REST API), согласовании типа содержимого и т. д.

С более широкой архитектурной точки зрения gRPC-Web обеспечивает сквозной gRPC. Как показано ниже:

Слева клиентское приложение взаимодействует с внутренним сервером gRPC через буферы протокола, который, в свою очередь, взаимодействует с другими внутренними серверами gRPC через буферы протокола. Справа веб-приложение взаимодействует с внутренним сервером REST API через HTTP, который, в свою очередь, взаимодействует с другими внутренними службами через протокольные буферы.

Чтобы было ясно, нет ничего плохого в самом приложении REST справа. Существует ряд очень успешных приложений, созданных на серверах REST API, которые используют протоколы, отличные от HTTP, для связи с серверными службами. Но если бы эти приложения разрабатывались на основе единого протокола и набора интерфейсов .proto (и набора сервисных контрактов), то можно было бы сэкономить бессчетное количество часов времени и головной боли.

Преимущества gRPC-Web заключаются не только в «техническом» аспекте, но и во влиянии на организацию. Ярко-оранжевая линия на графике — это не просто протокол — она представляет собой отдельный источник работы и когнитивной нагрузки, и теперь вы можете сделать ее полностью ярко-зеленой.

Преимущества gRPC-Web

Со временем gRPC-Web предоставит более широкий набор функций. В настоящее время все, что я вижу, это:

  • Сквозной gRPC. Как упоминалось выше, с помощью gRPC-Web вы можете формально удалить компонент REST из стека и заменить его gRPC, что позволит вам создать весь конвейер RPC с использованием протокольных буферов. Представьте себе сценарий, в котором запрос клиента перенаправляется на HTTP-сервер, который взаимодействует с 5 службами gRPC на серверной части. Скорее всего, вы потратите много времени на создание уровня взаимодействия HTTP, потому что вам нужно построить остальную часть всего конвейера.

  • Более тесная совместная работа между клиентскими и внутренними командами. Оглядываясь назад на диаграмму выше, где буферы протоколов определяют весь конвейер RPC, вам больше не нужно привязывать «команду микросервисов» к «команде клиента». Взаимодействие между клиентом и серверной частью — это еще один уровень gRPC.

  • Простое создание клиентских библиотек. С помощью gRPC-Web сервер, взаимодействующий с «внешним» миром, становится сервером gRPC вместо HTTP-сервера, а это означает, что все клиентские библиотеки могут быть библиотеками gRPC. Нужны клиентские библиотеки для Ruby, Python, Java и еще 4 языков? Вам больше не нужно писать HTTP-клиенты для всех этих языков.

Пример gRPC-веб

Некоторые преимущества gRPC-Web в крупномасштабных приложениях описаны выше. Теперь давайте проиллюстрируем на примере: простое приложение TODO. В gRPC-Web вы можете начать с простого определения todos.proto следующим образом:

syntax = “proto3”;

package todos;

message Todo {
  string content = 1;
  bool finished = 2;
}

message GetTodoRequest {
  int32 id = 1;
}

service TodoService {
  rpc GetTodoById (GetTodoRequest) returns (Todo);
}

Вы можете использовать это определение .proto и инструмент командной строки protoc для создания клиентского кода CommonJS:

protoc echo.proto \
  --js_out=import_style=commonjs:./output \
  --grpc-web_out=import_style=commonjs:./output

Затем получите список TODO с внутреннего сервера gRPC:

const {GetTodoRequest} = require(‘./todos_pb.js’);

const {TodoServiceClient} = require(‘./todos_grpc_web_pb.js’);

const todoService = new proto.todos.TodoServiceClient(‘http://localhost:8080’);
const todoId = 1234;


var getTodoRequest = new proto.todos.GetTodoRequest();

getTodoRequest.setId(todoId);

var metadata = {};

var getTodo = todoService.getTodoById(getTodoRequest, metadata, (err, response) => {

 if (err) {
   console.log(err);
 } else {
   const todo = response.todo();

   if (todo == null) {
     console.log(`A TODO with the ID ${todoId} wasn’t found`);
   } else {
     console.log(`Fetched TODO with ID ${todoId}: ${todo.content()}`);
   }
 }
});

Нет HTTP-кодов или методов, нет синтаксического анализа JSON, нет согласования заголовков. Вы объявляете типы данных и сервисные интерфейсы, а gRPC-Web абстрагирует весь шаблонный код, оставляя вам чистый и удобный набор API.

В бэкенде сервер gRPC может использовать любой язык, поддерживающий написанный gRPC, включая Go, Java, C++, Ruby, Node.js и так далее (см. документацию https://grpc.io, связанную с разработкой официальных язык в документе gRPC/docs/).

Последний ключ компонент - это прокси службы. С самого начала GRPC-Web поддерживает посланник в качестве прокси службы по умолчанию, который предоставляет встроенный фильтр Encoy.grpc_web всего несколькими строками конфигурации. Более подробную информацию будет подробно описано в блоге посланника (https://blog.envoyproxy.io/).

Следующий шаг

Общий выпуск означает, что основные строительные блоки готовы к использованию в рабочей среде. Но gRPC-Web также принесет много других вещей.

Ознакомьтесь с официальной дорожной картой разработки (https://github.com/grpc/grpc-web/blob/master/ROADMAP.md), чтобы получить представление о будущем, которое видит основная команда.

Если вы заинтересованы в том, чтобы внести свой вклад в gRPC-Web, основная команда надеется, что сообщество может помочь:

  • Интеграция с интерфейсной инфраструктурой. Распространенные интерфейсные платформы, такие как React, Angular и Vue, еще официально не поддерживают gRPC-Web. Мы бы хотели, чтобы эти платформы поддерживали его, поскольку каждая из них получит большую пользу от gRPC.

  • Поддержка прокси-сервера для конкретного языка. В выпуске GA Envoy является прокси-сервером по умолчанию для gRPC-Web, поддерживаемым через специальный модуль. Мы также хотели бы видеть внутрипроцессные прокси-серверы, разработанные на других конкретных языках. Внутрипроцессные прокси-серверы устраняют необходимость в специальных прокси-серверах, таких как Envoy и nginx, и могут упростить использование gRPC-Web.

Английский оригинал

https://www.cncf.io/blog/2018/10/24/grpc-web-is-going-ga/

Категории