Why use a micro framework?
On social media, often new PHP devs ask "What framework should I use for my project" and generally the answers given are "Laravel" or "Symfony".
While these are both good options, the right answer to this question should be "What do you need the framework to do?"
The right framework should be one that does what you need it to, without loads of features you will never use.
If you are making a website with one route, using Laravel or Symfony would be over engineering the site, while for a complex site, Laravel or Symfony may be the right choice.
Micro frameworks are great for building small to medium sized sites that don't need all of the features a full stack framework provides.
While there are many, Slim and Flight PHP are both great examples of micro frameworks.
Recently I built a small website that asks the user to solve 10 database related questions. It had three routes, and some basic queries to fetch the questions and compare the answers.
For a small project like this, a micro framework is a great choice. I built the site on both Slim and Flight PHP to compare them.
Skeletons
If you haven't used a particular framework before, using the provided skeleton project is generally a great place to start.
Flight PHPs skeleton project is pretty much what I expected, light weight, simple MVC setup, easy to understand the folder structure and know where everything should go in the project.
For someone new to the framework, the learning curve to getting up and running is minimal.
Light on composer libraries, just 5 in total (including the core library), 4 used in production.
The production size for the Skeleton, was 1.6Mb.
Slims skeleton project surprised me, The directory structure was more complex than I had anticipated. Geared more towards a structure that may be used in a larger project than in a small project. For a micro framework, this wasn't expected.
The Slim skeleton was a bit heavier than Flight PHP. 21 composer libraries, 9 used in production. Production size of the project was 3.3Mb.
Both worked out of the box with minimal additional configuration needed.
Building From Scratch
Instead of using the skeletons, I decided to build the sites by creating my own setup. The advantages of doing this is that I was able to tailor the frameworks to suit my needs, and see how flexible they were to different structures.
One of the big advantages of using micro frameworks is being able to build them to do exactly what you need without unnecessary overhead, adding features and libraries as they become needed.
My setup with Flight PHP wasn't significantly different from the skeleton, While I did end up with less directories and different composer libraries, structurally, it was similar.
With Slim, the structure of the project ended up significantly different from the skeleton.
It was nice that Slim was flexible and wasn't making assumptions about structure and worked just fine with a completely different structure than the skeleton.
Flight PHP is also flexible in this way, allowing for more complex structures if needed, adding new libraries into the framework was straight forward.
The Code
Routing
From a routing point of view, both were nice to work with. They were both easy to set up without much documentation reading necessary.
Routes in Flight PHP were slightly simpler to setup than Slim, and used less code to do so, but neither was difficult to setup.
Routing groups, regex abilities and middleware options made routes flexible while still being easy to work with.
Database Connections
With Slim, the expectation is that you should use an ORM like Eloquent or Doctrine for your database queries, whereas Flight PHP provides a simple wrapper for PDO that can be used if you need to and optionally, Active Record can be added to the project for query building.
For a small project like the one I was working on, using an ORM seemed to be a bit more than necessary, so I ended up building a small PDO wrapper class for Slim, similar to the one that comes built into Flight PHP.
ORMs are great, but having the flexibility built in to choose how I wish to code database queries is a good feature.
General Coding
Both Slim and Flight PHP Frameworks are good at allowing you to write code your own way.
Some frameworks tend to force you into coding a specific way and at times it can feel like you are fighting against the framework.
Frameworks should work with you not against you, and both of these felt like they were working with me.
Slim also provides a number of handy add ons including CSRF integration and HTTP caching.
Flight PHP provides additional add ons including Permissions and Active Record.
All of these add ons are helpful additions without having to use 3rd party solutions or build your own.
Returning JSON as a response is cleaner in Flight PHP than it is in Slim, Slim 3 had a convenient withJson response. While Slim 4 adheres more to PSR-7, it does mean that to build the JSON response requires more code.
If I was going to be using JSON responses a lot, I would likely create a wrapper to make it more convenient while still adhering to the PSR-7 standard.
This is a significant difference between the two Frameworks, Slim feels like it needs to be tailored more by creating classes to clean up and simplify the codebase, while Flight PHP has already done this for you.
Slim provides a number of helper middleware. The middleware is required in order to make some features work.
An example of this is fetching data from Javascript using FETCH. Slim has a method getParsedBody to create a data array from the POST request.
However, in order to use it the addBodyParsingMiddleware needs to be added to the container.
It's a little bit of a trap for new devs, but also provides access to optional features, which can lower the frameworks overall footprint by only enabling features you need.
Flight PHP achieves this through a config file, some features can be turned on and off through the config rather than through middleware enablement.
Speed Tests
According to benchmarks, comparing the two has interesting results, Slim edges out Flight PHP on some areas while Flight PHP edges out Slim in other areas.
Putting the two frameworks to a test on my own code showed that Flight PHP had faster and more consistent response times than Slim.
Front End
GET request returning JSON
POST request returning JSON
What I found noteworthy was the outlier spikes when using Slim.
Running these tests multiple times produced similar results each time to the ones I have shown above, with generally good response times for both but with outlier spikes in Slim that didn't occur when testing Flight PHP, and Flight PHP generally having better response times.
Final Thoughts
If you haven't ventured into micro frameworks, give them a go, there are a few out there and it can be a great learning experience to try them out and see what you like and what you don't like in each one.
Both Slim and Flight PHP are great micro frameworks.
Slim is a solid framework with some nice-to-have features, that will work quietly for you.
Flight PHP is lighter weight, and its simplicity makes learning the framework really easy.
Good response times and more simplified code to achieve the same thing makes it a really good choice for a micro framework to use.
After putting these two side by side, I do prefer Flight PHP over Slim, but as with any framework, give it a go and see if it works for you.
After all, the right framework is a framework that does what you need it to do.
Top comments (8)
Try also github.com/walkor/webman
or my beloved FatFree Framework :)
I do like Fat Free, have used it quite a bit,
The Webman website for the docs etc no longer work it seems :(
I used to be a fan boy for Fat Free as well. It's lacked a little bit for me recently with some problems I couldn't get around, that's why I maintain the Flight framework now to work around some of the problems I was running into with Fat Free.
Still hold a special place in my heart for Fat Free. Really helped me take my understanding of better design to the next level all those years ago.
Did you check this page? symfony.com/doc/current/configurat...
I looked this over and while Symfony can do it in one file-ish, I ultimately prefer the path that's simplest. If I was a new developer wanting to build a new project for the first time, even that page on symfony while following proper design patterns, would be a difficult start for me to wrap my head around all of what's happening.
For someone looking to build their own this would be a great starting point, im more looking for micros that I can just build on , and these one are great ones to do that with. Allows me to concentrate on building my code and not on the framework itself.
The point I tried to make is that Symfony allows you to bring your own batteries if that is what you want.
The thing is if is a application that is going to be around for a considerable time, most of the times it will outgrow the micro framework because other people are going to work on it.
If you choose a non standard way of building your application, you are the one how is in charge of documenting it. And we all know how bad we are at documenting things.
The benefit of having a bigger framework from the start is that there is a standard way of working. You might not like it, but if you build multiple projects that standard way of working will make you more productive, for example by using generator commands.
I mentioned Symfony because it provides a way to create a single file app to an MVC website, and everything in between. But You can do that with Laravel too. It is more MVC leaning so you have to ignore more things than with Symfony.
In my head ruby is the language that made micro frameworks mainstream, with Sinatra. And then when node became big Express took over that torch.
I see the appeal of a barebones tool. But I never had the feeling that Symfony or Laravel made me jump through hoops to create smaller applications.
Symfony is a micro-framework that can become a full-fledged framework when you add more components. But if you simply create a new project with Symfony you only have the HttpKernel, Router, very simple logger and DI. Nothing else. No ORM, no Template Engine, no message handler, etc.
Maybe you could have added it to your benchmarks. :-D
Great article, BTW. Thank you.