Комментарии 16
Спасибо за интересную статью! Подскажите, а есть ли неплохие русскоязычные статьи про grpc или в целом доки хватает?
Чтобы начать и заинтересоваться, достаточно (взято из ссылок автора поста)
В grpc-gateway есть фатальный недостаток — он очень медленный. Цепочка выглядит:
В Go на стороне сервиса довольно легко написать HTTP handler, который будет делать Unmarshal JSON'а напрямую в gRPC Request структуры (уже есть теги json) и вызывать реализацию gRPC метода.
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 (хотя бы на время), то уже так не получится. А так да, вариант.
Подход с десереализацией напрямую может работать только в случае, если это один сервис. Если же вы, к примеру, разбиваете монолит на gRPC-сервисы, и при этом хотите сохранить legacy REST API (хотя бы на время), то уже так не получится. А так да, вариант.
НЛО прилетело и опубликовало эту надпись здесь
Как раз тыкаю эту связку для нового проекта. Вы с аплоадом файлов в такой схеме не сталкивались?
К счастью, не сталкивался.
Вот такую issue в grpc-gateway обнаружил: github.com/grpc-ecosystem/grpc-gateway/issues/410
Вот такую issue в grpc-gateway обнаружил: github.com/grpc-ecosystem/grpc-gateway/issues/410
Я ее тоже нашел :-) как-то коряво, конечно.
Ну, корявость в задаче, а не в инструменте :)
Если подумать — grpc гоняет туда-сюда только протобафы + стримы. HTTP MultiPart это такой древний пережиток, что его втиснуть тут только каким-то своим методом можно.
Тоесть, либо самому делать handler, который будет вычитывать и на ходу писать в grpc-стрим (или все читать в память/диск и передавать одним большим объектом), или надеятся, что это сделают за нас в grpc-gateway :)
Если подумать — grpc гоняет туда-сюда только протобафы + стримы. HTTP MultiPart это такой древний пережиток, что его втиснуть тут только каким-то своим методом можно.
Тоесть, либо самому делать handler, который будет вычитывать и на ходу писать в grpc-стрим (или все читать в память/диск и передавать одним большим объектом), или надеятся, что это сделают за нас в grpc-gateway :)
Хотел выбрать его, но как понял он не может работать чисто по tcp, только по http? верно?
В примере proto файла, в самом начале не хватает точки с запятой в следующем коде
service LibraryService {
rpc AddBook(AddBookRequest) returns (AddBookResponse);
}
Теперь на стороне сервисов (все gRPC-методы в Go реализации принимают первым параметром context), вы просто достаёте это значение из контекста:
Нередко считается плохим тоном, так лучше не использовать контекст. Если пробрасывать такого рода значения в контексте, код становится трудно поддерживать. Назначение context.Value — информирование, а не контроль логики
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как перейти на gRPC, сохранив REST