Настройки, редактируемые администратором, без сложного кода

Приложения постоянно сталкиваются с одной и той же проблемой. Одни настройки должны храниться в файле .env, другие — меняться через панель администратора без необходимости повторного развертывания кода. Примеры: названия сайтов, часовые пояса или настройки регистрации.

Многие разработчики хранят такие данные в базе данных, но создают хаос. В итоге получается два способа чтения данных: одна часть приложения использует config(), а другая — модель базы данных. Это приводит к багам, когда настройки становятся несогласованными.

Этого можно избежать, используя единый путь чтения. Относитесь к базе данных как к слою, который накладывается на ваш конфиг при загрузке приложения.

Вот как это реализовать:

• Используйте единый источник истины. Значение хранится в базе данных, но приложение читает его только через config(). • Используйте типизированные классы. Вместо неструктурированных массивов используйте классы со строгой типизацией. Это предотвратит опечатки и скрытые ошибки. • Загружайте настройки во время процесса загрузки (boot process). Используйте service provider, чтобы извлечь значения из базы данных и поместить их в массив конфигурации.

Остерегайтесь этих двух технических ловушек:

  1. Ловушка часового пояса Laravel устанавливает часовой пояс на раннем этапе загрузки. Если вы измените значение в конфиге позже, PHP все равно будет использовать старый часовой пояс. Вам нужно вручную вызвать date_default_timezone_set(), чтобы синхронизировать глобальную настройку PHP с новым значением из конфига.

  2. Ловушка чистой установки У нового приложения еще нет таблиц в базе данных. Если процесс загрузки прервется из-за отсутствия таблицы настроек, приложение не запустится. Вы не сможете запустить миграции, если приложение не может загрузиться. Оберните логику настроек в блок try/catch. Это позволит приложению использовать значения по умолчанию из .env, пока вы не запустите миграции.

Еще один совет по безопасности: При отключении такой функции, как регистрация, не ограничивайтесь простым скрытием кнопки в интерфейсе. Полностью удалите эту функцию из конфигурации. Если вы удалите функцию из конфига, маршруты (routes) исчезнут. Скрытая форма с рабочим эндпоинтом — это риск безопасности. Отсутствующий маршрут возвращает 404.

Пишите простой код. Ваши контроллеры и представления (views) не должны знать, пришла настройка из файла или из базы данных. Они должны видеть только config().

Источник: https://dev.to/nasrulhazim/admin-editable-settings-without-giving-up-config-2cj0