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.
Tag: Legacy code
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.