I’ve always been the kind of developer who wanted to have the maximum control on its application code.
Of course I often found myself involved in the same tedious tasks reinventing the wheel. But I found it even worse to spend a lot of time in learning just-another-framework and not being satisfied at all because:
- High learning curve;
- Some skills were very specific to that framework, hardly applicable in other situations;
- Huge amount of features, often a lot more than I needed;
- Risk to waste a lot of time just to figure out which file to edit if I wanted to change a single label;
- Hard to find collaborators able to work on that specific framework.
Cake PHP and Symfony
My first meeting with an MVC-like framework was Cake PHP in the mid 2000’s. Concepts like Models, Views and Controllers were completely new to me and I found the whole package a kind of mystery-box in which I didn’t really get the point in being so complicated.
Years later, I heard about Symfony and tried to give the MVC world another chance. The concepts were quite familiar this time, but the framework was really huge and I kept thinking that a framework like that was really over-engineered for my humble needs.
I appreciated the frameworks approach to the web-development problem. I studied it for a while, applying some of its concepts here and there, internalizing them as my work and projects evolved. I thought Cake and Symfony were valid, incredible tools but, simply put, too much for me.
Do it myself
One day, I decided to do it myself. Believe me, the only way to really know what a framework does, is try to build one.
I like to keep things simple. The first thing I just needed was a way to map a URL path to a PHP function that does “something”. What the function does is, in short, take some data and an HTML template and merge them to the final HTML output.
I ended up in building a small web engine I used in a pair of projects. However, I soon realized that there was room for a lot of improvements in terms of memory usage and performance, and in code abstraction as well.
I had finally grasped the concept of HTTP Request and Response abstraction. The question was: why should I have PHP objects that represent those entities that already exist? I just put here this slide, it will be the subject for a future article.
In my own web engine, I had rudimentary routing rules, so I looked around for a well-tested PHP component able to map a path to a function and I found the nikic/fast-route which appears to be one of the fastest out there.
Being that router engine the heart of the Slim PHP framework, I started to look at its code. I found it to have a lot in common with my web engine.
Slim helps me, but not too much
I feel Slim is perfect for my needs because it solves the problems I tried to address with my own engine. I was satisfied with the fact I developed a lot of code in the same manner the Slim developers did, without knowing it. My code was certainly not optimized and somehow buggy under some circumstances. I could not obviusly compete with a community of developers testing their code with different operating systems and web servers.
I decided to abandon my experiment and completely switch to Slim for my next projects. Slim is not huge (as the name suggests) like the big frameworks out there, and leaves a lot of freedom to the developer.
I’m free to manage the files and classes for my application in any way. Slim is built on top of components that follows the PHP-FIG standards, and it’s easy for it to integrate with other modern components and libraries.
The dependency container helps to use external libraries and tools. It’s easy to play with it although I must say I needed some practice to completely understand the way it acts. Dependency injection may not be immediately clear, but it’s really simple concept (I’ll try to explain clearly in the next articles).
The other nice concept featured by Slim is Middleware. You can always execute code and manipulate the request or the response, attaching this code to the entire application, to a specific route or to a route group. It comes in handy, for example, when you have to check only certain routes for user authentication.
Slim features the famous template engine Twig as rendering solution. However I feel perfectly comfortable and happy with PHP code in template files, so I always use the other alternative: the php-view rendering engine. I don’t feel like learning a new syntax to do things I am yet able to do… until I found a valid reason.
Slim does not include any built-in solution for interacting with databases. This is entirely up to the developer. For the same reason stated above, I don’t like to learn an ORM as Symfony suggests. I however evolved from the old mysql_* PHP statements and I’m fully satisfied with my PDO prepared queries.
In the end
Slim allows me to start my next projects from a highly efficient core, being able to decide the tools and the code organization I like. There are not tons of options and a lot to study, but every time I have a problem I can easily find a solution in the Slim framework GitHub or around in the Stack Overflow community. Likely the problem has been addressed yet and some option is ready to be used.
I think I can build something on top of Slim that will help me to be even more productive, automating the repetitive tasks and write reusable code.
Cake PHP web development framework
Symfony, High Performance PHP Framework for Web Development
PHP-FIG — PHP Framework Interop Group
FastRoute — Fast request router for PHP on GitHub
Slim — a micro framework for PHP
Slim on GitHub
Slim on StackOverflow
My own WebEngine experiment on GitHub