Configurações Editáveis pelo Admin Sem Código Complexo

Aplicativos enfrentam um problema constante. Algumas configurações pertencem a um arquivo .env. Outras configurações devem mudar via um painel administrativo sem um novo deploy de código. Exemplos incluem nomes de sites, fusos horários ou configurações de registro.

Muitos desenvolvedores armazenam essas informações em um banco de dados, mas criam uma bagunça. Você acaba com duas formas de ler dados. Uma parte do seu app usa config() enquanto outra usa um modelo de banco de dados. Isso leva a bugs onde as configurações ficam inconsistentes.

Você pode evitar isso usando um único caminho de leitura. Trate o banco de dados como uma camada que sobrepõe sua configuração durante o processo de boot.

Aqui está como construir isso:

• Use uma única fonte de verdade. O banco de dados detém o valor, mas a aplicação apenas lê via config(). • Use classes tipadas. Em vez de arrays soltos, use classes com tipos estritos. Isso evita erros de digitação e erros silenciosos. • Carregue as configurações durante o processo de boot. Use um service provider para buscar os valores do banco de dados e inseri-los no array de configuração.

Cuidado com estas duas armadilhas técnicas:

  1. A Armadilha do Fuso Horário O Laravel define o fuso horário cedo no processo de boot. Se você alterar o valor da configuração mais tarde, o PHP ainda usará o fuso horário antigo. Você deve chamar date_default_timezone_set() manualmente para sincronizar a configuração global do PHP com o seu novo valor de configuração.

  2. A Armadilha da Instalação Nova Um novo app não possui tabelas no banco de dados. Se o seu processo de boot falhar porque a tabela de configurações está faltando, o app não iniciará. Você não pode executar migrações se o app falhar ao iniciar. Envolva sua lógica de configurações em um bloco try/catch. Isso permite que o app utilize os valores padrão do .env até que você execute suas migrações.

Outra dica de segurança: Ao desativar um recurso como o de registro, não apenas esconda o botão na interface (UI). Remova o recurso da configuração inteiramente. Se você remover o recurso da configuração, as rotas desaparecem. Um formulário oculto com um endpoint ativo é um risco de segurança. Uma rota ausente retorna um 404.

Mantenha seu código simples. Seus controllers e views não devem saber se uma configuração veio de um arquivo ou de um banco de dados. Eles devem apenas ver o config().

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