Ларавель часто дає прості інструменти для задач, які з часом стають складнішими, ніж здавалися спочатку. У цій категорії я збиратиму невеликі спостереження з реальної роботи: про Pipeline, сервіси, черги, події, тестування та інші рішення, які допомагають упорядковувати код.
Парольний вхід і Google OAuth можуть давати різні гарантії щодо email, тому одна перевірка після входу не завжди правильна. Розбираю, коли локальне підтвердження email потрібне, коли його можна не дублювати і чому вимкнене підтвердження email не повинно випадково блокувати OAuth-користувачів.
Відсутнє джерело переходу не завжди означає втрату даних. Прямий вхід, скопійоване посилання, месенджер, мобільний застосунок або видалений Referer можуть чесно залишити джерело невідомим. Головне - відрізняти об’єктивно невідоме походження від помилки власного відстеження.
Якщо сторінка адмінки лише показує фактичний стан налаштувань, а різні групи зберігаються в одній таблиці, завантаження всіх Settings-класів може бути зайвим. Для режиму лише читання інколи простіше й точніше прочитати таблицю напряму, не перетворюючи цей підхід на обхід правил запису.
WebSocket добре підходить для миттєвого оновлення інтерфейсу, але подія може бути пропущена. Вкладка могла спати, мережа могла зникнути, ноутбук - прокинутися після паузи. Тому оперативні події варто поєднувати з HTTP-оновленням, яке відновлює фактичний стан.
Нова функція не завжди означає нову таблицю. Якщо в системі вже є модель гілки обговорення та повідомлень, публічна дискусія може бути окремим сценарієм використання тієї самої моделі. Але спільне зберігання не повинно змішувати правила доступу, доменні події та поведінку різних частин системи.
Якщо перевіряти блокування лише під час входу, уже відкриті сесії можуть продовжити працювати. Надійне блокування має враховувати активні сесії, кеш дозволів, захищені запити, історичні дані та правильну поведінку після розблокування.
Різниця між загальною кількістю переглядів і кількістю переглядів без повторів може бути кориснішою за кожен показник окремо. Якщо загальна кількість переглядів різко зростає, а кількість переглядів без повторів майже не змінюється, це привід перевірити, чи не пов’язане таке зростання з повторними запитами або автоматизованою активністю.
Гість може створити звернення ще до реєстрації, а після створення облікового запису система має безпечно прив’язати ці дані до нового користувача. Email може бути містком між двома станами, але сам процес має бути захищений від повторного запуску, гонок і помилкового захоплення чужих записів.
Queued listener може виконатися повторно після retry, timeout, часткового збою або повторної події. Тому бізнес-операція за listener має бути безпечною при повторному запуску, а друге виконання не повинно створювати дублікати чи повторні side effects.
Security bug не завжди означає, що middleware написаний неправильно. Іноді правило правильне для одного типу користувачів, але endpoint помилково живе в route group іншої authorization boundary.
Якщо usage_count можна повністю відновити з канонічних зв’язків, він не є джерелом істини. Події можуть загубитися, старий код залишити drift, а міграції обійти звичний flow, тому для похідних лічильників потрібен безпечний шлях повного перерахунку.
Коли бізнес-вимога змінює момент запуску процесу, недостатньо підключити нову подію. Старі listeners, guards, services і тести можуть і далі непомітно реалізовувати попереднє правило життєвого циклу.