Налаштування, що редагуються адміністратором, без складного коду

Додатки постійно стикаються з однією проблемою. Деякі налаштування мають бути у файлі .env. Інші ж мають змінюватися через панель адміністратора без необхідності повторного розгортання коду. Прикладами можуть бути назви сайтів, часові пояси або налаштування реєстрації.

Багато розробників зберігають їх у базі даних, але створюють безлад. У результаті ви отримуєте два способи читання даних: одна частина вашого додатка використовує config(), а інша — модель бази даних. Це призводить до багів, коли налаштування стають неузгодженими.

Ви можете уникнути цього, використовуючи єдиний шлях читання. Розглядайте базу даних як шар, що накладається на ваш config під час завантаження (boot).

Ось як це реалізувати:

• Використовуйте єдине джерело істини. База даних зберігає значення, але додаток читає їх лише через config(). • Використовуйте типізовані класи. Замість неструктурованих масивів використовуйте класи з суворою типізацією. Це запобігає друкарським помилкам та прихованим помилкам. • Завантажуйте налаштування під час процесу завантаження (boot). Використовуйте service provider, щоб отримати значення з бази даних і передати їх у масив config.

Остерігайтеся цих двох технічних пасток:

1. Пастка часового поясу Laravel встановлює часовий пояс на ранньому етапі процесу завантаження. Якщо ви зміните значення config пізніше, PHP все одно використовуватиме старий часовий пояс. Ви повинні вручну викликати date_default_timezone_set(), щоб синхронізувати глобальне налаштування PHP з вашим новим значенням config.

2. Пастка нової інсталяції У нового додатка немає таблиць у базі даних. Якщо процес завантаження завершиться помилкою через відсутність таблиці налаштувань, додаток не запуститься. Ви не зможете запустити міграції, якщо додаток не може завантажитися. Огорніть логіку налаштувань у блок try/catch. Це дозволить додатку використовувати значення за замовчуванням із .env, доки ви не запустите міграції.

Ще одна порада щодо безпеки: Коли ви вимикаєте таку функцію, як реєстрація, не просто приховуйте кнопку в інтерфейсі (UI). Повністю видаліть цю функцію з config. Якщо ви видалите функцію з config, маршрути (routes) зникнуть. Прихована форма з активним endpoint-ом — це ризик для безпеки. Відсутній маршрут повертає 404.

Тримайте свій код простим. Ваші контролери та представлення (views) не повинні знати, чи прийшло налаштування з файлу, чи з бази даних. Вони мають бачити лише config().

Source: https://dev.to/nasrulhazim/admin-editable-settings-without-giving-up-config-2cj0