SymfonyCon 2019 in a nutshell: Symfony 5.0, components and performance

Symfony is an open source software project used by hundreds of thousands of developers. Every year the community gathers at the SymfonyCon event, which is an opportunity to share knowledge and socialize with Symfony users from around the globe.

In 2019 the annual conference was held in Amsterdam, and the event attracted a record-breaking 1600+ attendees from more than 50 countries. The Symfony project releases a major version every two years at the end of the year. It's been two years since Symfony 4.0 was launched, so many sessions at the event evolved around the next iteration: Symfony 5.0

eZ Platform is built on the Symfony Framework, so a lot of the topics discussed at the SymfonyCon are relevant to our ecosystem. In this blog post I will share details from relevant sessions for eZ Platform developers from the event held in late November.

Symfony 5.0 and 4.4 released

Details on the latest major release were shared in multiple different sessions. The first of which was the event keynote held by project lead Fabien Potencier. The keynote began with an overview of everything that goes into maintaining an open source project like Symfony. Quite a bit of work is done behind the scenes that is not obvious to the random observer.

In addition to hands-on code changes, reviews and other public work, the core project team maintains a lot of automation tools and processes. These are vital for ensuring the consistent quality Symfony is known for. Developing and maintaining the number of supported releases would simply be unfeasible without the infrastructure in place. A hands-on demonstration Symfony 5.0.0 was released live during the presentation. Wow.

Finally, the there was discussion about the new Symfony 5.0 book. Titled Symfony 5.0: The Fast Track, the book describes how to create a real-world application using the latest version of the Symfony Framework. While the book itself is an interesting endeavor, it is more interesting how it affected product development. The book was written while 5.0 was in development, and it ended up affecting the software and the ecosystem around it.

To build the example application changes were made to simplify development and related project received compatibility updates. This means that not only did the framework itself change as a result, but the whole ecosystem was pushed forward as projects like Doctrine were compatible with Symfony 5.0 from day one. In addition, the book also fed back into QA, as the app built in the book is now an official part of the test suite going forward.

Components: Messenger, Mailer and HttpClient

A new major version like 5.0 is always exciting, but the parallel 4.4 release is nothing to scoff at. As you may know the last minor release and first major release of Symfony have feature parity. This means that 4.4 and 5.0 share the same supported features, and that version 4.4 is by nature a (relatively) simple update for any application built using the 4.x series.

As per semantic versioning, a major version like Symfony 5.0 could contain more radical changes. In the case of Symfony moving from 4.4 to 5.0, it is an evolution rather than a revolution. This is something our engineering team is well aware of, and we're looking into the possibility of upgrading eZ Platform to Symfony 5.0 to keep us at the forefront.

So, if Symfony 5.0 is the same as 4.4, what is the point of 5.0? It is an opportunity to remove old (deprecated) code and features that are no longer available. This means that 5.0 is more lightweight and slightly more performant than 4.4, but it also comes with a number of new features marked as experimental. They come in the form of components.

Since version 2.0, Symfony has been a collection of stand-alone components and a separate framework that ties them into a whole form. These components can be used independently from the framework. The Symfony project contains some experimental features that are unstable or controversial. Some of these do graduate to become stable features.

In this lifecycle, the Messenger component is no longer considered to be experimental. The component was added in Symfony 4.1 in March 2018, since then it has matured quite a bit. Using Messenger, developers can handle asynchronous, time-consuming tasks by pushing them into a working queue that can be processed as a background task. Ryan Weaver held an in-depth presentation on using Symfony Messenger at SymfonyCon 2019.

Messenger is a great way of integrating Symfony apps to popular queueing backends such as cloud-based Amazon Simple Queue Service (SQS) or Open Source software like RabbitMQ. It is also useful for eZ Platform developers looking to offload heavy tasks to be processed later. It is worth noting that our eZ Platform Cloud hosting solution supports RabbitMQ out of the box - making adopting an enterprise grade message queue simple.

In addition the Mailer and HttpClient components have been made stable in 4.4 and 5.0. They can be thought of as somewhat back-to-basics features, as they manage rather mundane use cases: Sending emails and making HTTP requests. However, both are necessary as the Symfony and PHP ecosystems could use improvements on these fronts.

The Symfony framework has been using the Swift Mailer, a project closely related to Symfony. It was getting long in the tooth and had not evolved much. The Mailer component is a fresh take on the old subject, and is built to be feature rich and supports backends such as Amazon SES, Mailgun and SendGrid via dedicated transport components.

In the case of the HttpClient, there was a similar void to be filled. Making HTTP requests is a very common need, but there was little activity in developing a contemporary client library within the broader PHP ecosystem after development on Guzzle dwindled down. The HttpClient component has an easy-to-use API and a feature rich implementation.

For Symfony 5.0 there are two new components made available as experimental features:

• String, for object-oriented strings management with an abstract unit system
• Notifier, for sending notifications via one or more channels (email, SMS, ...)

Performance improvements

Performance in computing is not all about brute force. You can add resources to make an application perform better, but the more exciting aspect is doing more with less. In the world of software this not unheard of, as developers often learn to make their software more efficient over time. This is positive for the bottom line through reduced cost and the environment due to reduced energy use. A textbook example of a win-win situation.

Improving performance is a topic that you can approach from multiple angles. There are many aspects that you can find room for improvement. Regarding the sessions at SymfonyCon 2019 I decided to split these into three high level topics:

• Run less code or run it faster
• Cache data more efficiently
• Improve transportation infrastructure

Run less code or run it faster

In his session titled Building Really Fast Apps, Tobias Nyholm discussed how running less code is the best way to make an application perform better in relative terms. More hardware resources or better caching can improve throughput, but not improve efficiency. While some of the stripped-down examples Tobias offered might not be practical for larger projects, the mindset of adding components only when needed is a healthy mindset.

The above bodes well with the philosophy of the Symfony Framework since version 4.0. Instead of including all the components, it requires you to explicitly require every component. This leads to less code that the CPU needs to step through for the same result. 5.0 continues on the same path, while removing deprecated 4.x code behind.

Most code written runs on a high level, meaning there is a thick slice of software it builds on. This means that we can gain advantages not by changing our code, but the platform that it runs on. For this topic there was an interesting session titled A View Inside PHP by Julien Pauli that gave insight into how the PHP runtime internals function.

In addition there were random mentions of a the Preloading feature available in PHP 7.4. The feature allows applications to define a list of classes that should be preloaded for all PHP requests. Support for Symfony is being worked on. According to Nicolas Grekas, PHP 7.4 preloading can offer up to 20% performance improvement for existing applications.

Cache data more efficiently

Caching is a process of storing data that can be reused. There are many layers of caches in systems from the very low-level processor caches to high level caches in the browsers. All of these can have a dramatic effect on the overall performance of an application.

HTTP caching is a method that is used by web applications to store generated responses for serving them to more users. The Symfony framework comes with good support for HTTP caching out of the box and developers are encouraged to use it. To get started, I recommend looking into the HTTP Caching with Symfony 101 demo app by Matthias Pigulla.

Symfony offers a generic Cache component that allows developers to store arbitrary values for a specified period of time. It can be configured to use a number of backends from a local filesystem to distributed high-availability server setup such as Memcached or Redis. eZ Platform uses the cache component extensively to reduce repetitive database calls.

Earlier this year our team found some areas of improvement in the cache component while developing eZ Platform. This lead to cross team cooperation which resulted in improvements to Redis caching in Symfony 4.4. During SymfonyCon 2019, André Rømcke provided details in his talk Head First into Symfony Cache, Redis and Redis Cluster.

Improve transportation infrastructure

The World Wide Web (WWW) was built around the Hypertext Transfer Protocol (HTTP). From its humble beginnings, the HTTP protocol as well as its applications have expanded well beyond what they were originally intended for. Nowadays HTTP is used transferring gigabytes of files as well as kilobytes of API calls.

Is there room to improve…?

For sure!

The HTTP protocol has been in its second major iteration since 2015. This was a great improvement allowing for better security and performance over its predecessor HTTP/1.1. Kévin Dunglas held a session how HTTP/2 and showed how it could be used to fix some shortcomings of REST APIs. In fact, the HTTP/2 Server Push powered Vulcain protocol can even providing some advantages over the popular GraphQL protocol.

But HTTP/2 is not the end of the line. Just this year work on formalizing the HTTP/3 specification has begun. It builds on the success of HTTP 1 and 2, but it goes onwards to replace the underlying TCP protocol completely. It aims to combine HTTP with a lower level data transfer protocol with integrated encryption. A major undertaking discussed in detail by Benoit Jacquemont in his session HTTP/3 - it's all about the transport.

Conclusion

The SymfonyCon was again a few days packed with information and familiar faces friends and getting to know a few new ones. All the sessions from Ansterdam will be made available live to SymfonyCasts, so if you visited the event but missed some sessions - you can view the videos online in the coming weeks. Links to materials: SymfonyCon 2019 talks

Next year the SymfonyCon will be held in Disneyland Paris in early December. At the time of writing it is over a year away, but they say well planned is half done :) In the meanwhile our engineering team is busy working on the next release. We'll be sure to have an even better version of eZ Platform available for our ecosystem next year.

To learn more about our engineering team's effort on upgrading to the latest versions of Symfony, read the post on Upgrading eZ Platform from Symfony 3 to 4 and beyond.