Symfony Live

Symfony Live is the conference around Symfony, the famous open-source PHP framework. It gives us the opportunity once a year to discover the progress of the latter as well as the new trends in web programming. On the program for this Parisian 2019 vintage, a certain number of conferences talking about Platorm API, Elasticsearch, the Messenger component, RabbitMQ, but also architecture (backend/frontend separated by a REST API) and Javascript. This year, I was there with Charly, so I offer you a look back at the conferences that interested me the most.

Opening Keynote & Symfony MIME Presentation

This conference of Fabien Potencier, creator of Symfony, took stock of a brand new official Symfony component, Symfony MIME. Its goal is to offer a simpler way to manage sending emails in its application. It offers different abstractions based on SwiftMailer.

On the program, a lighter email object and a more elegant way of composing it. But also a set of ready-to-use adapters to manage transport (eg: SMTP, Google mail, third-party APIs, etc.).

Powerful while remaining easy to use, Symfony MIME clearly offers a DX more modern than SwiftMailer. Good news because this will certainly make it possible to reduce legacy applications and start on a healthier basis on a new project.

Around API Platform

API Platform is a REST API framework built from Symfony. It allows you to quickly deploy different access points around Doctrine entities. The creator of this framework, Kévin Dunglas, was present. He introduced us to “ Symfony apps on steroids thanks to Vue.js, Mercure and Panther!“. Indeed, he explained how to quickly create a classic web application (using the MVC design pattern), in 5 minutes using MakerBundle. Then using API Platform and Vuejs, he demonstrated to us that it was possible to transform this application into a rich Javascript client that communicates with an API. Finally, he ended with the presentation of another of his creations, Mercury, a protocol for transmitting information about clients connected to the application, easy to use.

We then went into a little more detail with the conference “Lesson No. 139, API Platform is only good for making a POC, WRONG!” by Grégoire Hébert. Implementation of a message system, application cache, specification of read/write rights, more advanced use of Mercure… All of this was presented to us in a technical demonstration of the possibilities offered by API Platform.

To complete the two other conferences, François Zaninotto came to show us React-Admin. This is a React component library to create your administration space on a backend powered by a REST or GraphQL API. Additionally, all these components have been styled by applying the Material Design. This allows you to quickly have a clear and readable interface, while remaining modular.

State of the art of Elasticsearch with Symfony

The speaker and consultant Damien Alexandre explained to us all the best practices for implementation of Elasticsearch in a technical stack including Symfony. Although very powerful, Elasticsearch is often scary because of its difficult and time-consuming configuration, which is nevertheless necessary for its proper functioning and to meet specific needs.

To simplify the task, it is recommended to use directly Elastica, the official Elastic client in PHP. It allows you to translate the functional into an object, very practical in a Symfony app. For everything else, Damien recommends ''homemade''. For example, for the creation of indexes and queries, he recommends first building the JSON with Kibana (the graphical interface of Elasticsearch) and using hand-coded classes for the transformation of business data (see pass Frameworks therefore). This allows you to maintain full control of Elasticsearch indexes and avoid a certain number of errors. Concerning the indexing part, he recommends the use of asynchronous workers to avoid excessive load increases when updating indexes.

This conference was on the one hand a good reminder of the fact that Elasticsearch is a tool that requires time to set up, and on the other hand, is realistic about the dangers of overusing overlays in complex applications.

Symfony and PHP-FIG

If you follow PHP news at all, you have certainly seen the rant made by Fabien Potencier on standards PSR 7 and 14 (HttpMessage and EventManager respectively) and the departure of Symfony from PHP-FIG, responsible for the latter. He had the opportunity to briefly return to it.

According to him, these new standards no longer concern the interoperability of PHP frameworks/libs but the standardization of components. To implement them, a rewrite of the “core” components of the framework will therefore be necessary.

Additionally, if all developers followed all the guidelines to the letter PSR standards, the diversity of ways of doing things would be reduced. It is therefore for these reasons that Symfony decided to leave the PHP-FIG and to only take what they deem good from the different PSRs. They are obviously not the only ones because Doctrine and Laravel are now outside the project too.

Do It Yourself, standalone components and decoupling

These were in any case the key values ​​of this Symfony Live, which I found very successful. With varied and enriching conferences, innovative technological bricks and a good open-mindedness (see the frontend and JavaScript presentations), symfony once again proves its investment in the modern web. We leave this event happy to be part of this community and a few dolipranes later, “overexcited".

Link to the slides of all the conferences: https://github.com/SymfonyLive/paris-2019-talks