Сергей Протько

бряки, брэйкпоинты, точки остановы...

Не могу решится что выбрать symfony или laravel.

Для CRUD-а, если на сервере не будет ровным счетом никакой бизнес логики, лучше возьмите laravel, быстрее сделаете.

от фрейма требуется только работа с базой и частичная валидация, кэширование, работа сессиями.

А еще предоставление нормальной платформы для организации HTTP API но это мелочи да.

Думаю что больше редис.

redis универсальнее, но сложнее. В принципе тупо как key-value разница не существенна.

Если есть возможность работать с вебсокетом, то будет хорошо, а если нет, то ajax.

ajax (или XmlHttpRequest) это просто возможность делать HTTP запросы из браузера. То есть это поддерживают по дефолту все существующие фреймворки ориентированные на HTTP.

Что до websockets - тут вам придется всеравно делать отдельное приложение, можно на пыхе но дешевле и проще взять node.js + socket-io. Причем не обязательно при этом все писать на node.js. Ваша апишка может быть реализована на PHP, и через очередь сообщений (redis умеет pub/sub и mq) просить другое приложение (простенькое на node.js + socket.io) отправить пользователям сообщения.

Для авторизации в этом случае рекомендую JWT, так как тогда не нужно будет node.js-у стучаться в php приложение для подтверждения авторизации. Достаточно проверить сигнаруру токена и достать данных из оного. Опять же куча готовых решений как для symfony, так и для laravel и для socket-io.

Ну и да, если у вас реально сервер нужен только в качестве клиента для базы данных + валидация - рассмотрите вариант использования инструментов типа loopback.io и прочего.

https://github.com/symfony/symfony/issues/8703

Для конкретики стоит указать версию PHP, но сам по себе symfony ничего с настройками php не делает. Он разве что вешает свой хэндлер ошибок.

Был не прав. Пруф.

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

Ну а так от проекта зависит. Если нужно писать новый функционал, я бы еще обернул все это в HttpKernel симфоневский, и новый функционал писал бы уже на Symfony (если бюджет клиента позволяет, и если в этом есть смысл).

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

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