Sergey Ilichev

- получение данных об общем количестве записей для построения пагинации, это SELECT count(id)

1. count(*), а не count(id)
2. если вас не сильно интересует абсолютно точное значение для миллионов результатов, то делаете оценку количества, начать проще с EXPLAIN <текст запроса> вы можете получить оценку количества результатов. Мы для себя решили, что если по оценке меньше 50 000 строк, то вслед за этим делаем обычный SELECT count(*) для получения точного количества.

Потом дергается запрос для получения данных на экспорт

1. Пожалуй, вам от этого нужно избавляться в первую очередь. Нажал человек на кнопку "экспортировать" - экспортируете, а до этого и дёргаться нет смысла. Фильтры можно получить либо при клике, либо из заголовка referer
2. Если вам нужно абсолютно все данные, то ставите задание на экспорт в очередь и выполняете его в отдельном процессе, сохраняете в файл. Для пользователя рисуете прогресс выполнения и выводите его в нажатую пользователем кнопку, хотя можно тупо на отдельной странице выводить список "заказанных" выгрузок и ссылки на скачивание.

Запросы на каждый выпадающий список в фильтрах - SELECT distinct field_name

Можно с какой-то периодичностью выгружать выхлоп таких запросов в материализованное представление / справочную таблицу / ENUM. Для обновления таких справочников "в реальном времени" можно повесить триггер на вставку в основную таблицу который будет делать INSERT INTO dictionary (value, column_oid) ON CONFLICT / ALTER TYPE ADD VALUE IF NOT EXISTS
После чего в основной таблице заводите рядом поле под идентификатор в справочнике и индексируете уже его.

Запрос при фильтрации и сортировке - SELECT * FROM some_table WHERE field_name LIKE '%value%'

1. если у вас значения длинные (от 8 - 10 символов), то стоит попробовать триграммные индексы. Но на коротких значениях они могут замедлить поиск раза в полтора-два.
2. Полнотекстовый поиск. В частности есть поиск лексемы по префиксу ts_tsquery('сло:*') (быстро найдёт и "слово" и "словарь", но не найдёт "однословное")
3. Для полей по которым вы сделаете словари лучше делать поиск через словарь SELECT * FROM table WHERE column_dictionary_id IN (SELECT id FROM dictionary WHERE value LIKE '%текст%'). В словаре у вас наверняка на порядок - три меньше значений, а несколько сотен или тысяч значений в IN постгрес нормально пережуёт.

Полей много, разные даты, guid, названия проектов, данные из поля типа json, цены.

Активнее используйте функциональные и частичные индексы.
Например, у нас есть кадастровые номера. Триграммный индекс по ним весит 56 мбайт, а BTREE по номерам урезанным до кадастровых кварталов - 15 мбайт, в поиске к "cadastre_id LIKE '11:22:333333:1%'" добавился "AND to_quarter(cadastre_id) = '11:22:333333'", но сам поиск получается на порядок быстрее (~5 мсек вместо 50 - 70).
Главное не забывайте о стоимости этих самых функций - индекс по to_quarter может строиться всего в 1,5 раза дольше нефункционального, если делать LEFT(cadastre, -(position(':' IN reverse(cadastre))), а может и в 100 раз, если использовать регулярку.

На все индексы не поставишь, тем более что один индекс может добавить гигов 5-10 к весу.

Если ещё не обновились, то обновляйтесь на 13-ю версию, там размер BTREE индексов уменьшили в 3 раза. Ну и посмотрите, возможно вам где-то нужны GIST, GIN или BRIN индексы.

В GraphQL есть концепция Mutation-ов - по сути просто функции/процедуры, которые можно вызывать.
Так что да - можно.

Сколько людей - столько мнений. Не стоит прям вообще всех слушать, кто высказывает какие-то "гениальные" откровения. Даже внутри крупных фреймворков многие вещи реализованы по разному, и каждый считает что именно так надо, и никак иначе. Думаю автор статьи просто искал дешевого хайпа, на практике никто так не делает. Контроллер по сути не модель, а управляющая конструкция, в ней нормально внутреннее ветвление на методы. С таким же успехом можно решить что для модели нужно 4 репозитория, на каждое действие CRUD...

SELECT ('{"data": "test", "count": 8}'::json->>'count')::int + 2

Ну вижу смысла выносить конкретное поле (флаг) в отдельную таблицу. Потому что ничего хорошего это частное отделение не даст:

1. фактор неожиданности у коллеги: с какого перепугу была необходимость отделения конкретного флага?
   
2. дополнительная таблица, для которой нужен JOIN.
   
3. дополнительный код
   
4. дополнительные миграции и поддержка
   

На мой взгляд все эти настройки должны лежать в отдельной таблице product_settings, ну если уже в коде везде product, а не project. Так как по сути это настройки, а не прямая информация о продукте.

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

На мой скромный взгляд, проблема несколько шире. Вот почему someParam это массив, а не осмысленный объект? Пока его суть остается неопределенной, будут возникать неопределенные ситуации, когда непонятно что делать, падать в ошибку или городить полотно проверок. А ведь можно вынести всю валидацию на этап создания объекта, там же выбрасывать ошибки, так будет явно понятно, что ошибка в данных, а не где-то в логике, где данные уже должны быть.

Сложно понять Вашу картину и что имел ввиду Ваш коллега. Об этом лучше спросить самого коллегу. Однако постараюсь помыслить на эту тему...

1. Конкретно DTO не совсем применима к API в чистом виде и работе с ней. Более правильно в запрос кидать json, а вот этот json уже маппить на вашу DTO, в которой будет высокоуровневая валидация от симфони и php7.4. Пример И само DTO.

2. Так как у вас система микросервисная, то DTO передавать по сети точно не нужно. Вы можете использовать DTO внутри своего приложения, но не использовать его по сети. DTO позволяет Вам в сервис/хэндлер/команду передавать не сам Request и не кучу параметров, а своё DTO, которая должна создаваться на основе запроса. Таким образом вы отделяете слои и ответственности. При изменении названий параметров DTO не обязательно их менять в API и наоборот. Нет зависимости и это хорошо! Так же хорошо и для тестируемости.

3. Если вы упомянули ParamConverter это по сути конвектор параметров, но опять же на уровне приложения, а не между запросами сети) Об использовании его можно почитать в документации симфони. С помощью него можно указать в методе DTO, которую он принимает, а конвектор, написанный вами, знает как это DTO создать на основе ваших переданных данных. То есть вы не DTO передаёте в запрос, а те же параметры, просто этот конвектор делает вам из этих параметров DTO. Использовать его или нет - дело ваше. Вы правильно подметили, что в Yii2 такого нет. Можно заморочиться написать свой, но смысла от этого нет вообще) Использовать DTO я бы рекомендовал. Так как профит будет: разделение слоев, меньшая связанность и возможность валидации. А вот использовать конвектор - решение команды или разработчика. Оно позволяет вам создать вашу DTO на основе переданных параметров. Параметры никуда не денутся, они просто сразу лягут в DTO это один профит - чище код.