Middelhoek.com

PensioenPerfect

  • Home
    Home
  • Personen
    Personen
  • Mutaties
    Mutaties
  • Contracten
    Contracten
  • Tarieven
    Tarieven
  • Status
    Status
  • Deelnemers
    Deelnemers
  • Totalen
    Totalen
  • Facturering
    Facturering

PensioenPerfect is a Web Application for the calculation and administration of pension insurance contracts. It was build for the FinTech startup with the same name PensioenPerfect, of which I am one of the founders.

Why a Web App? To be independent of the IT-infrastructure of the client. 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 are still ranging on an ever shifting battlefield, so any choice will be terribly wrong. Please feel free to be personally offended when I disclose my language of choice: PHP. I will now defend my position, without actually defending PHP as a language, because purely as a language it is indefensible (the same holds for javascript in my opinion). As an environment however it has a lot going for it. It is the true “run-everywhere” language, server-side that is. Every PaaS provider supports at least a xAMP-stack. A private server is easy to set up, configure and maintain, which is significant advantage for a startup with only one system administrator: me. The ecosystem is huge and most libraries are open source, not encumbered by legal restrictions. The quality of libraries can be a problem, but there are always alternatives to choose from.

There is also a really low-level consideration. It may look like premature optimization, but I am glad I checked first. The strategy of PensioenPerfect 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 C-implementation without any OO-overhead or other niceties. Compared to the other languages I bench-marked, PHP was faster (Python) or blindingly faster (Java, Ruby). Especially for Java this was a real show stopper; as was string manipulation in general.

Then we get to the question of frameworks. From the start we 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. We 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 failure. 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 string handling of many languages. So, I needed a loosely coupled PHP framework. Ask Google, the answer is Zend. The Zend3 framework provides the database access, session management, validation, ACL, authentication and logging.

Mapping out the MVC-structure we start with a Model layer that is written in a fully Object Oriented style of PHP. It manages the database and contains all the business logic. The Controller(s) and the View(s) 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 sometimes the Old Ones had their reasons. In combination with a good IDE (PhpStorm) the prototyping can be very rapid indeed, the auto-completion and syntax-checking of the HTML/PHP pages is a great help.

For interfacing with third-party systems I build a SOAP API that has direct access to the Model-layer. It is not a public API, so authentication presented a real problem; again leveraging the Zend session management and SOAP-server a solution was found. The API is used by the Elements application from FasterForward. The same API may also represent the future of the PensioenPerfect application itself. This would allow splitting the web-server from the “model”-server. The model could then be re-targeted to any programming language capable of running on Linux. Here Swift comes to mind... Yes!

That is all I will divulge about the internals of PensioenPerfect at this time, and as they say, the rest is silence.