Admin-Editable Settings Without Complex Code
アプリケーション開発において、常に直面する問題があります。一部の設定は .env ファイルに置くべきですが、他の設定は、新しいコードのデプロイなしに管理パネルから変更できる必要があります。例としては、サイト名、タイムゾーン、登録設定などが挙げられます。
多くの開発者はこれらをデータベースに保存しますが、その結果、管理が混乱してしまいます。データの読み取り方法が2通りになってしまうのです。アプリの一部では config() を使い、別の部分ではデータベースモデルを使うといった状況です。これにより、設定に不整合が生じるバグが発生します。
これを回避するには、単一の読み取りパスを使用します。データベースを、起動時に設定（config）の上に重ね合わせるレイヤーとして扱います。
実装方法は以下の通りです：
• 単一の真実のソース (Single Source of Truth) を使用する。値はデータベースに保持しますが、アプリケーションは config() を通じてのみ読み取ります。
• 型定義されたクラスを使用する。緩い配列の代わりに、厳密な型を持つクラスを使用します。これにより、タイポやサイレントエラーを防ぐことができます。
• 起動プロセス中に設定をロードする。サービスプロバイダーを使用してデータベースの値を抽出し、それらを config 配列に注入します。
次の2つの技術的な罠に注意してください：
タイムゾーンの罠 Laravelは起動プロセスの早い段階でタイムゾーンを設定します。後から
configの値を変更しても、PHPは依然として古いタイムゾーンを使用します。グローバルなPHPの設定を新しいconfigの値と同期させるには、手動でdate_default_timezone_set()を呼び出す必要があります。新規インストールの罠 新しいアプリにはデータベースのテーブルが存在しません。設定テーブルがないために起動プロセスが失敗すると、アプリは起動できなくなります。アプリが起動できないと、マイグレーションを実行することもできません。設定のロジックを
try/catchブロックで囲んでください。これにより、マイグレーションを実行するまで、アプリは.envのデフォルト値にフォールバックできるようになります。
セキュリティに関するもう一つのヒント：
登録のような機能を無効にする場合、UI上でボタンを隠すだけでは不十分です。config からその機能を完全に削除してください。config から機能を削除すれば、ルート（routes）も消えます。エンドポイントが生きていてフォームだけが隠れている状態は、セキュリティリスクになります。ルートが存在しなければ、404が返されます。
コードはシンプルに保ちましょう。コントローラーやビューは、設定がファイルから来たのかデータベースから来たのかを知る必要はありません。それらは config() だけを見ればよいのです。
Source: https://dev.to/nasrulhazim/admin-editable-settings-without-giving-up-config-2cj0