MindaPHP: a new PHP framework optimized for learning

When people talk about Web Application Frameworks (WAF), they often refer to web frameworks with a model–view–controller (MVC) architecture. MVC is a software architecture pattern that separates the representation of information from the user’s interaction with it. Most popular frameworks actually follow the model–view–adapter (MVA) that decouples the model and the view as described below:

Traditional MVC arranges model (e.g., data structures and storage), view (e.g., user interface), and controller (e.g., business logic) in a triangle, with model, view, and controller as vertices, so that some information flows between the model and views outside of the controller’s direct control. The model–view–adapter solves this rather differently than the model–view–controller does by arranging model, adapter or mediating controller, and view linearly without any connections whatsoever directly between model and view. — Wikipedia

More and more frameworks consist of a set of components (e.g. Zend). This is why people start to talk about “full-stack” vs. “glue” frameworks. A “glue” framework allows the programmer to create a tailor-made framework by gluing the needed components together. Full-stack frameworks, on the other hand, do not require you to do this.

Others talk about the difference between “push-based” vs. “pull-based” frameworks. This difference essentially is whether the framework pushes data towards the view or pulls the data in from the view. Most frameworks use the “push” approach.

Separation of concerns

What everybody seems to agree is that we need some form of “separation of concerns” or a n-tier architectural model. This means that we “divide the system cleanly into three tiers: the presentation tier, the business-logic tier, and the data-access or resource tier”, like MVC or MVA does.

What many framework architects do not seem to optimize for are these three important things:

  1. Cost of learning – maximize documentation reuse & minimize innovation
  2. Cost of scaling – maximize compatibility & minimize lines of code executed
  3. Cost of defects – maximize best practices & minimize complexity

They seem obsessed with optimizing separation of concerns a.k.a. reducing the “Cost of spaghetti”. In their efforts they create hard to grasp concepts, like “Dependency Injection” and “Aspect-oriented programming“. Do not get me wrong: I am not saying that these methods do not help you to fight the cross-cutting concern, but IMHO the complexity problems they cause outweigh their benefits of keeping things organized.

MindaPHP to the rescue

So, it may be clear that I believe that simple is better. With that “vision” I wrote MindaPHP. Whether you like it or not you may decide for yourself, but it certainly is easy to learn and about 10-20 times faster than CakePHP or Symfony, while providing the same abstraction layers to keep things organized.

MindaPHP aims to be a full-stack framework that is:

  1. Easy to learn
  2. Secure by design
  3. Light-weight

By design, it does:

  1. … have one variable scope for all layers.
  2. … require you to write SQL queries (no ORM).
  3. … use PHP as a templating language.

Mainly to make it easy to learn for PHP developers. Check it out!

Code: https://github.com/mevdschee/MindaPHP
Demo: http://maurits.server.nlware.com/


API first architecture or the fat vs thin server debate

API first architecture is an architecture that treats the API user as the primary user of the application. This means that API is not an alternative view in the MVC paradigm, but it has the highest priority. The main differentiators are that in “API first” the architecture enforces a complete, responsive, and well-documented API. This is especially important when targeting: mobile (Apps connect to the API), resellers (their presentation layer uses the API) and highly integrated, but decoupled, multi-product environments.

MVC reuse

The MVC architecture has been popular for a long time already. In 2004, it’s popularity skyrocketed when Ruby on Rails was released. MVC allows for high reuse in the case you have a front-end / back-end application (in the CMS sense), where customers use the front-end and employees use the back-end. This does require that you choose the same software stack for both the front-end and back-end, and make those applications as similar as possible. When the MVC strategy is executed properly, many parts of the application can be reused. Some of the parts that can be reused are: DBAL/ORM, Business Logic, Presentation and AAA. Specifically AAA (Authentication, Authorization and Accounting) can be reused by allowing employees to impersonate customers, use the same login screen and share logging facilities.

Mobile views for MVC

In 2007, Apple introduced the iPhone and from that time on the importance of web application (and websites) on small screens quickly grew. MVC applications were, and still are, very suited to facilitate small screens. All that is needed is a separate or adjusted set of views that is usable on a smartphone or tablet. The strategy of creating a single set of views that is suitable for mobile and also for desktop is called “mobile first“. This is the most cost-effective and radical approach, which requires strong leadership and decision taking, because all the software needs dramatic change, as all the views need to be adjusted. The alternative is to maintain two sets of views: one for mobile and one for desktop. The alternative views are often hosted on a “m.” subdomain. This is a simple and transparent approach.

Adding API to MVC

The dreadful “HTML5 vs Native” app development debate is going on right now and I quote Danny Brown:

Any company creating mobile apps today faces an important decision, Native or HTML5? Each one has its advantages, but choosing the wrong one could be costly. – Danny Brown

Choosing Native requires you to build a complete, responsive, and well-documented API, while choosing HTML5 requires you to redesign the views. There are arguments to defend either path and it depends on the situation what choice is best. There is one approach that will always fail: building an API as views on top of MVC. Let me explain why that fails and why so many people do it anyway.

Typically the (server-side) MVC approach leads to pages with 200 ms of load time. In this approach the server does three things: database abstraction, business logic, and presentation. This is why it is also referred to as “fat server”. An API is not responsible for presentation, executes smaller business logic per request and is therefor named “thin server“. A good API is highly optimized for speed and has typical load times under 20 ms. The means that when a mobile page is constructed there can be multiple (up to 10) calls made to render the full page within 300 ms.

Still when one took the MVC approach and is now lacking an API, the easiest thing to do is to add a few views that output JSON and call it a “RESTful API”. All you need to do is write some documentation and the boss will be happy. The fact that this API is totally unusable in real life, because it does not scale and is horribly slow, will only be noticed when the API is actually used and there is no way back.


Twitter & API first

In 2010, Twitter announced their “API first” strategy. They call this a JavaScript architecture, since they created a web application in JavaScript in a similar architecture as the mobile “apps”. This allows them to have full reuse of the API they build. Where initially the API was something “extra”, next to their web application, it then became the foundation of all other development. Their API is focused on delivering optimal integration for JavaScript programmers by using a RESTful JSON API. But they are also serving their application using traditional pages:

In order to support crawlers and users without JavaScript, we needed a rendering system that runs on both server and client. – Twitter

This approach of delivering traditional pages, while still using the “API first” strategy is what I call “Hybrid”. In the diagram below I’ve tried to enumerate the different approaches.



Optimal reuse brings down costs, but optimal reuse can only be achieved when there is a strong architectural strategy to follow. Refactoring code to increase architectural compliance does not bring value to the business directly. It will bring down the cost of change eventually, but the level of trust needed for these decisions is not easily gained.

Further reading

This is not the first post about “API first”. Check out the following links if you want to learn more about it:


I created a deck of 11 slides about “api first” for a presentation I gave on the 26th of November at LeaseWeb.