Late 2017, during SymfonyCon Cluj, Fabien Potencier presented Symfony 4: the latest version of the world’s most downloaded professional PHP framework.
Made available on the 30th of November, this updated version appears to be the easiest to use, the most flexible and the most powerful since the creation of the framework, and pledges to reinvent development experience for its users.
Nicolas Grekas, member of Symfony’s core team, gives us the details on Symfony 4’s latest innovations and benefits for developers, projects and businesses.
SensioLabs: Can you tell us about the main changes brought by the new version?
Nicolas Grekas: I would say that Symfony4 is a new way of developing, much simpler, for developers who very often had to do certain tasks repeatedly. It’s especially the case for configuration: each time you define what is known as a service, you must (in Symfony 3) amend a configuration file mirroring the changes made in the code. This leads to cumbersome writing, as well as significant maintenance (for instance any renaming in the code also requires you to go in the configuration to say “I’ve renamed these parts of the code”). In Symfony 4, new features make the configuration for common use completely automated.
Before Symfony 4, you had to be very explicit for the configuration to be correct; you needed to tell everything to Symfony’s configuration so that Symfony could work. Now, instead of explicitly providing every tiny detail, you can give details by batches: you express conventions and everything that enters the convention without overriding it is automatically configured.
Symfony 4, a more automated version
SensioLabs: Can you explain what a convention is in Symfony 4?
Nicolas Grekas: Let’s take an example, here is a common one: “for all the classes of my application that will need a logger, give them Symfony’s default logger”. This rule is generally enough in most cases. In Symfony 3, you needed to configure each class to specify which logger to give them (often the same one).
Also, as an example, you needed to configure N times the default language of an application for the N services that needed it. It is now possible to say: “For all services that need a default language, here is the value to give”, while coding the convention.
When talking about “conventions,” one should also talk of “exceptions”. In Symfony 4, there is also a way to express special cases to have the configuration explicitly adapt when necessary.
The aim of conventions is to cover general cases, while enabling to override if necessary. The result is a set of conventions focused on what is essential.
SensioLabs: What does Symfony Flex stand for?
Nicolas Grekas: Flex is a part of the Symfony 4 experience we were talking about earlier. There are two levels of automation in Symfony:
First of all, configuring your code through conventions, brought by Symfony 4.
Then, wiring dependencies of your code is also automated. Symfony bundles are features made available by the community (or internally), and are reusable on several different applications. These features also need configuration, especially when installing a new bundle. This configuration is what Flex offers. We have started making an inventory of all the configuration recipes for as many of the community’s bundle configurations as we can. This knowledge base enables anyone who wants to use (or test) one of these bundles to do so effortlessly: Flex will provide the required default configuration.
SensioLabs: Can you tell us more about this automation and the fact that the code is now “bundle-less”?
Nicolas Grekas: Bundle-less does not mean that the application doesn’t use bundles anymore. The difference is that, now, bundles are only intended for third-party coding. Before, in Symfony 2 and 3, the applications themselves were bundles.
But coding a bundle in your application required writing very specific codes to integrate it with Symfony itself. This code had very little added business value, but it was essential, which created a useless technical debt. In Symfony 4, this go-between bundle is no longer necessary. In fact, we recommend deleting it from the application. This makes the application’s code a pure business code that is less specific to Symfony in the application’s design.
Symfony 4, a new way to work in project mode
SensioLabs: At what moment in a project do these new features take on more importance? What are the major benefits of Symfony 4 for projects?
Nicolas Grekas: The new features brought by Symfony 4 come into play throughout the entire life of a project! There was a time (when the Symfony 4 adventure was only just starting) when automatic configuration was considered by some people to be a good, friendly approach for beginners, but something that people would gradually walk away from as their skill level increased. Because they didn’t see the purpose and thought it was just making things easier, like some kind of a crutch they did not need. Truth be told, nothing at that time could have made us think they were wrong.
However, with practice, we realized that expert developers too gained in productivity, though it required a paradigm shift, a new angle on configuration design. Internally, when we migrated blackfire.io toward Symfony 4, the senior developers that were on the subject were unsure of this “beginner’s crutch.” At the end of the migration, when they had understood how to apprehend this new development practice, they were totally convinced!
It is a real change in the developers’ productivity. Maintaining a project is also easier since the volume of files to configure has diminished. This means it is easier to enter a project and it is easier to make it evolve. This is the advantage of reasoning by convention and the automation that follows.
Developers save time. One of the main headlines of Symfony 4 is “Keep you at coding as long as possible” this means that back-and-forths between coding and configuration are very much reduced, which results in a considerable amount of time saved by developers.
SensioLabs: Regarding features, what will this new version change?
Nicolas Grekas: Symfony 4 is even more powerful than its previous versions; also more suited to the Cloud. Symfony is perfectly fit for use on containers platforms, like for instance SensioCloud, using best practices to achieve this.
For example, in secrets management – a recurring problem – most developers use environment variables to configure the applications they roll out. However, we recently discovered that this was not for the best: these variables leak too easily. It is better to store secrets in virtual files exposed by platforms like Docker.
Logically, Symfony is now capable of reading these files dynamically on execution, which wasn’t possible before. More generally, a Symfony application is compiled: you create its container and the associated caches once and for all. All the configuration that used to be in the files was read when the application was compiled, without the possibility to change it later on. Now you can compile the application leaving “holes”, which are filed out during runtime. This allows for better roll-out on Cloud applications.
Best practices to migrate towards Symfony 4
SensioLabs: Can you tell us the best practices to successfully migrate towards Symfony 4?
Nicolas Grekas: A migration between Symfony 3 and 4 is at the same time different and similar to a migration between Symfony 2 and 3. There are two main steps to complete it.
1. Like for a migration from Symfony 2 to 3, the transition from Symfony 3 to 4 hinges on the same bases: the impaired features have been removed, therefore you need to make sure they are no longer used before migrating. The same application running under Symfony 3, ridden of the deprecated features will run on Symfony 4 code even if the configuration is not updated and stays “old fashioned.” This migration step is required. However this means you are only halfway through the Symfony 4 experience and are not yet using the new configuration system to its fullest.
2. The second step now consists of adopting the new configuration by writing the essential conventions recommended by the framework. It’s also at this stage that we would generally recommend adjusting the directory structure to align it with the new skeleton of Symfony 4 and thus benefit easily from all the associated tools.
These two steps can be done in the order you want. It is absolutely possible to start by migrating toward Symfony 3.4, since this version contains all the features needed to implement the new configuration.
Building skills and developing Symfony 4 expertise
SensioLabs: In terms of Symfony 4 trainings, what are the most important aspects to deal with?
Nicolas Grekas: It will now be easier to start on Symfony. With the new development experience, it is easier to get positive results without needing to understand how the configuration systems operate first. Thus the framework is more open, the learning curve should be smoother at the beginning, enabling people who have less experience to create prototypes more easily.
However, don’t forget that the simplification is brought on by the features. Pre-existing features are still there, which means that, to become an expert, you will have to master the previous versions as well. A beginner developer will start by becoming a Symfony 4 expert, then Symfony 3 and 2, since the core is essentially very similar.
SensioLabs: Is strong knowledge of the previous versions necessary to obtain Symfony 4 certification?
Nicolas Grekas: Absolutely. Symfony 4 certification will require knowing the (non deprecated) features of the previous versions.
SensioLabs: To sum-up, what are Symfony 4’s benefits for businesses?
Nicolas Grekas: To begin, it is easier to start on Symfony 4, creating of prototypes and getting results is easier.
For experts, the flexibility brought by Symfony 4 will enable them to lose less time on configurations and focus more on the coding aspect.
Do you wish to build your skills on the framework? Contact us on jonathan.sam-mouy[at]training.sensiolabs.com. or discover our various training plans at