PHP

While the previous article opens up many refactoring strategies, it is still important to work out the details. This time, I will cover sharing application settings (including PHP options which ZF1 apps tend to set in the runtime) and sharing error handling.

In the previous part, we got Zend Expressive working on top of legacy Zend Framework 1 application. This was only the first step towards deeper integration. In this post, I will show how to bring these apps closer by introducing shared Service Container. It will open up new strategies of refactoring.

Just as presented in the previous article, wrapping legacy application in a PSR-7 compatible middleware seems to be the best option for gradual modernisation process. In this post I will show how to do it, starting from Zend Framework 1 skeleton application.

Back in its days, Zend Framework 1 used to be one of the most popular PHP frameworks around. Even now, 8 years later, there are numerous working applications built on top of it. Because ZF1 has reached it's EOL and is not supported anymore, companies and development teams are considering upgrading it to something more modern. While the default choice is often to migrate ZF1 application to Zend Framework 2 (or 3), there's a good alternative - Zend Expressive. Expressive is much smaller, better suiting modern, API-centric applications. It promotes separating business logic from the legacy code, and I would argue that it is easier to master than ZF3.

This is what we did in my company, with good success. With relatively small effort, in 2-3 years we've been able to reduce our legacy code base to only 18% of total 300k lines of code (meaning that only 18% is now dependent on old ZF1).

Because from time to time I'm getting questions about the migration, I'd to blog about it. In this post, I will give a basic introduction, and later on, I'll show concrete code examples.

Writing factories for zend-servicemanager can be a tedious, repetitive task. Most of factories
I write follow the same pattern: pull some dependencies from the container, instantiate new
object and return it. How can you avoid the repetition?

PSR-7 brought some interesting patterns that can be applied to PHP application
regardless of what framework it uses. It is particularly interesting when it
comes to performance - no matter what technology your project uses, you can apply the
same techniques to make it faster.

Here I will show how PSR-7 middleware can be used to cache application's output.
I call it "extreme caching", because I want to trigger it as early as possible, in
order to reduce amount of code to be executed on each request.

I will present this pattern on Zend Expressive-based application. It will work for
any PSR-7 framework that uses middleware with following signature (which has become
de facto standard):

One reasons for PHP still being considered slow is a consequence of how it
works under web server environment: every time a client sends request, application
is initialized from scratch - it runs all the bootstrap code.
Bootstrapping is repeated over and over again, for every connecting client.

While this is an obvious waste of resources, it is also very difficult to avoid
without rewriting an application under different architecture. Is there anything
that could be done to at least reduce impact of application bootstrap, without
making any changes to actual application? As it turns out, there is.

PSR-7 is here and is big. Now, more than one month after it was voted, a lot of work has been put into projects supporting this standard. Even though we’re still at the beginning of this great journey, it is exciting to see what is already available, thanks to great work of PHP community.

Watching related projects since the inception of that standard, I will present packages that can serve as foundation for actual applications: HTTP message implementations, dispatchers and micro frameworks.

As you may know, folks from ZF2/Apigility projects keep bringing interesting utility modules, enriching ZF2 ecosystem.
Today I discovered small framework/helper for writing console applications: ZF-Console.
And, to my surprise, it was based on my own pull request
from last year! I was really proud to see that I brought something useful to the community.

There's an important question often rising when working on Zend Framework 2 module:
should I test service factories? After all, they are usually trivial, they create some object
and inject it with dependencies from ServiceManager. Having one test per factory seems to be an
overkill.

Better to go one step back, and ask yourself a question: what exactly do you want to test?