Как реализовать grpc ендпоинт, чтобы фронтенд получал ответ в формате

json?

?

!

По какому протоколу ты хочешь, чтобы фронтенд получал json?

http2

Вообще вопрос странный, grpc использует http2, и бинарный формат данных, фронт требует json, можно же преобразовать бинарные данные в json и вернуть фронту

По http2 или по grpc?

по SOAP ^)

Можно, но этим будет не grpc-эндпоинт заниматься. Можешь написать сервис-прослойку, который будет забирать данные по grpc и отдавать json-ом по http. Ну или добавить в сервис http+json эндпоинты

Да, я вот и спросил с целью узнать как правильнее сделать

Зависит от того, как тебе удобнее, в общем-то. Либо от корпоративной политики :)

А вообще при состыковке react и grpc, как лучше фронту отдавать?

Никак, браузеры не умеют работать с grpc. Делай для браузеров отдельные эндпоинты.

Можешь попробовать посмотреть в сторону grpc-web, который предлагает прокси, транслируют grpc в удобоваримую для браузерного js-а форму.

Java RPC

https://github.com/grpc-ecosystem/grpc-gateway

Его много ругают за кривоту

Прикол из требований в вакансии, в golang jobs

- во-первых обработка ошибок оч плохая - во-вторых заголовки неадаптированные типа grpc-status заставят поплясать - в-третьих у нас были сложности с отображением ответа в браузере кароч тулинг не готов был либо фронтендеры не могли этим занятьс и не хотели Может envoy?

Я его не юзал. Вообще, я бы просто отдельный набор эндпоинтов под потребности браузера нарисовал.

Можешь пример показать плиз, где rest используется рядом с эндпоинтами grpc?

Avangers: Final Endponit ^)

В паблике нет, но на предыдущем месте работы так активно делали, пока техдир с подачи безопасников не приказал распилить сервисы на отдельно grpc-бэки с бизнес-логикой и обертки с http api и фронтом.

Я читал статью, что разделять еще правильно надо.

CQS? Или что?

Хм, а что опасного держать в одном месте grpc и rest?

Т е фронт дёргал обертки http api а обертки в свою очередь обращались к grpc?

У меня такое было на нескольких проектах, при чём везде по разному назывался "gateway service", "frontend service", "api service". HTTP в мир, а внутри всё на gRPC

В delivery его надо, не в адаптеры

Точно понимаешь про что я говорю ?

Про чистую архитектуру

delivery это что? Контроллеры?

Про хексогональную. Где есть driven и secondary adapter. (В целом идейно чистая) Мне кажется, grps — это presentation слой. Просто не совсем понимаю что такое delivery

В адаптерах gateway как правило для dao, delivery он же presentation layer используется для grpc, http api, graphql

В хексогональной два вида адаптеров. Primary — presentation. Secondary — инфраструктурные. С разных сторон типо.

Presentation

Для grpc есть обязатеоьный внутренний фреймворк аутентификации и авторизации клиентов, а для http эндпоинтов разброд и шатание. Потому потребовали от команд отделить сервисы с бизнес-логикой и grpc с нормальной аутентификацией и авторизацией и http-сервисы

Да

Потому что так было заведено в компании: grpc обязательно для s2s, а остальное по потребности

или secondary

Те вы вынесли аутентификацию и авторизацию на grpc?

Обработчик запрсов — presentation Клиент от других API — адаптер

В Go например соединение с бд выносят в отдельных пакет в папке pkg

О.o Столько вопросов. Что значит "вынести соединение в пакет"? Почему "pkg"? Что за название? Почему не адаптер? Как название пакета влияет на реализацию

Нет, s2s AA для grpc отдельно, а для http отдельно (уже в зависимости от потребностей сервиса). Просто для grpc была реализована функциональность на уровне общего фреймворка.

Коннект к бд это внешняя зависимость не имеющая отношения к ча, зачем тебе в ча тащить коннект к бд?) Мартин писал об этом, но все почему то тащат Коннект к бд в чистую архитектуру адаптеров

это называется адаптер

может потому что эти все понимают, что такое адаптеры?

Я делаю слой адаптеров внутри usecase для соединения с внешними слоями репозитория например, а подключение к бд выношу в отдельный пакет вне ЧА

O.o

Ты либо интерфейсы адаптерами называешь, либо у тебя нарушен DIP

Интерфейсы

это порты называется

Адаптерами называют реализации, не интерфейсы

https://refactoring.guru/ru/design-patterns/adapter (простите, нужен VPN. Изображения кидать нельзя~)

Да все правильно, я разделяю на слои delivery, domain, repository(использует gateway, dao), usecase(содержит интерфейсы) Само подключение к бд у меня в pkg, как внешняя зависимость, в остальном все как вы показывает на картинке

репозиторий - не слой

откуда берется этот деливери загадочный. Не первый раз встречаю в чате, но не встречаю больше нигде

Сразу видно что вы не работали в крупном продакшене)

ладно))))

Что для тебя крупный продакшн?

.

К чему это? Адаптер в ЧА это частный случай адаптеров как паттерна