Comments 3
Не совсем по теме, но может любопытно - как раз работаю над проектом, где получилось довольно удачно на мой вкус реализовать связку фронтенд/бэкэнд через gRPC.
gRPC недоступен наружу, а React-фронтенд сделан на Next.js с app router / server functions. То есть коммуникация фронтенд-gRPC-бэкэнд происходит исключительно через внутреннюю серверную подсеть и обычный Node.js, а коммуникация браузер-фронтенд идёт через встроенные в Next механизмы. Таким образом получается использовать "нормальный" javascript gRPC без всяких прокси-шмокси.
Получилось очень удобно и эффективно (быстро писать), и работает хорошо (быстро загружаются странички), и API проектировать сильно проще становится.
Личный опыт использования gRPC - вынужденный и остро негативный.
Вынужденный - потому, что большая часть сервисов Mailion реализована на go, а поиск - чисто C++ - разработка.
Негативный - потому, что реализация gRPC, столь изящная и нативная для go, для C++ напоминает козу без сисек, с разноразмерными шинами вместо копыт и одним толстым х.. вместо рога на носу.
Примеры из Tutorial работают идеально и внушают уверенность в успехе. По мере использования оказывается, что наиболее значимые настройки не реализованы, а реализованные возможности не документированы совсем.
А уж когда находишь перехваченный аллокатор памяти, в случае её нехватки делающий abort(), приходит понимание всей глубины бездны индийского замысла.
А уж негарантированная доставка поставленного в очередь тега сколько крови попортила...
Публикация джарок, сгенеренных с proto-файлов - понятно.
А вы делали публикацию/импорт самих proto-файлов из java/kotlin проектов? Protobuf - он же как бы мультиплатформенный.
Эффективное создание и деплой gRPC API с помощью GitHub Actions и Packages для проекта на Kotlin и React