Для нас при выборе была важна не только скорость самого фреймворка, но и то, что backend должен был стать основой довольно большой системы: API, административной части, бизнес-логики, интеграций и работы с большим каталогом.
В процессе эксплуатации основные проблемы с производительностью у нас чаще оказывались не на уровне Symfony как такового, а в запросах к БД, объёме обрабатываемых данных, интеграциях и кэшировании. Поэтому переход на более лёгкий фреймворк сам по себе вряд ли дал бы тот эффект, который можно получить оптимизацией этих участков.
Но Slim 4 для более компактного сервиса или отдельного API действительно интересный вариант. Любопытно, на каких объёмах у вас разница между Symfony и Slim становилась уже заметной именно в production?
Информация
В рейтинге
1 710-й
Зарегистрирован
Активность
Специализация
Архитектор программного обеспечения, Руководитель разработки и архитектуры ПО
Для нас при выборе была важна не только скорость самого фреймворка, но и то, что backend должен был стать основой довольно большой системы: API, административной части, бизнес-логики, интеграций и работы с большим каталогом.
В процессе эксплуатации основные проблемы с производительностью у нас чаще оказывались не на уровне Symfony как такового, а в запросах к БД, объёме обрабатываемых данных, интеграциях и кэшировании. Поэтому переход на более лёгкий фреймворк сам по себе вряд ли дал бы тот эффект, который можно получить оптимизацией этих участков.
Но Slim 4 для более компактного сервиса или отдельного API действительно интересный вариант. Любопытно, на каких объёмах у вас разница между Symfony и Slim становилась уже заметной именно в production?