A recent blog post had me trying to find a good base structure for my Online Dispute Resolution platform. I looked at a few possibilities, none of which were really appropriate. I decided to try taking a more modular approach, using libraries to handle things such as authentication but building my system in an abstract way to enable swapping out modules if necessary.

Large frameworks such as Zend and CakePHP are very constraining, requiring you to stick to their idea of what is the best development approach (specific directory structures, MVC design pattern, and so on) or else perform some very heavy, non-standard configuration to make it suit your project. I’m sure either of these heavyweight frameworks would be perfectly well suited to ODR, but generally speaking I try to stay away from non-transferable frameworks. I like to understand exactly how my application works, rather than delegate that understanding to a third-party library. And I like having the freedom to change frameworks painlessly at a later date – something which is NOT suited to heavyweight frameworks!

I considered a few of the lighter options: Huge, Opauth, Laravel and Fat-Free Framework. Huge looked promising to begin with but then appeared to be more of a middleweight framework, strongly encouraging but not requiring you to follow certain directory structures. It would be a base that I would have to build on, rather than a library that I can plug into my system, only calling it as and when I need it.

Opauth looked nice and lightweight, but was aimed at projects which want to use OAuth for authentication, allowing people to sign in using their Twitter, Google, LinkedIn or Facebook account. This was not suitable, given my project requirements. Laravel was the next one I looked at, and looks a little like PHP’s answer to Rails as it generates an entire application structure through a proprietary command.

I’m sure that any one of these libraries is a suitable starting point, and I know that there are thousands more in existence. It would be impossible to spend a long enough amount of time evaluating every framework that one could make a truly considered decision.

Fat-Free Framework

The most promising framework at first glance was Fat-Free Framework, or F3 as it is commonly known. I found it had a low learning curve and an unconstraining nature. Its modular build means that I can cherrypick the elements of functionality I want, rather than go for an all-or-nothing installation. Interaction with the library is through calls to namespaced classes. F3 is fundamentally different to its competitors because I can slot F3 into my code, rather than slotting my code into F3.

This work was supposed to just be some spike work, but I must confess I’ve now invested around 5 days in seeing how well I can utilise F3 for my project. At this stage in the project, I’ve managed to set up user registration (with back-end support for multiple user types) and login/logout functionalities, developed in a relatively test-driven way (though I plan on writing more unit tests to make my current codebase more robust, as well as Cucumber acceptance tests).

It wouldn’t be too late to turn back now and opt for a different framework. I daresay I’ve built many transferable components, such as the SQL database structure. But I’m very happy with how it’s going with F3 and I intend to keep going with it, despite not having looked at the other frameworks in a lot of detail.

You could argue that I’ve stumbled into my framework decision – but let’s go back another step and you could also argue that I stumbled into my choice of programming language. These days, most languages can be run on the server-side, so there was nothing stopping me using Ruby (with Ruby on Rails), Node, or Python. What made me go for PHP?

PHP is still the most popular server-side programming language worldwide, and, more importantly, it’s the server-side language I have by far the most experience using. I could have spent a few weeks learning the ins and outs of C# and .NET to deliver my project, but given I have so much to build (remember the 5 incremental deliverables outlined in my Outline Project Specification), I didn’t want to find myself desperately trying to debug an obscure error in a new language a week before the deadline.

I think PHP and F3 are the right choices, but I hope in the coming weeks I can justify my decision with something a little stronger than just “it was the easiest way to get started”.