Сериализатор в Symfony действительно может выглядеть “топорно”, если не контролировать глубину вложенных сущностей. Под капотом он рекурсивно обходит граф объектов, и при неосторожном использовании можно получить гигантский JSON и нагрузку на базу данных.
На практике я решаю эту проблему через:
Группы сериализации (@Groups) — указываю ровно те поля, которые нужны на данном эндпоинте, и не отдаю лишние связи.
DTO / преобразователи — когда нужно очень чётко контролировать структуру данных и не тащить полную модель.
Настройку выборок (fetch joins) и лимиты, чтобы не грузить слишком большое дерево из БД.
Если делать всё осознанно, сериализатор остаётся удобным инструментом, особенно в комплексных проектах, где нужно динамически формировать JSON для разных сценариев. Но вы правы в том, что “из коробки” он может вытащить лишнее и “задушить” производительность, так что приходится внимательно следить за конфигом и архитектурой запросов.
Действительно, 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 готовы к этому формату.
AssetMapper действительно стал рекомендованным решением в Symfony с недавних версий, потому что позволяет упростить конфигурацию и избавиться от перегруженности Webpack. Я пробовал его на среднем проекте, где были Sass и несколько библиотек на JS — сборка стала быстрее и конфиг менее громоздким. Конечно, если вам нужны специфичные плагины или сложная оптимизация, Encore может оставаться удобнее. Но в большинстве типовых проектов AssetMapper уже отлично справляется со сборкой, и команда Symfony будет развивать его как основное решение.
Сериализатор в Symfony действительно может выглядеть “топорно”, если не контролировать глубину вложенных сущностей. Под капотом он рекурсивно обходит граф объектов, и при неосторожном использовании можно получить гигантский JSON и нагрузку на базу данных.
На практике я решаю эту проблему через:
Группы сериализации (@Groups) — указываю ровно те поля, которые нужны на данном эндпоинте, и не отдаю лишние связи.
DTO / преобразователи — когда нужно очень чётко контролировать структуру данных и не тащить полную модель.
Настройку выборок (fetch joins) и лимиты, чтобы не грузить слишком большое дерево из БД.
Если делать всё осознанно, сериализатор остаётся удобным инструментом, особенно в комплексных проектах, где нужно динамически формировать JSON для разных сценариев. Но вы правы в том, что “из коробки” он может вытащить лишнее и “задушить” производительность, так что приходится внимательно следить за конфигом и архитектурой запросов.
Действительно, 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 готовы к этому формату.
AssetMapper действительно стал рекомендованным решением в Symfony с недавних версий, потому что позволяет упростить конфигурацию и избавиться от перегруженности Webpack. Я пробовал его на среднем проекте, где были Sass и несколько библиотек на JS — сборка стала быстрее и конфиг менее громоздким. Конечно, если вам нужны специфичные плагины или сложная оптимизация, Encore может оставаться удобнее. Но в большинстве типовых проектов AssetMapper уже отлично справляется со сборкой, и команда Symfony будет развивать его как основное решение.