Стоит конечно. Активно развивающаяся хрень
Можешь тогда немного опытом работы с gRPC поделиться? В формате вопрос-ответ
Ну, не вопрос, спрашивайте.
1. Есть два способа отправить запрос по gRPC, это обыкновенный запрос и стриминговый запрос, в каких случаях нужно использовать то или то, а в каких случаях нельзя использовать то или то. 2. Допустим есть несколько микросервисов, каждый общается с другими, как правильно хранить в проекте каналы с помощью которых они общаются. (Первое что пришло на ум это через DI пробрасывать соединение как Singleton) 3. Где хранить proto файлы? Я написав не большой проектик с одним клиентом и двумя сервисами, заметил что proto файлы в проектах одинаковые и просто копируются из одного проекта в другие, это можно как-то оптимизировать? 4. Какие проблемы gRPC может вызвать во время написания проекта? Возможно какие-то сложности с ним или что-то иное? 5. Представим что у нас есть фронт на каком-нибудь React, и насколько я прочитал инфы, gRPC из браузера не работает, и начитал что это решается с помощью какого-то прокси, так вот вопрос в том, насколько много это доставляет проблем? 6. Вы обворачиваете какие-либо объекты от gRPC в свои для удобства? допустим фабрики GrpcChannel делаете или что-то еще)))
Скиньте в личку, плз, постараюсь ответить.
1. Unary запросы - атомарный вызов запрос/ответ. Stream - запрос и постоянно приходят ответы. Стримы юзаются когда надо не ждать все данные, а обрабатывать по мере их готовности на сервере. 2. Не надо ничего с grpcchannel делать. просто регистрируются grpc клиент и он уже инжектится куда нужно. 3. Обычно в проекте сервера и копируется в проект клиента. Более сложные варианты зависят от конкретного проекта или инфраструктуры компании, например. 4. Нет сложностей. Разве что если стримы рвутся, то надо какой-то механизм переподнятия делать, которые уже обработанные данные не будет отправлять, но это зависит от проекта. 5. Ну они щас такие себе... Проще делать всю логику в бизнес-сервисах, а для внешних потребителей юзать просто разные контроллеры grps и rest. 6. Если хочется полность абстрагироваться от специфических особенностей grpc - лучше сделать, но придется на каждый grpc request/response писать свои dto обьекты и мапить их.
Обсуждают сегодня