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

Раздельное версионирование фронта и бека?

да, теперь так, к счастью

псип

и тут спсип

У нас вот именно таких задач очень много.
Щас опишу как она решена в одном проекте

Есть сервис, который должен предоставлять ВСЕ данные какие возможно. Он потребляет все возможные кафки (а если инфа доступна только через апи, делают сервис, который поллит данные из апи и кладет в кафку) и складывает в единую сущность с примерно такой моделью:


ids: {
 id1: optional id1
 id2: optional id2
 id3: optional id3
 …
},

datasource1: optional datasource1,
datasource2: optional datasource2,
…


все датасорсы имеют свои айдишники,  их надо как-то коррелировать, там могут быть разные отношения 1:1, 1:N, N:M это зависит
Если там 1:M например, то внутри ids будет массив других айдишников.
Как это наложить на твою БД и её индексы, зависит от БД. У нас в кассандре много таблиц маппинга, но какие-то бд умеют строить индексы по структуре

Далее основной пейлоад имеет поля в которые тупо перезаписывается (или мержится) пришедшая инфа из datasource. Соответственно может вообще нихуя не придти, поэтому все поля опциональные. У всех должен быть таймштапм послднего ingestion

У тебя может встать вопрос - а что если нужны поля, которые агрегируют несколько датасорсов?
Тогда тебе нужно организовать change feed. Допустим в агрегации участвуют поля datasource1 и datasource2. Когда кто-то из них изменяется посылается событие в топик и отдельные сервис будет пересчитывать aggregatedField и перезаписывать его при получении новых данных.

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

АПИ поверх этого должно учитывать что пейлоад ебанистичеки большой и консумер может хотеть получать только его часть поэтому можно в квери писать имена полей из финального респонса, которые ты хочешь получить (соответственно из БД только их и грузить).
Ты скажешь - ну это же графкуэль - я отвечу - ПОХОЖЕ, но моё мнение что графкуэль говна самовар.

почему тебе графкуль не нравится

вещь в себе.

Возможность писать квери на клиенте, это что-то очень странное и попахивать excel, когда надо дать возможность играться с данными доверенным людям

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

так а в чём опасность? пришёл тебе запрос, ты валидируешь, потом уже исполняешь

А саму задумку - писать запросы на клиенте чтобы меньше данных тянуть, не только через графкл можно сделать

ну да, LIMIT 10000, group by (10 ключей), 3 inner select, where (in range)

и вперде исполнять

нет, это не так работает

ты перед исполнением запроса чекаешь его сложность

по каждому полю и с учётом каждого аргумента комплексити чекаешь и потом уже допускаешь или нет

Классический SQL тоже так проектировали. Потом оказалось, что некоторые запросы могут поставить базу в известную позицию. При этом не только сами будут выполняться медленно, так ещё и притормозят все остальные.

Моё мнение, что подобное апи выставлять наружу нельзя, а для внутренних клиентов подобный запрос может исходить только от аналитиков, которым можно дать доступ к данным без граф кл. Все остальные кейсы надо проработать и понять что же им блять НА САМОМ ДЕЛЕ НУЖНО

но в графкуле ты сам играешь в валидатора и сам играешь в планировщика