Самая большая проблема с этой системой - зависимые данные. Если в
виджете 1 запрос А, работающий с
таблицей X, зависит от данных из
запроса Б к
таблице Y (id сущностей оттуда берёт, например), то
запрос Б нужно отправить сразу, не аггрегируя его с
запросом В из
виджета 2, который работает с теми же данными, но отправляется позже. Большинство запросов зависят друг от друга, поэтому ощутимой пользы такая штука не принесёт.
Плюс, в большинстве проектов бэкенды синхронные - выполнение всего кода останавливается до окончания выполнения текущей функции, поэтому реализовать какой-то асинхронный агрегатор не так просто, скорее всего, придётся вообще всё приложение переписывать.
Плюс, как вообще такой системе узнать, что все запросы пришли, и пора их агрегировать и исполнять?
Плюс, виджеты, которые работают с одними и теми же данными, встречаются не часто - система будет работать вхолостую.
Плюс, собранные автоматически запросы могут быть очень неоптимальными, что только ухудшит производительность.
Плюс, если запросы к одинаковым данным будут генерировать с разной структурой, СУБД не сможет их эффективно кешировать.
На фронтенде и парадигма другая и с запросами проще (их легко различать по URL), поэтому такую штуку и сделать легче и меньше вероятность себе ногу отстрелить. Ну и задержки там
значительно серьёзнее - сходить по сети на бэкенд и сходить на бэкенде в БД - это как слетать к Альфе Центавра и съездить на другой конец города, поэтому если есть возможность не летать, её стоит использовать.
На бэкенде такую задачу (оптимизации) эффективнее решать с помощью кэша, вынесения части данных в легковесные хранилища и старых добрых
лучших практик работы с БД: правильная схема, корректно составленные запросы, индексы по часто используемым колонкам.
Но вот реальный кейс, где я похожую систему реализовал и использую: есть программа на C++, постоянно делающая запросы к внешнему API. Это внешнее API устанавливает лимит на количество запросов в секунду, в который программа не всегда укладывается. Выходов два: ставить задержки перед запросами или агрегировать их в пакеты (API это поддерживает). Второе решение, очевидно, лучше с точки зрения скорости работы. Но я не реализовывал в нём анализ и объединение похожих запросов - это сложно сделать, легко накосячить, а профит будет относительно небольшой. Всю эту штуку удалось сделать только за счёт того, что все операции асинхронные и запросы выполняются через планировщик. На каком-нибудь стандартном php-проекте этого не добиться.
