user-service и shop-service. в Юзер сервисе есть таблица карзины, в которой есть айд пользователя и массив товаров которые у него в корзине (тупо их айдишники) все описание товаров и так далее лежит в шоп сервисе. Мне необходимо вернуть на клиент юзера со всеми его товарами (не только с айдшиниками, а с полной инфой). Как лучше сделать?
1. Из юзер сервиса дергать шоп сервис, что бы получить все товары и потом собрать json
2. На Gateway сперва сделать запрос к юзер сервису, потом к шоп сервису и так же на гейтвейее собрать json
3. Сделать 2 запроса с клиента
Зависит от архитектуры 😄 Вообще годный вопрос, все 3 варианта кажутся хорошими и уместными. Это вопрос паттернов. Так понимаю, речь про шину событий, а не rpc
Думаю логичнее будет запрос от юзер-сервиса отправить, раз уж он отвечает за эти данные.
из юзер сервиса дёргать cart сервис, а оттуда шоп
а не слишком ли сильное раздробление?
Хотя последний вариант в подходе микросервисов теряет консистентность получаемых данных (наврядли в простом шопе это будет важно), но может быть проблема
Разделение ответственности
О ты, как я тебя давно выдел, ты почему ушел?
не создаст ли это сложные зависимости сервисов от друг друга? не лучше ли чтобы сервисы вообще в друг друга ходить не могли?
мало микросервисы вспоминают
Никаких зависимостей. Даём запрос "дай мне селект джойн" и отдаем на клиента. Данные нужны этому сервису, при подготовке данных по корзине. Всё логично
для этого 1. сервис корзины должен знать что сервис юзеров это валидный сервис, а не хакер пытающийся получить доступ к данным. Это требует ввода общей валидации сервисами друг друга 2. Нам нужна апи библитека, которая будет предоставлять доступ к сервису корзины, а если сервисов, которые могут к нему обратиться несколько и они на разных яп? писать под каждый яп либу и при изменении изменять ее везде? 3. А если мы решили обновить формат выходных данных на сервисе корзины? обновить одно поле в бд (его имя), то посыпется вся система, ведь под это поле придется переделывать все сервисы, что могут обратиться к сервису корзины
1. Не думаю что это нужно, ведь это открытые данные. 2. Просто один эндпоинт для получения данных, они в любом случае задействованы на сайте, а таким образом мы просто данные подготовим. Ответственность за данные о продуктах отдельно, а о корзине отдельно (за нее отвечает другой сервис) 3. Ну по факту. Только такая проблема будет всегда. Я вообще думаю, что подход с таким разделением не очень хороший. Gateway будет решением, как и что я предлагаю. Тут скорее вопрос в том, как этим всем потом будут пользоваться и зачем. Т.е. gateway может быть избыточен
Обсуждают сегодня