Ну, фронту пофиг - витрина за bff или merge. Да и на существующих платформах делать обогащение на клиенте тоже легко (если фронт говорит, что сложно - увольте их нафиг).

Ну и откуда там "в разы" мне тоже не понятно. Дело точно в витрине и это точно компетентный фронт?

В разы вполне себе будет, если нужен "гибкий" UI с подбором колонок, разными сортировками, обилием фильтров. Merge на лету при таких требованиях на UI приводит к необходимости делать вручную соединение разных источников, разделение фильтров по ним, вплоть до выбора оптимальной последовательности фильтраций и соединений. То есть, повторяем логику оптимизатора запросов из СУБД витрины.

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

Хм, вообще merge на клиенте при этом делается очень просто.
А "произвольные фильтры, сортировки, колонки" по разным источникам - не бывают, так оно не работает.
И даже при наличии витрины, прикрытой сверху graphql - все равно куча проблем вылезает и совокупная трудоемкость скорее возрастает, чем падает.

Ну можно на примере посмотреть. Один источник - ФИО (х10000), другой - какие-нибудь счета или заказы (x1000000). И менеджеру хочется фильтры и по сумме заказа и по части фио, и сортировки - по фио и по сумме заказа, и пейджинг. И предположим, что UI именно такой должен быть (хотя, конечно, можно долго убеждать, что UI нужно сделать более специалищированным под кейс применения). Какие варианты реализации таких выборок без витрины?

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

Да, конечно, если всех данных мало, доступов к данным нет и запросов 0.5 TPS, то можно взять любой MySQL и вперед.

А ты можешь сказать, на какой витрине этот кейс будет нормально работать?

На одной общей РСУБД, в которой есть и фио, и заказы. Они ж ровно для таких задачек и придуманы.

(Я согласен, что витрина - это дорого)

… а точно ли нужны микросервисы в этом кейсе?

Ээ, РСУБД не даст нормального поиска по части ФИО (нет там обычно приличного полнотекста, увы)
Ну и произвольные выборки на РСУБД - вещь непростая (индексы на все не прикрутишь).
Так что лучше уж делать связку CH+ES, но это уже сложный merge (

Но лучше, конечно, изменить требования, оно в разы дешевле.

Я не говорю, что они нужны. Я говорю, что имея распределенную архитектуру по типу микросервисной, вы можете попасть на такую задачу. И есть разные варианты ее решения, начиная с отказа ее решать, и заканчивая витриной.

Ну, обычно людям конечно нужен поиск по началу фамилии. Это норм индексируется. А CH - это что ты имеешь в виду?

Ну, обычно нужно просто вбить что-то и получить )
CH - ClickHouse

Хотя надо на кейсы смотреть, конечно (

Ага. А то ишь кожаные мешки разбаловались, поиск по нескольким критериям им подавай )  
Самая жестяная жесть, это когда ФИО, например, в какой-нибудь отдельной БД thanks to 152-ФЗ и в витрину их по той же причине фиг вытащишь.

Ну, ФИО почти всегда нужно шифровать, да.

Вообще, как ни грустно, нормальных инструментов для витрин сейчас нет.