Golang RESTful gRPC

Нельзя просто взять и написать структуры (классы) доступа к данным Protocol Buffers. gRPC API начинается со спецификации. HTTP API может существовать и без спецификации. Тем не менее, по понятным причинам, трудно найти коммерческий HTTP API без какого-нибудь OpenAPI (он же Swagger, он же Гога, он же Жора). В экосистеме gRPC есть инструмент по имени grpc-gateway, который может оказаться очень полезным в случае необходимости "прикрутить" HTTP JSON API к gRPC API. Он позволяет генерировать код reverse-proxy, а также спецификацию в формате OpenAPI,  используя определения в файлах .proto, что упрощает как разработку, так и поддержку.

Sending binary with Node.js via gRPC

Protocol Buffers - протокол сериализации структурированных данных. Нельзя просто взять и скомпилировать: rpc Send (stream bytes) returns (void);, нужно обязательно использовать структуры: rpc Send (stream File) returns (Empty);. В Node.js самый простой способ отправить файл, или любой другой Readable Stream - спайпить его с Writable Stream. Для того чтобы отправить файл через gRPC можно пребразовать поток бинарных данных в поток структурированных данных и наоборот с помощью Transform Stream, как-то так: на клиенте Readable Stream -> Transform Stream -> ClientReadableStream, на сервере ServerReadableStream -> Transform Stream -> Writable Stream.

Node.js gRPC defaults

Вчера обновил grpc-node и после запуска приложения получил предупреждение: 'DeprecationWarning: grpc.load: Use the @grpc/proto-loader module with grpc.loadPackageDefinition instead'. В процессе выяснения причины оказалось что grpc-protobufjs среди прочих решает вопрос с дефолтными значениями: по умолчанию отсутствие значения интерпретируется как отсутствие значения, т.е. полю не присваивается дефолтное значение. Конец моим страданиям и разочарованиям, теперь можно избавляться от костылей. Кроме того исследование изменений в gRPC позволило мне ответить еще на один на вопрос: как передать метаданные с сервера на клиента без использования ошибки.

WTF with errors in gRPC?

Недавно мне задали вопрос: для чего нужен package-lock.json, я ответил: для того же для чего и npm-shrinkwrap.json - чтобы не было мучительно больно. Вчера обнаружил удивительный диссонанс между версиями 1.8.0 и 1.8.4 модуля gRPC, а именно изменения в процессе создания ошибки, вот от кого никак не ожидал. К примеру, если в версии 1.8.0 ошибка с сообщением 'Invalid name' на сервере предсказуемо превращалась в ошибку в таким же сообщением на клиенте, то в версии 1.8.4 на клиенте то же сообщение об ошибке превращается в '2 UNKNOWN: Invalid name'. WTF?

Going to gRPC. Bidirectional streaming

В процессе проектирования одного приложения в какой-то момент я решил, что один сервис должен иметь возможность итерировать по коллекции, за которую отвечает другой. Не просто получать данные в виде списка или потока, а иметь возможность перечислять элементы коллекции по одному, а также прерывать процесс итерации. Не смотря на то, что в итоге ответственность за прерывание процесса досталась итератору, что позволило решению остаться в пределах парадигмы request-response, мне захотелось посмотреть как могло бы выглядеть решение на bidirectional streaming RPC.

Handling errors in gRPC

Вчера прочитал один пост на тему обработки ошибок в gRPC. На мой взгляд передавать вместе с ошибкой стэк - это уже перебор: сообщение, статус, может быть какой-нибудь код, прочие дополнительные поля (например Retry-After), но не стэк. По-моему стэк должен быть залогирован там где произошла ошибка, после чего его миссия завершена. Кроме того я не согласен с автором на предмет того, каким образом передавать все эти дополнительные поля: идея передавать ошибку вместе с данными (или вместо данных) мне не нравится, думаю метаданные здесь подойдут лучше.

Going to gRPC

Недавно начал инвестигировать gRPC + Protocol Buffers. В Node.js профит сомнительный, по крайней мере до тех пор пока не появится стабильный http/2 (без флага --expose-http2), тем не менее никто не мешает уже сейчас использовать другую платформу, я бы предпочел Go. Первое знакомство с Node.js прошло без проблем, а вот с Go пришлось повозиться: скачать C++ реализацию protobuf, сбилдить protoc.exe с помощью CMake, после чего сбилдить protoc-gen-go (и не забыть добавить в переменную окружения PATH путь к protoc.exe).