Для начала композитный фронт, условно собирающийся из нескольких приложений. (тянет куски фронта, зависимости, компоненты из соседнего фронтового-микросервиса и собирает это в приложение, в зависимости от прав, насторек системы и тд)
Во вторых, зачем тащить бизнес-валидацию и проверку токенов в микросервисы, если можно оставить в них только бизнес логику, поместить их в мелитаризованную зону и позволить пользоваться ими различным системам, которые занимаются проверкой прав и тд на своей стороне?
api-gateway - это просто как вариант, можно его сделать на уровне фронта, если мы придерживаемся идеологии "умный фронт", можно вытащить в api gateway.

>Для начала композитный фронт, условно собирающийся из нескольких приложений. (тянет куски фронта, зависимости, компоненты из соседнего фронтового-микросервиса и собирает это в приложение, в зависимости от прав, насторек системы и тд)

зачем этот геморой? разыне приложения, пусть в конце концов по разным путям и крутятся...
на чем такой фронт сделан?

>Во вторых, зачем тащить бизнес-валидацию и проверку токенов в микросервисы, если можно оставить в них только бизнес логику, поместить их в мелитаризованную зону и позволить пользоваться ими различным системам, которые занимаются проверкой прав и тд на своей стороне?

потому что где-то что то могут не учесть. вообще валидация и праверка прав на клиентской стороне - это полнейший бред. система сама должна отвечать за собственную безопасность, а не пологаться на кого-то, да еще и логику проверки во всех клиентах делать. и смех и грех

а про демелиторизованную зону  (кстати именно с приставкой де-) - да, поставил аутентификацию на api-gateway и все остальное просто недоступно извне. если же идет доступ непосредственно к определнным сервисам - то только проверка на сервисах. ах да, а если у одного пользователя одни права, а у другого другие и идет межсервисный запрос внутри? у первого пользователя есть права на второй сервис, а у второго - нет, но его то уже пустили в демеллиторизованную зону - как быть? авторизация в каждом микросервисе

и да, следует различать авторизацию и аутентификацию

Я говорю скорее про одну страницу, которая собрала логику с пачки сервисов и на сервере отрендерилась и отдалась пользователю.
Например меню подтянули из одного места, содержимое какого то модуля из другого места и тд

а насчет валидации - то тут только конкретный контроллер конкретного микросервиса скажет валиден ли запрос для него. вот представь делать валидатор на пару сотен запросов в прокси. (ха-ха-ха)

зачем?

за меню приложения отвечает один сервис, а за навигацию другой, за страницу с блэкджеком - третий? и все это сшивается?

бизнес валидация - это одно, техническая валидация - это другое.
Технически ты можешь передавать какие-то данные, например загружать файлы любого размера и микросервису будет ок, а по бизнесу тебе запрещено загружать больше 2х файлов больше 1мб каждый. В данном конкретном кейсе

и как оно потом выглядит на фронте? как франкинштейн?

Нет, как сверстали, так и выглядит

и почему эту проверку не делать на бэке?

ты так и не ответил на чем фронт?

реакт же

еще один франки

на бэке нода и хапи

тот случай когда инструменты рождают проблемы, которые этими же инструментами и костылятся

Привет. Имеется спринг бут. Задача: сделать тонкую настройку кэша на некоторых методах. Тонкость либо по времени, например хранить кэш 15 минут, либо до первого измнения источника данных. В какую сторону копать?

а в чем конкретная проблема?