I wrote a couple of times previously about Symfony 4, particularly the architecture and use of Makefiles. It’s now at the point of being testable, so I took it for a short spin.

One comment for Linux users: your operating system will probably need an upgrade. I’m a Fedora user, and the stable release only includes PHP 7.0. Although that’s recent, it’s not good enough. Thankfully Fedora 26 has been in alpha a little while, and the beta is due at the end of this month. It was an easy upgrade, and includes PHP 7.1.4, a new enough version.

Getting started with Composer

The demo of an API client using Symfony Flex is a really nice example of how project setup works. A project is created with Composer, you bring in a few dependencies, and everything mostly wires together easily.

There are still oddities and rough edges. For example, a default .env file currently says:

The SQLite bit doesn’t seem to work for me, and I don’t see why it should – variables should be specified in this file, so having them be parameterised is very chicken-and-egg. But a fully-qualified file path works fine.

Aliases for requirements are great, and the decision to alias api to API Platform is a good one. This implies some standardisation and consolidation in the future. Existing API bundles like FOSRestBundle make less sense, to me, in a Symfony 4 world. Overall, though, I can’t see this being a bad thing. In the past, some bundles (like FOSUser) have been too big in scope and dominant in popularity – that should be avoided. So far, the separation and granularity is great, though.

Including Easy-admin is also a natural, good, choice. Combined with the API and ORM choices, it’s now very simple to put together basic CRUD-style applications. My impression with the controllers is that there is some more simplification coming, too.

What next?

It is a good time to start writing applications in Symfony 3.3. There is a lot more to think about in terms of best practice, and rethinking how to write applications with composition in the large is going to take a little time. Some of this is a little bit domain-driven in concept, and I’m slightly suspicious of enabling programmers to opt out of too much framework.

There are two tests that interest me. One, how simple is it to convert an existing application? Two, how much more quickly can an application be written? Realistically, enabling people to write apps more quickly is very useful – but converting existing is more valuable. Those two goals are also in tension – the more different the framework becomes, the more difficult the conversion. Getting answers to those questions will take more than a cursory kick of the tyres.