Symfony 4: Melhores Práticas
Qualquer versão principal de um projeto é uma oportunidade para revisitar suas melhores práticas. Modernizando-as. Adaptando-as aos novos recursos do projeto. O Symfony 4 não é exceção.
Padronização primeiro
O Symfony 4 será uma evolução das práticas atuais, tentando abraçar mais ferramentas de padrozinação.
Symfony se esforça para abraçar os padrões PHP e web. É difícil acreditar que o Symfony 2 começou em um momento onde oComposer não existia. Desde então, a comunidade PHP iniciou o grupo Fig, Que adotou várias recomendações. OSymfony foi um das primeiros frameworks principais a adotar a maioria dos PSRs, sem quebrar a compatibilidade com versões anteriores. PSR-3 para log há muitos anos. PSR-4 para autoloading. Mais recentemente, o PSR-6 para armazenamento em cache. A próxima versão do Symfony, a 3.3, implementa o PSR-16 para armazenamento em cache e o novo PSR-11 para interoperabilidade de containers. Podemos até ter um caso de uso para PSR-13.
O uso de padrões ajuda com a interoperabilidade, mas também com o desacoplamento de seu código do framework.
Aplicações sem Bundles
A mudança para aplicações sem bundles foi explicada na publicação anterior do blog. Está sendo mencionada novamente, pois essa é uma mudança importante no conjunto atual de melhores práticas.
Variáveis de Ambiente
O livro atual de melhores práticas do Symfony explica detalhadamente como criar configurações em uma aplicação Symfony. Quando usar app/config/parameters.yml para configuração relacionada à infraestrutura ou app/config/config.yml para configuração relacionada à aplicações.
É recomendado evitar o uso de app/config/config.yml o máximo possível. Existem casos de uso válidos, mas podem ser contados em uma mão.
O Symfony 4 não terá o equivalente a app/config/parameters.yml. Use variáveis de ambiente em vez disso. É o que a maioria dos frameworks faz em outras linguagens. Essa é também uma das recomendações do Manifesto Aplicação 12-Fatores. Que é encorajado por muitas plataformas de hospedagem modernas.
Usar variáveis de ambiente, embora longe de ser perfeito, possui muitos benefícios sobre o que fazemos atualmente. As variáveis de ambiente são uma maneira mais “padrão” de gerenciar as configurações que dependem do ambiente (não é necessário gerenciar um parameters.yml.dist, por exemplo). As variáveis de ambiente podem ser lidas por várias aplicações, pois são independentes do seu código, framework e linguagem. As variáveis de ambiente ajudam com deploy de sistema de arquivos somente leitura, pois estão desacopladas do seu código. Os valores das variáveis de ambiente podem ser alterados “dinamicamente” sem precisar de um novo deploy da sua aplicação (limpando o cache para o Symfony). Por último, mas não menos importante, as variáveis de ambiente podem ser gerenciadas por ferramentas existentes.
Observe que armazenar segredos em variáveis de ambiente não é mais “seguro” do que armazená-los em um arquivo de configuração.
Como o uso de variáveis de ambiente pode ser complicado durante o desenvolvimento, o uso de um arquivo .env “padrão” é mais fácil e recomendado. O Symfony 3.3 vem com um novo componente Dotenv que será usado por padrão em aplicações Symfony 4. Alternar entre um arquivo .env e variáveis de ambiente “reais” será feito de forma automática e transparente.
Note que você também pode definir as variáveis de ambiente em um arquivo parameters.yaml se isso parecer melhor para você. Essa não será a maneira recomendada. Observe que parameters.yaml não é um erro de digitação de parameters.yml! Essa é outra mudança no Symfony 4, que será discutida em um artigo posterior.
Como um efeito colateral agradável, ajuda a simplificar como o ambiente Symfony e a flag de depuração são manipulados tanto pelo console quanto por aplicações web.
Atualmente, a ferramenta console do Symfony pode receber o ambiente e a flag de depuração através das flags--env e --no-debug. Ou, alternativamente, através das variáveis de ambiente SYMFONY_ENV e SYMFONY_DEBUG.
Com o Symfony 4, isso não é mais necessário. APP_ENV e APP_DEBUG podem ser usadas tanto para o front controller web quanto para a ferramenta de console.
Sem mais ./bin/console foo:bar --env=prod --no-debug ou SYMFONY_ENV=prod SYMFONY_DEBUG=0 ./bin/console foo:bar. Basta usar ./bin/console foo:bar.
Simplesmente funciona. Em servidores de desenvolvimento e em produção.
Symfony 4 está repleto de tais simplificações.
Front Controller Web Unificado
O Symfony 3 possui dois front controllers web. Um otimizado para produção. Um otimizado para o desenvolvimento. O Symfony 4 usa apenas um. Não é necessário remover mais o front controller web de desenvolvimento. Não há mais problemas de segurança se você esquecer.
Você pode pensar que o código é mais complexo do que antes. Esse não é o caso, pois conseguimos remover muitos códigos “legados”. Graças as variáveis de ambiente. Graças ao PHP 7 e à remoção de caches bootstrap e de classe. Graças ao Symfony 3.3 que remove a necessidade de um autoloader específico.
Makefile
Muitos projetos possuem alguns scripts personalizados: um wrapper para executar testes de unidade ou integração, um script que executa o servidor embutido do PHP e muito mais. Scripts para os quais escrever um comando de console do Symfony não faria sentido.
Por conveniência, você pode ter definido eles em seu arquivo composer.json da aplicação. O Silex faz isso com uma entrada de script que executa o servidor embutido no PHP. Mas isso vem com muitos problemas, como timeout ou não ter suporte para códigos de escape ANSI.
Contudo, a centralização dos comandos ajuda com a descoberta. Que tal usar ao invés um makefile? Essa é talvez a característica mais controversa do Symfony 4. Mas estamos convencidos de que traz muito valor e ajuda a resolver alguns problemas.
make é uma conhecida ferramenta “padrão”. É mais poderosa do que os scripts executados pelo Composer. Não depende do PHP. Use-a para facilitar a implantação, para se conectar a servidores remotos via SSH, para executar teste scenarii do Blackfire. Use-a para executar npm, gulp, webpack, você que escolhe. As tarefas em que o uso dos comandos do Symfony não são práticos nem desejáveis.
Aproveite com a execução de receitas em paralelo. Não execute tarefas se nada mudou. Make é poderosa.
Vamos dar um exemplo, limpeza de cache. O Symfony tem um comando para limpeza e para warmup do cache. Executar ambos no mesmo processo não funciona bem, pois o PHP não pode recarregar uma classe se ela for alterada. Mas isso é fácil de conseguir com make:
cache-clear:
@test -f bin/console && bin/console cache:clear --no-warmup || rm -rf var/cache/*
.PHONY: cache-clearcache-warmup: cache-clear
@test -f bin/console && bin/console cache:warmup || echo "cannot warmup the cache (needs symfony/console)"
.PHONY: cache-warmup
Como outro exemplo, muitos dos meus projetos PHP possuem duas tarefas que ajudam a executar testes do Blackfire:
bf-dev:
blackfire-player --endpoint=http://`bin/console server:status --filter=address` run tests/bkf/all.bkf
.PHONY: bf-devbf-prod:
blackfire-player --endpoint=https://twig.sensiolabs.org run tests/bkf/all.bkf --variable="env=prod"
.PHONY: bf-prod
Deseja mudar uma aplicação para o modo “manutenção”? Use make, não um comando do Symfony.
Gestão de Ativos
O Assetic foi removido na Edição Standard do Symfony 3.0. Atualmente, não recomendamos substituições porque o mundo JavaScript ainda está trabalhando em uma ferramenta “padrão”. Mas o Symfony 4 fará uma recomendação e proporcionará alguma integração profunda. Mais sobre isso em algumas semanas. Ainda assim, queria mencionar isso, pois também apoiamos ativos que são links simbólicos/copiados de bundles para web/bundles/ via assets:install, mas provavelmente isso não irá sobreviver ao Symfony 5. Especialmente porque temos agora uma estrutura de aplicações sem bundles.
Apoiar as novas práticas recomendadas tem algum impacto na estrutura de diretório, que é o tópico do próximo post. Fique ligado!
Tradução do artigo original publicado por Fabien Potencier “Symfony 4: Best Practices”
