Максим

Для начала данный код нужно отрефакторить и сделать его хотя бы читабельным. Почитайте про рефакторинг, про ООП...

Так как по коду нечего сказать скажу методы для ускорения работы уже написанного кода.

1. Первый вариант это перейти на более последнюю версию php. Например, 7.х, 8.х. Особенно почувствуете разницу при переходе с версии 5.6 на 7.х. Однако какой-то код может сломать. Подходите этому внимательнее.

2. Использовать кэширование. Кэшировать можно как внедрением в вашем коде кэширования, так и расширениями php вроде opcache.

Тут надо не сокращать, а рефакторить код до более понятного использования. Если у Вас PHP >=7.0, то можно применить такую конструкцию:

$this->test[$id] = $this->test[$id] ?? 0;

$response = $this->test[$id] >= 3 ? 'нельзя' : 'получил';

$this->test[$id]++;

echo $response;

Однако от этого особо толку не будет, так как код всё равно не особо читаем

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

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 это один профит - чище код.

public function show(string $slug, RegionFetcher $fetcher): Response
    {
        $region = $fetcher->findOneBy(["name.slug" => $slug]);
        return $this->render('app/admin/location/regions/show.html.twig', ['region' => $region]);
    }

Добавляйте метку времени используя time(), используйте UUID, md5 и т д

Файл .env. Подробно в документации

Если бы вы прочитали документацию и ещё, то Вы бы не задавали подобного вопроса

Уберите это:

$container = \Yii::$container;
$container->setSingleton(Container::class, function () use ($container) {
  return $container;
});

Вы определитесь: Вам нужно поучиться или подобрать стек под проект?

Если поучится, то тут вопроса не стоит. Просто скачивайте Symfony и начинайте. Возможно, Вы потратите больше времени и сил, чем с Laravel. Но зато попробуете для себя новый, перспективный фреймворк. Symfony не сложный. Он просто имеет другие подходы в разработке и требует от разработчика более строгого подхода в написании кода.

Если же Вам нужно подобрать стек, то Laravel отлично подойдёт под текущие задачи. Особенно учитывая то, что Вы его хорошо знаете.

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

Изучение как устроен какой-то Фреймворк тема интересная, так же как и написание своего фреймворка. Но делается это не для того, чтобы написать с нуля свой Фреймворк, а для понимания как и из чего устроены Фреймворки. И нужно это профессионалам, а не новичкам.

С точки зрения практики идея о своём фреймворке не очень хорошая. Вам никогда не хватит сил на развитие и поддержание своего фреймворка. Ведь за большинством Фреймворков стоит большая команда.

Если хотите взять какой-то минимум от фреймворка — рассмотрите микрофреймворки. Например, Slim.

Если кратко — главное чтобы работало, в вашем случае.

Если чуть развёрнуто:

1. Функция в функции плохо. Выносите.
   
2. Весь код в контроллере тоже плохо. Выносите в калькуляторы, сервисы, репозитории.
   
3. Используйте camelCase в переменных.
   
4. Посмотрите в документации как правильно получать через консоль пользовательские данные (input)
   
5. Некоторые комментарии излишние и некоторые названия не логичны. Уберите лишние комментарии и поработайте над неймингом.
   

Это основные моменты. Тут стоит опираться не на код, а на Ваши знания. Вам не хватает знаний и стоит погрузиться в тему рефакторинга, ООП, чистый код и т.д.

Ваш код — результат Ваших знаний.

Зачем вам бандл? Вы что планируете подключать этот код где-то в другом приложении? Бандл это по сути интеграция вашего кода с симфони приложением.

Создавайте папку Api и туда помещайте. Можно сделать и отдельное приложение. Решать вам.

Цитата из документации:

В версиях Symfony до 4.0 было рекомендовано организовать собственный код приложения с помощью пакетов. Это больше не рекомендуется, и пакеты должны использоваться только для совместного использования кода и функций между несколькими приложениями.
Пакет похож на плагин в другом программном обеспечении, но еще лучше. Основные функции Symfony framework реализуются с помощью пакетов (FrameworkBundle, SecurityBundle, DebugBundle и т. Д.) Они также используются для добавления новых функций в ваше приложение с помощью сторонних пакетов.

Попробуйте TSL и порт 587. Если не поможет вышлите конфиг где вы вводите все настройки

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

Формы нужны там, где человек через UI вводит данные. А в AJAX (он же API) данные прилетают не в форму, а обычным POST запросом, который обрабатывается. И если надо валидируется с помощью компонента.

В вашем случае зарос будет такой:
http://phptest/web/index.php?r=post/post

Напишите свой клиент и не мучайтесь) Документацию вам скинули в комментарии