Комментарии 9
Сейчас вроде в Symfony рекомендуют использовать AssetMapper вместо Webpack Encore. Реально большая экономия времени на сборке. Но я пробовал его только на простых вещах.
AssetMapper отличное решение, если ваш проект не на scss. Один своей проект где просто bootstrap перевел на AssetMapper и не мог нарадоваться. Больше не нужно было думать о сборках, в дев всё происходило буквально за секунды, в отличие от webpack.
Но вот, другой проект, где всё на scss, ех, даже с подключённым модулем AssertMapper для scss, адекватно завести не получилось, что-то отвалилось. Было конечно решение просто взять готовое решение "скомпилированное" без scss, но тогда вся прелесть простой модификации элементов фронтенда улетают в трубу, как и быстрое нахождение требуемых переменных.
В общем остаётся надеется, что фронтедоры перестанут использовать scss, раз последние версии css, уже имеют весь тот же функционал. Ну или ждать когда AssetMapper сможет нормально работать со сложными scss
symfonycasts/sass-bundle не поможет с scss? У меня тоже scss использовался, но я не сильно глубоко его использовал. Вероятно каких-то сложных вещей просто нет и меня это решение вполне устроило.
я про него и писал в комментарии.
Он помогает, частично, со сложными структурами, динамическими он не работает.
Например есть шкурка, которая заточена на вариант письма слева направо и наоборот. И до момента загрузка оно не имеет состояния (все элементы расплющены по обе стороны), и только после загрузке всех элементов оно принимает одно из состояний. Вот с такими фокусами sass-bundle не справляется.
К слову я говорю про CoreUI.
Можно конечно залезть в код и насильно выставить изначальное состояние, но там дальше ещё больше подводных камней всплывает. В общем я решил это не стоит свеч, тем более я и не фрондендер и не хочу окунаться в эту выгребную яму.
AssetMapper действительно стал рекомендованным решением в Symfony с недавних версий, потому что позволяет упростить конфигурацию и избавиться от перегруженности Webpack. Я пробовал его на среднем проекте, где были Sass и несколько библиотек на JS — сборка стала быстрее и конфиг менее громоздким. Конечно, если вам нужны специфичные плагины или сложная оптимизация, Encore может оставаться удобнее. Но в большинстве типовых проектов AssetMapper уже отлично справляется со сборкой, и команда Symfony будет развивать его как основное решение.
Подскажите пожалуйста, в большинстве случаев мне попадаются бэкендеры на ларе и json всегда отправляют в snake_case. В 2025 у Лары нету нормального сериализатора? Потом у нас вроде существует стандарт ответа https://jsonapi.org/ но я никогда не встречал, чтобы мне прилетело в подобном формате. По идее на беке нужно ведь просто запихнуть коллекцию в сериализитор, чтобы получить на выходе данный формат?
Действительно, Laravel традиционно использует snake_case при сериализации моделей, потому что так исторически сложился конвеншен. При желании его можно переопределить через кастомные сериализаторы или трансформеры (например, Fractal или Laravel Resources), но большинство проектов остаётся на дефолтном snake_case ради совместимости и привычки. Что касается JSON:API — в Laravel есть несколько пакетов (spatie/laravel-json-api, cloudcreativity/laravel-json-api), позволяющих формировать именно такой формат. Но это реже встречается, так как стандарт довольно строгий и требует дополнительной настройки (relationship links, meta-данные и т.п.). На практике многие команды придерживаются простого REST/JSON, не тратя время на соответствие JSON:API. Если вам нужен именно JSON:API, можно встроить один из готовых пакетов или написать собственный сериализатор — технически это возможно, но нужно учитывать, что не все потребители API готовы к этому формату.
Не используйте serializer
Топорнейшее решение которое тянут из версии в версию (под капотом обход графа) если где-то будет в ответе большое дерево и отдача будет без офсета ответ будет прям сильно притормаживать. Лимитирование зависимых сущностей решает проблему, но можно за этим просто не уследить
Сериализатор в Symfony действительно может выглядеть “топорно”, если не контролировать глубину вложенных сущностей. Под капотом он рекурсивно обходит граф объектов, и при неосторожном использовании можно получить гигантский JSON и нагрузку на базу данных.
На практике я решаю эту проблему через:
Группы сериализации (@Groups) — указываю ровно те поля, которые нужны на данном эндпоинте, и не отдаю лишние связи.
DTO / преобразователи — когда нужно очень чётко контролировать структуру данных и не тащить полную модель.
Настройку выборок (fetch joins) и лимиты, чтобы не грузить слишком большое дерево из БД.
Если делать всё осознанно, сериализатор остаётся удобным инструментом, особенно в комплексных проектах, где нужно динамически формировать JSON для разных сценариев. Но вы правы в том, что “из коробки” он может вытащить лишнее и “задушить” производительность, так что приходится внимательно следить за конфигом и архитектурой запросов.
Symfony + React: Основные проблемы и методы их решения