Forest header image

Symfony Finland
Random things on PHP, Symfony and web development

Four things I like about Symfony 4

Symfony 4 launches on November 30th 2017, some two years after the previous major release that was Symfony 3. Symfony 3 can be thought of as a stabilisation release with code cleanup, some new functionality and housekeeping Standard Edition (AKA Full Stack Framework).

In the latest incarnation there are more significant changes, especially to the framework and some key components. Let's take a look at four features that address frustrations that I've had in the past.

tl;dr: 1) Less directories 2) Less copy-paste from GitHub 3) Less YAML config for DI 4) JavaScript asset builds

1. Simplified project structure

The Symfony Standard Edition is a feature rich framework that is used for many capable Business Application Platforms like Akeneo PIM, eZ Platform CMS, ORO CRM, Sylius eCommerce and a host of others - proprietary and Open Source.

The trouble is that, with the framework comes some rigidity and boilerplate. This is why many (me included) rather looked at using micro frameworks for simple tasks early on. I was pretty happy with using Silex, or something completely different, when I knew wouldn't need much server side logic.

Fast forward to 2017 and most CRUD apps I see around are a dumb thin layer on the server that integrates "to the cloud" and a fat client written in JavaScript and running in the browser. Apps with complex business logic and large teams working will still benefit from a feature complete back end framework, but in sheer volume of projects a light weight server app written in QuickBasic or Turbo Pascal would work fine for the complexity at hand.

With Symfony Flex replacing the Standard Edition from Symfony 4 onwards, there seems to be a decent middle path. The new directory structure is easier to approach, while you still get the convenience of YAML based configurations and the power of full DI Container. There's less confusion on where to place your templates, no need to explain why you need the AppBundle.

To see the structure for yourself, you can bootstrap a new project with Composer:

composer create-project symfony/skeleton my-project

2. Easier installation of extensions

Since 2011 the defacto method for extending Symfony Framework apps has been the Bundle System. Over the years it has proven to be a very powerful method that has enabled to extend and modify how the underlying framework functions.

The technical solution of Bundles may have proven to be a good one, but for developer experience they leave room to improve on in Symfony Standard Edition. Each time you want to install a new bundle, you'll need to go through manuals steps of installing the dependency, registering the bundle and configuring.

While the routine of enabling bundles may not be much of a chore when you're used to working with the framework, it certainly can be intimidating for the beginner. Installing bundles, registering kernels, defining parameters and configurations is a mouthful for someone coming from, say WordPress or another CMS with a rich plugin/module/extension ecosystem.

With Symfony Flex, you now gain easier access to installing and managing framework extensions with a a mechanism known as Recipes. A recipe is only a JSON file that defines what steps should be taken when a new bundle is installed. This means the often repeated steps are done automatically and a standard config is put in place.

Flex Recipes come in a set of recommended official supported recipes from the Symfony project and another one for contributed recipes, which users can opt-in to. For managing recipes the standard Composer packet manager is used Composer packet manager is used, for example:

composer req willdurand/js-translation-bundle

3. Dependency Injection improvements

The Symfony Dependency Injection Component is a popular part of many applications, with and without the Symfony Framework. Over 2100 projects report is as a dependency, including projects like phpBB and Drupal. In Symfony 4 this component has received a lot of improvements.

The DI mechanism allows organising code within your application to reusable services that can be (re)used where appropriate, and even swapped out for others as needed. This flexibility has come at a price, as some boilerplate configuration that has been needed to be written and maintained.

Again this configuration is may not feel like a big overhead if you're used to working with the framework day-to-day, but there it does seem superfluous if you're used to the terse syntax of a micro framework like Sinatra or Express. Anyone whose worked with Symfony SE has had their fair share of YAML fatigue.

In Symfony 4 the Dependency Injection Component now registers every class as a service automatically. This means that instead of needing to register services, they're automatically picked up with the class as the identifier (e.g. App\Greeting\HelloService vs. manually configured app.greeting.hello_service). You can also inject them directly in the method signature via PHP type hinting.

There's a lot more work done here, to learn more I recommend to see the slides from Nicolas Grekas regarding the DI component in Symfony 4:

4. Symfony Encore for asset management

When Symfony2 launched back in 2011 it came with an integration to the Assetic library. Assetic was (and is) a PHP based tool to manage static assets like JavaScript and CSS. Since that time JavaScript based tools on the front have taken center stage for front end minification, etc.

In 2015 Symfony added the Asset Component which allowed referencing static files with versioning, setting up a CDN and more. This all enabled a sane front end asset management workflow with symlinks from bundle's directories to the web root. This all worked, but there was still some confusion and no recommendation from the framework on how to process and organise assets.

Encore pre-dates Symfony 4 and is technically not a Symfony 4 component at all. Is a configuration layer on top of Webpack application written in JavaScript and running on Node.js. Webpack is a swiss army knife for managing front end assets, it is highly configurable and is nowadays the de-facto tool for processing and bundling modular JavaScript code.

Symfony Webpack Encore enables an opinionated way to set up a contemporary JavaScript-based front end asset pipeline that is decoupled from Symfony PHP framework, simply integrating to via the asset component (and manifest.json for cache-busting). Oh, so you've already got a good workflow…? no need for Encore :)

Encore has a Flex recipe, so it can be installed using composer with the following command:

composer req encore

Conclusion

With the launch of Symfony 4.0 and Flex the project addresses a number of areas that have been painpoints to many developers. Cutting overhead and reducing boilerplate are a welcome improvements for small one-off apps churned out in a few days.

With Flex the framework now has a mechanism that is capable of configuring framework extensions, making it more competitive with higher level products like Content Management Systems that have their own module/extension repositories. The API-Platform is an excellent example of what can be built on top of the Flex ecosystem.

In addition to the features and improvements mentioned in this article there have been a number of new components and capabilities introduced already in the 3.x range releases leading up to 4.0. Symfony 3.4 is released at the same time as 4.0 and is at feature parity with it. Even if you're not starting a new 4.0 Flex project, you can start using the improvements with reasonable effort.

For example, It is completely feasible to take a 2013 Symfony2 SE project and port it over to 3.4 with reasonable effort. Armed with the DI ergonomy improvements and more, you can then gradually move this from Standard Edition to Flex if you see this as an advantage. Flex starts light, but scales to projects of high complexity.

So maybe the ultimate killer feature of Symfony 4 in the end is capacity to keep improving your existing codebase, but improving and modernising it gradually.

Learn more about Symfony 4 and Flex:

Written by Jani Tarvainen on Monday November 27, 2017
Permalink -

« State of GraphQL PHP libraries and Symfony integrations in 2017 - Adding a GraphQL API to your Symfony Flex application »