Максим

Недолгоживущий JWT Access Token (5-15мин), который после того как просрочится сделает доступ к сервису невозможным.

Но чтобы каждые 5 минут не простить залогиниться пользователя изобрели RefreshToken, который хранится в базе дольше. Примерно 1 месяц. Он нужен для того, чтобы выпустить новый JWT AccessToken. При взломе RefreshToken просто удаляется и новый AccessToken выпустить не получиться. Почитайте в целом про OAuth 2.0 + JWT

Вы сначала изучите Фреймворк. Сходите в документацию, прежде чем писать такой код. Например, зачем использовать такие конструкции $_POST['pages']; Так же для отладки используется не контроллер, а провайдер. И функции dump. Для симфони, как и для других это всё давно продумано.

Смотря для чего вы делаете эти try catch. Это не всегда повторяемость иногда действительно нужна, например, чтобы перебросить своё исключение. Пойти можно разными способами. Но а простой - это вам нужно просто их убрать и сделать Listener или Subscriber, который будет обрабатывать ошибки и отдавать их в нужном формате в api. Если правильно понял для чего нужно. Пример.

1. Не мыслите таблицами - ничего хорошего не выйдет
2. Хранить можно также в NoSQL, что даже лучше. Например, redis.

Настройте время. Скорее всего установлен не верный часовой пояс (UTC)

(new DateTimeImmutable($array["Date"]))->format('F d, Y');

Серверная ошибка. Смотрите логи или включайте debug панель.

Гдето в вашем вызове вызывается null, поэтому возникает данная ошибка.

Это точно об X-debug.

Умение им пользоваться будет полезным в использовании незнакомого вам кода. Большинство ошибок можно найти данным инструментом более быстро, чем расставлять везде dd(). Вам нужно поставить одну точку, а дальше полный набор отладки.

Но мне не очень понятно зачем отлаживать свой код. Если код написан читаемо, то отлаживать его нет необходимости - достаточно покрыть его тестами. Даже если возникнет какая-то ошибка, то найти её можно быстро. Я ещё ни разу не пользовался X-debug для отладки именно своего кода. Код читаем и ошибка находится быстро. Более того, дошёл до того, что даже браузер не открываю, так как занимаюсь только backend частью. Мы недавно сдали проект с хорошим кодом и на демо-версии не было ни одной 500 ошибки, а покрытие тестов было всего 35%.

Поэтому тесты+читаемый код может вообще избавить вас от необходимости настройки данного инструмента. Разве что нарвётесь на какой-то баг библиотеки. Вот тогда и придётся «расчехлять» данный инструмент.

Архитектура вообще не относится никак к фреймворку.

Из примеров могу посоветовать пример проекта Дмитрия Елисеева на slim. И ещё есть доклад от Валентина Удальцова про архитектуру на Symfony.

1. Kernel хранить в src, если он один.
2. Миграции можно src/Data/Migration Или src/Migration
3. Тесты, если общие (функциональные), то в /tests, а если unit, то в папку, где фича src/Feature/Test

Из вашей структуры я бы вынес Console и Controllers в одну папку на уровне с Feature.

Так же сервисы я бы тоже не делал всё в одном services.yaml, а выносил бы в config/services/feature.yaml Или в каждую фичу.

Сложно понять о чём вы пытаетесь спросить, но попробую пояснить.

Интерфейс должен всегда храниться в слое или модуле, где он используется. Интерфейс так же создаёт абстракцию и создан для уменьшения связанности.

Например, вам нужно оправлять уведомления из модуля магазина в модуль уведомлений. В магазине вы делаете интерфейс (API) через который магазин будет отправлять уведомления. Саму реализацию можно оставить и в магазине, но лучше вынести в src/Infrastructure. В этой папке можно хранить все инфраструктурные вещи.

Так же можно использовать пример из DDD где есть деление на слои Application, Domain, UI, Infrastructure. В этом случае в Domain может быть RepositoryInterface, а в Infrastructure реализация DoctrineRepository

Что касается абстрактных классов, то храните их там, где вы их используете или реализуете. Это может быть где угодно. Абстрактный класс, в первую очередь, класс! Он создан для общей базовой логики в классах, но при этом его нельзя вызвать через new()

unlink() - удалить файл.

Не совместный с интерфейсом класс.
Не хватает параметра $userLang = App\Domain\Repository\Language::FR В классе App\Domain\Repository\ChoiceRepositoryInterface

Достигнут количественный лимит на вызов метода VK API.

Лимит не зависит от способа и метода запроса, а зависит от количества запросов. Лимиты считаются на каждого клиента (client_id). Поэтому обойти его не удастся. Снизите лимиты обращений и используйте кэш.

Лимиты: https://vk.com/dev/data_limits

Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.

В PHP, в отличии от других некоторых языков конструктор один. Из-за чего объект нельзя создать несколькими способами, с другими бизнес правилами. Поэтому принято конструктор делать приватным, а объект создавать через фабричные методы вроде create(), requestJoinByEmail(), joinByNetwork() и другие.

Возьмём всем известных User-ов, которые могут появиться в нашей системе по-разному:

1. Создание пользователя Администратором через метод create().
2. Регистрацией пользователя по Email через метод requestJoinByEmail().
3. Регистрацией пользователя через социальную сеть через метод joinByNetwork().

Таким образом наш объект становится более гибким и содержит в себе разные бизнес требования к состоянию в зависимости от способа его создания.

Чтобы хорошо понять суть рекомендую прочитать полезный ресурс — Refactoring Guru - Фабричный метод.

Это формат электронно цифровой подписи прочитать его можно только при наличии второй части ключа.

Это закодированная информация, чаще всего способом base64, а иногда openssl_sign(). То есть это закодированные данные. Прочитать можно при наличии ключа (возможно и ещё других данных) и понимании какой алгоритм был декодирования.

Используйте для декодирования функцию json_decode(), но с вашей строкой что-то явно не так.

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

Первое с чего нужно начать это проанализировать какое хранилище вам подойдёт, возможно это будет даже не реляционная БД, а какая-то NoSQL. Подробнее о выборе хранилища можно почитать статью на Хабр: https://m.habr.com/ru/post/487498/

Даже если вы не хотите изменять хранилище MySQL на какую-то другую, то вам следует подумать о денормализации данных в отдельные таблицы. Благодаря чему вам не придётся делать сложные JOIN запросы, а все данные будут уже в готовом виде с своих таблицах. Такие данные будут во много раз быстрее выгружаться в отчёты, но и нужно будет следить за актуальностью данных. Собирать эти данные можно по разному: по событиям на этапе создания/изменения/удаления, по крону, по запросу.

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

Для большего ускорения следует отказаться от объектов в пользу массивов. Особенно если запросы идут в базу не на простом SQL, а через какую-то ORM вроде Doctrine. В доктрине происходит маппинг данных на объекты, что очень сильно замедляет работу с данными.

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