Symfony 4: Monolito vs Micro

Esta é a segunda parte de uma série de artigos sobre o Symfony 4. O primeiro foi sobre as limitações atuais do modelo de Distribuição do Symfony.

Projetos monolíticos versus micro-aplicações: um debate sem fim. O Symfony é compatível com ambos. Mesmo a Edição Standard do Symfony sendo provavelmente mais adequada para projetos monolíticos, pois depende do pacote symfony/symfony. Esse meta-pacote contém todos os componentes do Symfony e alguns bundles do “núcleo”. Entre outros recursos, você obtém o Twig e o Web Profiler. Mas, tecnicamente, eles não são necessários se você estiver desenvolvendo uma API para a sua próxima aplicação móvel.

Claro, alguns arquivos extras sob o diretório vendor/ não mudam nada, mas alguns desenvolvedores pensam que suas aplicações são mais “inchadas” por causa desses bits extras no disco. Parece que esses recursos extras não utilizados tornam a sua aplicação pesada. Isso é sobretudo percepção.

O Silex utiliza outra abordagem onde cada componente individual é exigido apenas quando necessário. Isso torna o Silex mais simples, leve ou mais rápido do que o Symfony? Não. No entanto, o Symfony 4 será mais semelhante ao Silex nesse aspecto.

As aplicações Symfony são mínimas

Sem mais dependência no symfony/symfony. Uma aplicação Symfony agora dependerá dos componentes e pacotes individuais do Symfony. Essa é provavelmente a mudança mais significativa na forma como você irá desenvolver aplicações com o Symfony 4. O principal motivo não é porque ele ajuda a reduzir o número de arquivos sob vendor/. Mas porque abre muitas outras ótimas oportunidades.

Isso ajuda com a configuração automática, um dos principais recursos do Symfony 4. Ao instalar um bundle, o Symfony agora irá configurá-lo automaticamente com bons padrões. A configuração também se adapta de acordo com suas outras dependências.

Pegue o Bundle do Framework Symfony como exemplo. Alguns recursos podem ser ativados ou desativados, como formulário, validação, templates, serializador, assets, …

A partir do Symfony 3.2, o suporte aos formulários está habilitado por padrão, mas você pode desativá-lo se não o estiver usando na sua aplicação. Por que é habilitado por padrão? Porque não há nenhuma maneira do Symfony saber se você usará formulários em sua aplicação. Desativá-lo por padrão levaria a uma experiência de desenvolvimento ligeiramente pior, pois essa é uma configuração para ajustar antes de seu primeiro formulário funcionar.

Agora, imagine uma aplicação onde symfony/symfony não é uma dependência. Uma aplicação pode começar apenas com symfony/framework-bundle. Habilitar automaticamente o suporte aos formulários agora é trivial: ative-o quando o symfony/form for instalado, desative-o caso contrário. Simples, sem magia, sem configuração, excelente experiência para o desenvolvedor. Você vai adorar o Symfony 4.

Como um ótimo efeito colateral, o desempenho é melhor, pois os recursos opcionais são desativados automaticamente. Sem ajustes em arquivos de configuração. Serão compartilhados alguns benchmarks simples em outro post.

Ser mínimo também significa que o Symfony não tenta fazer mais suposições quanto ao seu stack. Além da remoção dos arquivos LICENSE ou README no esqueleto, não há mais arquivos .htaccess do Apache. E se você estiver usando o Apache então? Bem, será necessário esperar por outro post para obter a resposta, mas você terá cobertura.

Composição

A remoção da dependência symfony/symfony ajuda com outro recurso do Symfony 4: descoberta automática e remoções de dependências. A composição foi mencionada no post anterior. O Symfony 4 usará essas dependências menores para ajudá-lo a compor as suas aplicações.

Deseja usar formulários? Adicione symfony/form. Quer usar o servidor web embutido no PHP? Adicione symfony/web-server-bundle. Aprimoramento progressivo. Adicione dependências somente quando necessário.

Juntamente com a configuração automática, é muito poderoso. Não precisa mais do servidor web embutido? Remova o pacote symfony/web-server-bundle. O Symfony cuida de remover a configuração do bundle.

Esse é um exemplo muito simples, mas há mais. Vamos ilustrar o poder desse novo paradigma com o SensioDistributionBundle, um bundle exigido por padrão na Edição Standard do Symfony.

Você não acha que as verificações de requisitos atualmente são implementadas estranhamente? Os arquivos são copiados do bundle para a Edição Standard no lançamento. Você é responsável por removê-los antes da implantação (especialmente web/config.php).

Toda a lógica foi movida para symfony/requirements-checker. Deseja verificar os requisitos? Adicione o pacote com o Composer. Execute os scripts. Corrija quaisquer problemas. Desinstale o pacote quando terminar. Os arquivos são adicionados e removidos automaticamente.

Outra característica principal do SensioDistributionBundle é poder executar alguns comandos quando você executa composer install ou composer update: eles gerenciam o arquivo bootstrap (que não é mais necessário com o PHP 7), limpam o cache e instalam os assets. Parece uma lógica de código fixo (veja a chamada Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::* no arquivo composer.json do seu projeto). O conceito foi reformulado para o Symfony 4 de uma maneira extensível. Você pode ajustar e adicionar seus próprios comandos e lógica.

Não haverá uma versão SensioDistributionBundle compatível com o Symfony 4. Não precisamos de uma. Você pode pensar no Symfony Flex como o sucessor dele. Uma versão mais simples e poderosa dele.

Aplicações sem Bundles

Quando foi escrita a primeira versão das melhores práticas do Symfony, houve um longo debate sobre a promoção de “aplicações de um único bundle” versus “aplicações sem bundles”. Foi decidido seguir com um único bundle AppBundle para evitar uma interrupção muito grande, mas também porque o Symfony não estava pronto para suportar aplicações sem bundles como cidadãos de primeira classe. Mas durante os últimos meses foi trabalhado muito para garantir que o Symfony 4 possa permitir aplicações sem bundle.

Portanto, o Symfony 4 irá recomendar e gerar aplicações sem bundle. Não há mais bundles em seu código, basta usar App\ como um namespace para qualquer classe em src/. Isso reduz a complexidade percebida. E também faz seu código parecer mais desacoplado do Symfony. Não acho que as aplicações devem desacoplar 100% o seu código do framework subjacente, mas, a partir do Symfony 3.3, muitos recursos o ajudam a fazer isso.

Aplicações sem bundle são apenas uma das mudanças de melhores práticas para o Symfony 4. As melhores práticas são o tópico da próxima publicação.

Tradução do artigo original publicado por Fabien Potencier “Symfony 4: Monolith vs Micro”