Sometimes you have to deal with legacy codes, and sometimes the legacy can stretch a bit, more like... years behind.
I bet that every web developer encountered this problem at some point in time (or multiple times like I did). Normally, don't fix it if it ain't broken as some would say, but sometimes you don't have a choice - especially when you need to make the platform work for your native mobile apps that require API endpoints.
Recently in one of the projects my team was assigned with a legacy code base that dated back to 2006, and our goal is to make it work for native app eventually.
After a lengthy study of the code base, I finally decided to adapt to a distributed, micro service powered infrastructure instead of the monolithic monster we are dealing with now, see the evolution roadmap below:
Figure 1: The evolution roadmap
The above diagram shows the original code base and the two evolved forms of it. And I'm now at the very first step, which is to isolate the presentation layer and the logic layer.
So I was in need of a framework that is both robust and fast.
I looked at laravel, symphony and a slew of many other frameworks but they all come with a heavy load of extra bells & whistles which I really don't need — as you can see from the diagram in the middle, I've already built a very nice structure with dedicated Data Access Objects and Service Objects, so all I need really was routing and rendering the views.
Slim is one of the fastest PHP frameworks out there, but it's a bit bare-bone that it doesn't have out of the box support for comprehensive layout/templating, so I went and created a simple template engine which uses native PHP (with .phtml extension) — I'm always puzzled why someone would like to use a template engine that uses proprietary syntax and generates php files in a temporary folder - PHP is already a template engine in itself (do I need to remind you what the name 'PHP' stands for?), there's absolutely no reason for any developer to use yet another syntax which is limited in many ways, and makes debugging super hard.
So my goal is to find a suitable rendering engine that is 100% native php, and it should conform to the PSR-7 standard (slim 3 and symphony 3 both supports it, and there will be more libraries/frameworks that support it in the future). Unfortunatley, the only rendering engine that supports native php templates is really just a demo (https://github.com/slimphp/PHP-View), so I decided to create something that is simple yet extensible.
Later on, I decided to make it open source and here's the link: https://github.com/coreorm/slim3-view. In Part II of the story, I will elaborate on how it was integrated with slim 3 and also how the migration/evolution process took place with zero downtime of the existing web app.