Symfony 4: Best Practices - Fabien Potencier

  • Автор темы Planet PHP
  • Дата начала

Planet PHP

Guest
Any major version of a project is an opportunity to revisit its best practices. Modernizing them. Adapting them to the project's new features. Symfony 4 is no exception.

Standardization first#


Symfony 4 will be an evolution of the current practices, trying to embrace more standard tools.

Symfony strives to embrace PHP and web standards. It is hard to believe that Symfony 2 started at a time when Composer did not exist. Since then, the PHP community started the Fig group, which adopted several recommendations. Symfony was one of the first major frameworks to adopt most of the PSRs, without breaking backward compatibility. PSR-3 for logging many years ago. PSR-4 for autoloading. More recently, PSR-6 for caching. The next version of Symfony, version 3.3, implements PSR-16 for caching and the brand new PSR-11 for containers interoperability. We might even have a use case for PSR-13.

Using standards help with interoperability but also with decoupling your code from the framework.

Bundle-less Applications#


The move to bundle-less applications was explained in the previous blog post. I mention it here again as this is an important change in the current set of best practices.

Environment Variables#


The current Symfony best practices book explains in great detail how to create configuration settings in a Symfony application. When to use app/config/parameters.yml for infrastructure-related configuration or app/config/config.yml for application-related configuration.

I would go as far as recommending to avoid using app/config/config.yml as much as possible. There are valid use cases, but I can count them on one hand.

Symfony 4 won't have the equivalent of app/config/parameters.yml. Use environment variables instead. This is what most frameworks do in other languages. This is also one of the recommendations of the 12-Factor Application Manifesto. One that is encouraged by many modern hosting platforms.

Using environment variables, while far from being perfect, have many benefits over what we currently do. Environment variables are a more "standard" way of managing settings that depend on the environment (no need to manage a parameters.yml.dist for instance). Environment variables can be read by several applications as they are independent of your code, framework, and language. Environment variables help with read-only filesystem deployment as they are decoupled from your code. Environment variable values can be changed "dynamically" without redeploying your application (clearing the cache for Symfony). Last, but not least, environment variables can be managed by existing tools.

Note that storing secrets in environment variables is not more "secure" than storing them in a configuration file.

As using environment variables can be cumbersome in development, using a "standard" .env file is easier and recommended. Symfony 3.3 comes with a new Dotenv component that will be used by default in Symfony 4 applications. Switching between a .env file and "real" environment variables will be done automatically and transparently.

Note that you can also define environment variables in a parameters.yaml file if that feels better to you. That won't be the recommended way though. Note that parameters.yaml is not a typo of parameters.yml! This is another change in Symfony 4 which will be discussed in a later article.

As a nice side effect, it helps simplify how the Symfony environment and debug flag are handled by both console and web applications.

Currently, the Symfony console tool can take the environment and the debug flag via the --env and --no-debug flags. Or alternatively via the SYMFONY_ENV and SYMFONY_DEBUG environment variables.

With Symfony 4, this is no longer needed. APP_ENV and APP_DEBUG can be used for both the web front controller and the console tool.

No more ./bin/console foo:bar --env=prod --no-debug or SYMFONY_ENV=prod SYMFONY_DEBUG=0 ./bin/console foo:bar. Just use ./bin/console foo:bar.

It just works. In development and on production servers.

Symfony 4 is full of such simplifications.

Unified Web Front Controller


Truncated by Planet PHP, read more at the original (another 3795 bytes)

Читать дальше...
 
Сверху