Комментарии 9
А если серьезно, то зачем городить огород, если http+json всеми поддерживается, быстр, а с включенным сжатием догоняет бинарные форматы по размеру?
Статья про то, что ты можешь использовать http+json автогенерируемый -_-
Во-первых, к этому делу еще обычно swagger-документация нужна
А во-вторых, ты же сам описываешь недостатки данного подхода. А преимущества неочевидны
Дока тоже генерится, но с помощью ещё одного генератора protoc-gen-openapiv2
-> Наша система тупит
-> Открыть ворота
-> Бизнес не готов выделить отдельный бюджет
-> Закрыть ворота
-> Но нам согласовали неделю на техдолг
-> Приоткрыть ворота
Откажитесь уже наконец от gin, echo и <иной ваш фреймворк>
Из статьи я не понял конкретных причин, по которым нужно всем отказаться от gin/echo/fiber и использовать только gRPC-Gateway.
Допустим у меня один web-сервис с REST API. Используются middleware, такие как basic и jwt аутентификация, возврат различных http кодов ошибок, сессии, рендер шаблонов и статические файлы. Это все так же легко настраивается в gRPC-Gateway ?
В целом да, у нас так и работает. В наших проектах jwt аутентификация, есть сессии, статические файлы, даже кастомные эндпоинты только для http. В целом я не вижу смысла переписывать уже работающий сервис на том же gin, но если проектируете систему микросервисов с 0 - стоит обратить внимание на grpc, банально для упрощения общения между сервисами.
>Хотя gRPC-Gateway относительно эффективен, введение дополнительного прокси-слоя может немного увеличить задержку обработки запросов
Не немножко, а достаточно существенно, ибо проц начинает жрать перегонка json туда-сюда.
Как решение, можно делать не через проксирование http трафика на gRPC порт, а регистрировать в mux методы, которые так же генерируются автоматически, но тогда появляется проблема сбора метрик, ибо сгенерированный код не дает возможность получить uri template. Мы решили эту проблему только через патчинг сгенерированного кода, ибо все другие решения содержали слишком много минусов.
Странное заявление какое-то...надо не от фреймворков отказываться, а приходить к единообразию. Если нужна библиотека от одного фреймворка в другом, то отказ от используемого фреймворка никак не решит проблему с библиотекой.
Да и создавайте микросервисы на любом фреймворке, а данные гоняйте по gRPC, все счастливы.
Откажитесь уже наконец от gin, echo и <иной ваш фреймворк>