Shurik

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

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

Почему не сначала интерфейс - просто потому что вы изначально не представляете себе все требуемые методы. Это будет видно только из практики.

Таким образом вы и задачу решите оптимальным способом (локально), и опыт получите (причём в первую очередь в программировании), и гибкость добавите - если вдруг надо будет перейти на облако (причём не обязательно именно на это) то это будет проще сделать просто написав ещё один адаптер, но не трогая основной код

Чем больше зависимостей, тем сложнее поддержка в будущем.

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

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

Я настоятельно рекомендую не городить лишних сущностей и хранить файлы на том же веб сервере как статические. Если нужны ограничения доступа, то используй штатные инструменты авторизации веб сервера либо свой велосипед. Это 10-15 строк кода, например файлы изначально хранятся в не опубликованном каталоге, а при предоставлении доступа к файлу в публичном создается симлинк, в имени которого id сессии (например id_сессии/id_файла причем если доступ сразу ко всем файлам, то достаточно линка на каталог по id_сессии), а при отзыве доступа, удаляются все симлинки с указанным id сессии.

Бонусом получаешь максимально ресурсоэффективный способ хранения и публикации файлов, минусом наверное только свой uploader писать (в наше время начинающие разработчики просто обязаны пройти через написание своих велосипедов типа upload файла, обслуживание очереди задач по времени и т.п. иначе такое городят, смотреть на этот кошмар невозможно)

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

3. Вебсокет и unix сокет - это совершенно разные вещи. Websockets - это протокол обмена информацией по TCP/IP.
Как работают websockets:
- Клиент начинает с простого HTTP запроса с просьбой апгрейднуться до websockets.
- Сервер соглашается, и тогда между Клиентом и Сервером устанавливается постоянное TCP/IP соединение, по которому данные могут ходить туда-обратно по протоколу websockets уже без кучи церемониальных ритуалов, как принято в обычном HTTP.

1. Изначально PHP совершенно не подходил для постоянного соединения, потому что он создавался как скриптовый язык. Скрипт должен был отработать один раз и почистить все следы своего выполнения. Поэтому создатели особо не заботились об утечках памяти и т.д. В результате было очень обременительно создавать постоянно-живущие процессы, необходимые для websockets. Но в настоящее время PHP очень сильно развивается, разработчики уделяют очень много внимания такому сценарию использования языка. PHP стал производительнее и гораздо надёжнее работает с памятью. Однако, напрямую реализовывать долгоживущий сервис самому всё еще муторно, поэтому лучше всего использовать отличные сторонние фреймворки/библиотеки.

2. Что можно использовать:
- Ratchet
- Swoole / OpenSwoole
- Workerman

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

Разумеется можно. Никаких нюансов в одновременной работе нет, поскольку тут нет никакой "одновременности". php-fpm и websocket - это два разных сервиса, которые могут располагаться на одном и том же сервере или на разных, но в любом случае никак не пересекаются. В добавление к текущему веб-серверу вы просто запускаете вебсокет сервер и посылаете на него вебсокет запросы из браузера.

Ну то есть вам всего лишь надо осознать, что никакой одновременности нет, а дальше просто поставить вебсокет сервер, например workerman, и написать код, который по запросу будет соединяться с БД, получать нужную инфу и отправлять клиенту.

1. Да.
2. Как говорилось выше - можно. Любой сервер в сети по определению обеспечивает работу множества сервисов, количество которых ограничено только количеством свободных портов. Можно поставить два веб-сервера и пять вебсокет серверов.
3. Нет, разумеется. unix сокет это как раз внутренняя кухня сервера, но мы же говорим о сетевом взаимодействии. А tcp взаимодействие nginx и php-fpm тут вообще не при чём.

Да, подходит.

websocket это расширение http запроса, т.е. там добавляются специфические заголовки и можно отправлять туда-сюда пакеты в одном соединении.

Для этого приложение на php нужно реализовывать в виде http сервера (готовых библиотек тьма, включая штатные расширения), рекомендуется использовать swoole ну или по старинке на сокетах (библиотеки phpreact)

xdebug

Как человек, который в своё время так переусложнял код, что потом сам не понимал, что и где в проекте происходит, посоветую вам использовать самый лучший принцип на свете - "KISS"

Поэтому, ничего сложного пока не выдумывайте, поверьте, вы всегда сможете потом всё усложнить)))

Я бы сделал так:

• В контроллере сериализуем JSON в DTO ( можно вообще вот так https://symfony.com/blog/new-in-symfony-6-3-mappin... )
  
• Далее создаёс сервис, который будет нашим маппером, и который будет иметь 2 метода "fromDtoToEntity" и "fromEntityToDto", и он будет заниматься всеми преобразованиями туда-сюда.
  
• В этом маппере пишем наитупейшую логику, как вы и писали $user-setAge($DTO->getAge());
  
• Отдаём клиенту ответ из контроллера
  

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

Человечество развивается, люди становятся умнее, начинают наконец понимать стандарты. Ну, кроме разработчиков битрикса, конечно.

Для подобных целей существует функция method_exists.

Ваш вариант хоть и рабочий но очень дорогой по ресурсам сервера.

И вообще, что проверяется публичным ключок - сам токен или его подпись.

Подпись в самом JWT (JWS).

при ее валидности потом декодируется вручную payload токена и вычисляется по меткам времени его валидность

Всё верно.

где лучше производить валидацию токена в случае SPA приложения: на фронтенде при каждом запросе к серверу, либо же на бэкэенде получаю при каждом запросе access_token с фронта?

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

Единственное, что стоит проверять на фронте, это срок действия токена. Если он истёк, нужно получить новый токен.

Потому что библиотека не может скачивать изображения по ссылкам. Изображения же в base64 встроены в страницу и не требуют скачивания

В отличие от strlen(), iconv_strlen() учитывает кодировку строки. Длина string не обязательно будет соответствовать количеству байт в ней, так как в различных кодировках различные символы кодируются различным количеством байт, например, юникод может быть и двух-, и четырёхбайтным.

попробуйте mb_substr с указанием кодировки