Comments 16

Спасибо за интересную статью! Подскажите, а есть ли неплохие русскоязычные статьи про grpc или в целом доки хватает?

В grpc-gateway есть фатальный недостаток — он очень медленный. Цепочка выглядит: Umarshal JSON -> Marshal protobuf -> Call gRPC -> Marshal protobuf on server -> Unmarshal protobuf on gateway -> Marshal JSON.
В Go на стороне сервиса довольно легко написать HTTP handler, который будет делать Unmarshal JSON'а напрямую в gRPC Request структуры (уже есть теги json) и вызывать реализацию gRPC метода.

Я бы не назвал это очень медленным: просто не самая оптимальная реализация, которая сойдет на время переходного периода.

Это правда, grpc-gateway это ещё одно звено в цепи, со своей сериализацией/десереализацией. Но «очень медленный» это относительная фраза — речь всё таки о десятках миллисекунд, что для многих случаев более чем позволительно.

Подход с десереализацией напрямую может работать только в случае, если это один сервис. Если же вы, к примеру, разбиваете монолит на gRPC-сервисы, и при этом хотите сохранить legacy REST API (хотя бы на время), то уже так не получится. А так да, вариант.
GraphQL это язык запросов, gRPC — это кросс-языковой RPC-фреймворк.

Как раз тыкаю эту связку для нового проекта. Вы с аплоадом файлов в такой схеме не сталкивались?

Ну, корявость в задаче, а не в инструменте :)
Если подумать — grpc гоняет туда-сюда только протобафы + стримы. HTTP MultiPart это такой древний пережиток, что его втиснуть тут только каким-то своим методом можно.

Тоесть, либо самому делать handler, который будет вычитывать и на ходу писать в grpc-стрим (или все читать в память/диск и передавать одним большим объектом), или надеятся, что это сделают за нас в grpc-gateway :)
Хотел выбрать его, но как понял он не может работать чисто по tcp, только по http? верно?
В примере proto файла, в самом начале не хватает точки с запятой в следующем коде
service LibraryService {
    rpc AddBook(AddBookRequest) returns (AddBookResponse);
}
Теперь на стороне сервисов (все gRPC-методы в Go реализации принимают первым параметром context), вы просто достаёте это значение из контекста:


Нередко считается плохим тоном, так лучше не использовать контекст. Если пробрасывать такого рода значения в контексте, код становится трудно поддерживать. Назначение context.Value — информирование, а не контроль логики
Only those users with full accounts are able to leave comments. Log in, please.