Содержание
Коротко
На тестовом стенде всё летает, а через месяц после запуска API тормозят, панели мониторинга грузятся секундами, а команда ищет «более мощный сервер». Команда Spice Factory Philippines на Dev.to описала шесть типичных ошибок в Laravel-проектах для клиентов: от злоупотребления Eloquent до недооценки кэша и переписки с заказчиком. Почти все проблемы оказались на уровне приложения, а не инфраструктуры.
Что произошло
Eloquent ускоряет старт, но скрывает цену запросов. Авторы ловили N+1: связи подгружались в циклах, одна конечная точка API размножала десятки SQL-запросов, в ответ уходили лишние поля. Достаточно было явно указать with('roles') и проверить запросы через Telescope или лог — и задержки падали без смены железа.
Второй миф — «медленный API = слабый виртуальный сервер». На практике чаще виноваты отсутствующие индексы, повторные выборки одних и тех же данных и лишние соединения таблиц там, где хватило бы одного агрегата. После чистки схемы и запросов время ответа улучшилось на том же хостинге.
Кэш казался опцией «на потом», пока не пошла реальная нагрузка на отчёты и панели мониторинга. Простой Cache::remember на минуту для тяжёлых агрегатов снял заметную часть нагрузки с базы.
По мере роста код в контроллерах перестал помещаться в голове. Полную переработку не делали — логику постепенно выносили в сервисы, когда функциональность «разъезжалась». Это упростило совместную работу нескольких разработчиков.
В клиентских проектах сроки сдачи меняют приоритеты: сначала рабочий и стабильный релиз, потом полировка. И наконец, неясные требования обходились дороже, чем «умный» код — уточнение на старте экономило недели переделок.
Почему это важно
Учебники показывают синтаксис Laravel, но редко — как система ведёт себя под ежедневной нагрузкой. Слой ORM не виноват сам по себе: проблема в том, что удобство маскирует лишние обращения к PostgreSQL или MySQL. Тот же паттерн встречается в Django, Rails и TypeORM — «удобно писать, больно отлаживать».
Отдельно стоит кэш: без него база становится узким местом на экранах с частым чтением. А структура кода и договорённости с бизнесом напрямую влияют на то, успеете ли вы вообще дойти до оптимизации до дедлайна.
На практике
- На каждую новую конечную точку API смотрите число SQL-запросов; для списков всегда планируйте предзагрузку связей.
- Перед обновлением виртуального сервера проверьте индексы, размер выборки и дублирующиеся запросы в одном HTTP-запросе.
- Кэшируйте дорогие агрегаты для панелей мониторинга с коротким сроком жизни записи и явным сбросом кэша при изменении данных.
- Выносите растущую логику из контроллеров в сервисы по мере боли, а не «когда-нибудь потом».
- Фиксируйте требования письменно до начала итерации — это дешевле, чем переписывать API.
Итог
Шесть уроков сводятся к одному: производительность Laravel в продакшене — это дисциплина запросов, кэш там, где читают часто, и ясное общение. Железо помогает последним, когда приложение уже честно измерено и упрощено.