PensioenProject

PensioenProject is a Web Application for the administration and calculation of pension insurance contracts.

For more information on what the application does, visit the PensioenProject product site. Here we will mainly discuss the considerations that went into its development.

The development of PensioenProject started in 2010. The technological landscape was different then, although many of the trends were already visible. Still, we had to contend with a lot of technical debt from the previous era; as an example: Internet Explorer 6 was still the dominant browser in the corporate world.

So why a Web Application?

• To be independent of the IT-infrastructure of the client.
• Technological evolution is more predictable on the server side.
• To be able to offer the Software as a Service (SaaS).
• To have a clear migration path into the Cloud.
• Straightforward scalability.

The next important decision was which programming language to use. The language wars were (and are) still ranging on an ever shifting battlefield, so any choice will come in for some criticism. Out of all the server-side languages, I decided on PHP.

PHP is an old language, and therefore comes with a lot of evolutionary baggage. (The same holds for JavaScript, in my humble opinion.) As a programming environment, however, it has also a lot going for it. It is the true “run-everywhere” language, server side that is. Every PaaS provider supports at least a LAMP-stack. A private server is easy to set up, configure and maintain, which is a significant advantage for a company with only one system administrator: me. The ecosystem is huge, and most libraries are open source, and not encumbered by legal restrictions. The quality of libraries can be a problem, but there are always alternatives to choose from.

In 2010, the bleeding-edge version of PHP was 5.3, which had only just cleaned up its object-oriented style of programming. With every version since, PHP evolved in a more serious language by adopting features of the other big players. The code base of PensioenProject has closely followed these developments, and has now arrived at PHP 8.3.

There was also a really low-level consideration. It may look like premature optimization, but I am glad I checked first. The strategy of PensioenProject is to calculate a lot and to re-calculate often. Since almost all calculations are financial, efficient BCD-math is a requirement. PHP drops down to a machine-level implementation without any interpreter overhead. Compared to the other server languages I benchmarked, PHP was faster (Python) or blindingly faster (Java, Ruby). Especially for Java, this was a real showstopper.

Then we get to the question of frameworks. From the start, I had some very specific ideas about the user interface. Full-stack MVC frameworks tend to be very opinionated about their View layer, usually some templating system with dependency injection. I needed more flexibility. Now it turns out that PHP started its life as the ultimate templating system. Its ability to freely mingle with HTML is a feature, not a bug. It means that the HTML pages can be mostly static with minimal dynamic insertions. Web-servers like Apache love this. Much better than “printing” the whole HTML response, especially considering the poor (UTF8) string handling of many languages. So, I needed a loosely coupled PHP framework. Ask Google, the answer (again in 2010) was Zend. The Zend framework, now reborn as Laminas, provides the database abstraction layer, session management, input validation, ACL, authentication and logging.

Mapping out the MVC structure, we start with a Model written in a fully object-oriented style of PHP. It manages the database access and contains all the business logic. The Controller and the View are slightly interwoven, as a consequence of the HTML request-response protocol. When we identify the View with the client-side browser window, then every server-side “page” is a Controller and a form. This form submits to itself. I realize that this structure is rather old school, but it plays well to the strengths of the Apache/PHP integration. Also, remember that in 2010 JavaScript support in the browser was still very anemic (corporate would even disable it). These days one would be tempted to offload most of the view logic to the client, and interface with a RESTful API on the server. My LabServer project follows this approach. It turns out that when your page is mostly one big table, even in modern browsers the DOM manipulation slows to crawl. So for PensioenProject this approach might still be too early.

For interfacing with third-party systems, I build a SOAP-API that has direct access to the Model. It is not a public API, so authentication and ACL presented a real challenge; again leveraging the Zend session management and SOAP-server a solution was found. The SOAP-API was tested in cooperation with several large CRM- and BPM-platform suppliers like Salesforce, Pega and FasterForward. Because a SOAP server can generate a WSDL specification of its API, many of the clients could be auto-generated.