Обычная пагинация через смещение (LIMIT 10000,20) медленнеет с каждой страницей. База всё равно читает первые 10 000 строк, перебирает их и выбрасывает. Чем дальше страница, тем больше пустой работы.
Курсорная пагинация обходится без смещения. Приложение запоминает значение колонки сортировки на границе страницы, например last_message_at. Следующую страницу оно берёт через WHERE last_message_at <= ? и LIMIT 0,20. Если колонка в индексе, скорость почти не зависит от глубины.
В одном тесте на MySQL 8.4 и 300 000 строк страница 4000 открывалась за 127 мс через смещение и за 3 мс через курсор. В Doctrine ORM 3.7 для этого появляется класс CursorPaginator.
Подвох в том, что прыгнуть сразу на страницу 57 нельзя. Доступны только первая, следующая и последняя.
Если по вашим длинным спискам ходят краулеры или API-клиенты, самое время посмотреть, как выглядит переход в коде.
Демо с AI чаще всего выглядят одинаково: агент за десять минут пишет сервис с нуля.
Вот только в работе бэкендера всё сложнее: легаси, рискованные миграции, неработающие тесты и ревью, которое становится бутылочным горлышком.
🗓 С 26 по 30 октября в сезоне Podlodka Backend Crew «AI в бэкенд-задачах» участники:
• Научатся передавать агенту инженерные стандарты и правила, чтобы он писал так, как нужно, а не как получится
• Соберут ревью, где несколько моделей независимо проверяют изменения, а финальное решение остаётся за человеком
• Посмотрят, куда переезжает сложность миграции легаси, когда код пишет агент
• Выяснят, где ломается мечта отдать миграцию агенту целиком
• Разберут, какие антипаттерны тестов агенты уже успели перенять от разработчиков.
Формат — пять дней живых Zoom-сессий утром и вечером, закрытое сообщество в Telegram и общение со спикерами.
Будет много интерактива и практики. Базовый ликбез оставят за бортом — этот сезон для тех, кто уже пробует AI в реальных проектах. Присоединяйтесь с 26 октября!
✨ Symfony 8.2: контроллер, который не запустится дважды одновременно
Некоторые действия нельзя запускать параллельно: импорт каталога, оплату заказа, продажу последних билетов. Раньше блокировку через компонент Lock приходилось брать и снимать вручную прямо в контроллере.
В Symfony 8.2 хватит атрибута #[Lock]. Пока запрос выполняется, второй с тем же ключом получит 409 Conflict, а с blocking: true подождёт. Ключ можно собрать из параметра маршрута, тогда у каждой конференции своя блокировка:
#[Route('/conference/{conference}/tickets', methods: 'POST')]
#[Lock('ticket-sale-{conference}', blocking: true, ttl: 10)]
public function buyTicket(Conference $conference): Response { /* ... */ }
Подвох в TTL: по умолчанию блокировка живёт 30 секунд и сама не продлевается. Если контроллер работает дольше, её захватит другой запрос.
Продлить её или отпустить раньше можно, если принять LockInterface аргументом контроллера.
🧩 Исключение, которое само объясняет, что сломалось
Обычно ошибку бизнес-логики бросают как InvalidArgumentException с текстом. Это работает, пока не понадобится поймать именно её. Тот же класс летит ещё из десятка мест.
В Spatie, где пишут хелпдеск There There на Laravel, заводят свой класс на каждую доменную ошибку. На каждую причину в нём есть статический метод. Код читается как фраза:
Метод принимает типизированный $message. Поэтому текст ошибки без id и типа сообщения просто не собрать.
Одна тонкость: такие классы помечают интерфейсом ShouldntReport, и они не попадают в трекер ошибок. Это ожидаемые ситуации от действий пользователя, а не баги, так что трекер не засоряется.
Выглядит как оверинжиниринг ровно до первого раза, когда нужно поймать конкретную ошибку.