On the Symfony blog there's a quick post from Fabien Potencier (a sort of follow-up to this one) that talks about the end of Silex, a popular Symfony-based microframework, now that Symfony 4 and Flex exist.

What about Silex in a Symfony 4 world? During the last few months, and as an exercise when working on Flex, I have migrated several applications from Silex to Symfony 4. And the conclusion is that Symfony 4 feels like using Silex.

Using Symfony 4 and Flex feels as lightweight as using Silex. [...] Moving away from Silex is also made simpler as Symfony 4 almost auto-configure all your services. [...] For all these reasons, I would say that Silex is not needed anymore. So, we've decided to not support Symfony 4 in Silex, or at least not add the new features added in 3.4.

The comments on the post seem mostly supportive of the decision, realizing that what Symfony 4/Flex bring to the table all but replaces Silex anyway. A migration guide is in the works but hasn't been completed yet at the time of this posting (see this issue for the latest updates on that guide).

For those looking to make the move up to Symfony 4 and Flex the Knp University site has a new post that sheds some light on the composer.json configuration for Flex and how to use it to install a complete Symfony 4 application.

We need to make our composer.json file look like the one from symfony/skeleton. Actually, go to "Releases", find the latest release, and then click to browse the files. Now we can see the stable composer.json contents.

So... yea, this one file is all you need to start a new project. That's crazy! Flex builds the project structure around it.

The article then talks about the major changes including dropping the symfony/symfony package, how to synchronize the rest of the composer.json and autoloading updates. It ends with a brief mention of how to then scaffold out the full application structure - one command, a Composer update.

On the Symfony Finland site there's a new post sharing a tutorial showing how to add a GraphQL API to your application with the help of the overblog/graphql-bundle bundle.

I've been using GraphQL for some API thingamajigs, and it's been working fine. Now with Symfony 4 out, I figured a write-up on how to use GraphQL with Symfony Flex could be useful for someone.

We'll expand on a previous demo app that I built. That app already uses Doctrine ORM as storage, so let's bridge that to a GraphQL API.

He starts by linking to "a quick read" about GraphQL for those not familiar and listing out the basic structure of the application he'll build out. Next comes the installation of the bundle and a debug bundle to help make it easier to locate errors. He then updates the application configuration to add routes and define the schema for the objects in the system. Using the GUI that comes with the debug package, he shows how to access the API and how to create a "resolver" that will relay the information back to the client from the GraphQL API request.

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 stabilization 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.

The four features in the list are:

Simplified project structure

Easier installation of extensions

Dependency Injection improvements

Symfony Encore for asset management

Each section comes with a description of the update and links to other resources where you can find out more information about them. The post wraps up with an overall look at this new version (and Symfony Flex) and how they can improve a Symfony developer's life in the future.

Many Flex early adopters asked for it. The Symfony Flex server now supports private recipes repositories as announced during my keynote at SymfonyCon Cluj.

Creating a repository for your private recipes is easy. Create a regular Github repository (probably a private one) to store the recipes. The directory structure is the same as for the official Flex recipes repositories. Then, register the repository as a recipes repository. Done.

The private repositories will behave just like the other public ones in your application. You can also use them to override aliases. There are a few differences between public and private, however, like auto-merge not being supported.

The Symfony Finland site has a new post with a brief look at how the adoption rate of Symfony Flex has picked up with the impending release of Symfony 4 coming next month (November 2017).

With Symfony 4.0 a new standard structure for building applications is being adopted. This is known as Symfony Flex and will be the preferred way of creating applications. Symfony 4.0 is scheduled for release in November 2017, but many projects have already started adopting the new structure.

[...] In six years a lot of things have changed in the web development world, with the rise of front end driven applications, containerised microservices and more. [...] One thing that has not changed for some time is the Standard Edition itself. It has been critiqued for being enterprisey and heavy on configuration. [...] The trend was noticed by the team and in December 2016 at the SymfonyCon Berlin Symfony Flex was announced.

The post also lists out some of the projects that are already embracing Symfony Flex in their project structure including the GraphQL bundle and the PhpStorm Symfony plugin. Symfony Flex also gives developers a way to more immediately work with Symfony 4 when it is released through the same methods as now (with the 3.3 components).

On the SitePoint PHP Blog, there's a tutorial posted from editor Bruno Skvorc giving an introduction to Symfony Flex and how it is "paving the way" to a more performant future for Symfony.

Symfony Flex is a modern replacement for the Symfony Installer and not the name of the next Symfony version.

Internally, Symfony Flex is a Composer plugin that modifies the behavior of the require and update commands. When installing or updating dependencies in a Flex-enabled application, Symfony can perform tasks before and after the execution of Composer tasks.

The new Symfony will be called just Symfony 4, and while this tutorial will deal only with the Flex tool, it will mention some Symfony 4 upgrades as well.

The tutorial starts with some of the basics about Flex including its current development status and what kinds of things have changed from previous Symfony setups. It then walks you through the creation of a new Flex application including the bootstrapping of the application and the setup and use of application bundles.

On the Hackermoon site there's a new post from developer advocate Mickaël Andrieu sharing a few reasons why he thinks you should learn Symfony in 2017 if you haven't already.

In 2011, when I started my studies in computer sciences I learned the PHP using symfony 1.3, and I realized my very first student project on the beta of Symfony 2. At the time, we were moving from a fully integrated full stack framework with a back office provided to a framework that followed what was found in the Java community: besides, many components of Symfony2 were strongly inspired by JEE.

PHP 5.3 had just come out and with it the ability to start designing object-oriented correctly. [...] Large Open Source projects have started to migrate on Symfony components: if it was not first, SensioLabs has talked a lot about Drupal8 because it is one of the biggest CMS on the market. EzPublish, PHPBB, PrestaShop and many others followed, some with a full stack framework approach and others by incorporating only a few software bricks.

He then talks about the "vibrant and mature ecosystem", listing some of the packages that use Symfony components. He also looks forward to the next major iteration of the framework: Symfony Flex. He ends with his reasoning why you should learn Symfony if you haven't worked with it (or at least how it handles common things like requests and services).

Earlier this year I did some experimenting with a Hybrid state object between Symfony Twig templates and front end JavaScript frameworks. Since that time I did that experiment, the Symfony Flex project has progressed. I thought I would try how to port the state prototype to Symfony Flex.

[...] In my case the application was rather simple and all built in the AppBundle, which is best-practise in Symfony3 for many applications. I mostly had to move files and configurations around and change namespaces.

He starts by spending some time talking about the difference between a Symfony 3 environment and the environment Flex provides. He then goes through the eight or so steps to move from one to the other including file/directory changes and configuration updates. Next comes the look at performance differences between the two. Unsurprisingly Flex came out on top in every measurement he threw at it.

In addition to the new structure, the apparent improvement in performance is obviously welcome. This would likely be even more evident where I could leave more dependencies out, for example in API workloads. This obviously won't magically push Symfony/PHP into Golang or Node.js territory for raw API throughput, but for existing large code bases it could provide a low-effort boost.