14 July 2018 — Comments
I have written a lot of posts about Zend Framework in general and Zend Expressive in particular, but I have noticed that I have never talked about one of the things that, from my point of view, makes Expressive so game-changing, Interoperability.
In the past, PHP frameworks used to be very big libraries, which tried to provide solutions to any possible problem in order to retain users.
At that time, you had to decide which framework you wanted to use, by weighing pros and cons. People ended up saying "I prefer framework foo, because it has a better templating system", "ok, but framework bar has a better performance and its dependency injection approach is delightful".
It wasn't easy to pick the best part of each framework (or the parts you liked the most) and be able to use them in the same project. You couldn't just take the templating system from foo and make it work with the dependency injection approach from bar.
Because of this, the PHP Framework Interop Group was born (PHP-FIG from now on). Its goal was to define standard recommendations that frameworks and libraries could adhere to.
At some point this would mean that frameworks would use compatible APIs in their different components and people would be able to easily change one specific component by another.
Mostly all frameworks which are part of the PHP-FIG have more or less adopted these standard recommendations. If you have been working with PHP in the last 3-4 years, you know it is now much easier to "mix" libraries and frameworks in the same project.
However, the one which has been capable of making interoperability part of its essence is Zend Expressive (probably because it was born in that period and interoperability was one of its main design goals).
Expressive itself does not provide solutions to almost anything. Instead, it relies in a series of interfaces and abstractions in order to get everything working.
Some of those abstractions are PHP Standard Recommendations (PSRs) from the PHP-FIG.
The PHP-FIG still has some work to do in different areas. For those cases in which there's no standard recommendation, Zend's team has defined a few own interfaces and abstractions Expressive relies on in order to ease decoupling and extendability.
All of these abstractions are defined in separated packages, so in the future, if the PHP-FIG accepts a PSR for any of these things, Zend Expressive will probably start supporting them and drop these packages' interfaces as far as possible.
There are a lot of things a real project needs which have been left out of expressive's scope, which is in fact good.
You will probably need some way to handle configuration. Expressive doesn't tell you what to use, because usually config is consumed before the request is even dispatched, so there's no need for any kind of integration.
You will also need something to connect to a database, or consume external services. Once again, use whatever you want.
If you need to be able to run your app from the command line, expressive and the HTTP layer won't even come in place. For that purpose, Zend's team recommends using symfony/console these days. In fact, there are a few CLI utilities for expressive which have been built with that component, like zend-expressive-tooling.
Of course, all of this flexibility is great for experienced developers, but newcomers need a little bit of help to begin with. That's why a skeleton project was created.
The skeleton is installed using an interactive process which let's you choose the different components to be used, and the project approach you want to take.
This wide range focus makes expressive fit any project. Also, despite the fact that it can be considered a microframework, I can tell you it scales quite well.
Ok, perfect, interoperability runs in expressive veins, but I don't want you to just take my word. That's why I have built an example project where I use a variety of libraries and components for every task.
In order to build the project, I have used the skeleton mentioned before, and then tweaked it a little bit. You can find it here: https://github.com/acelaya-blog/expressive-interoperability-proof-of-concept
These are the components I have used:
The result is that very few of the code is actually from
The project includes the instructions to run it and see how everything is in fact working. It also includes one option in the menu to see an error page.
From my point of view, full-stack and coupled frameworks are something from the past. I like to be free to choose the tools I want to use in a project for every task, and to be able to use the best ones or the ones I like the most.
For me, it makes no sense these days to ask "What PHP framework do you use?", because thanks to the PHP-FIG and initiatives like Expressive it's more and more hard to answer.
Of course, if the full-stack approach is the one that fits you and makes you be more productive, I'm nobody to say otherwise :-)