Зміст
Коротко
На тестовому стенді все летить, а через місяць після запуску 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 у продакшені — це дисципліна запитів, кеш там, де часто читають, і ясне спілкування. Залізо допомагає останнім, коли застосунок уже чесно виміряний і спрощений.