We have narrow down our search between Silex and Slim PHP frameworks for routing our REST APIs on our Apache/PHP/MySQL Server.
Both seem to have good reviews. Silex has probably a bigger community because it came from Symfony. But the documentation seems to be better in Slim.
What do you guys suggests? Any real world experience from production environments?
Sathish
I had the same choice to make, and I choose Silex, here is why :
To conclude, the main argument is that is based on Symfony which has many advantage. The Symfony Debug tools are the best thing on earth !!
Now I have two sites made with Twig and I'm really happy !
You can also see that, it's a technical comparison of these both frameworks : https://michalzuber.wordpress.com/2015/04/02/silex-vs-slim-php-microframework-comparison/
Slim 3 is very light weight and well suited to APIs.
You can optionally inject a container (Pimple by default but any Container-Interop will work) when constructing your Slim app. The Silex app extends Pimple so is a container.
Require slim/twig-view if you need Twig.
Slim's Request and Response support PSR-7 HTTP message implementation.
On January 12th 2018, Fabien Potencier, main author of this micro-framework, wrote that Sensiolabs stops supporting Silex.
https://symfony.com/blog/the-end-of-silex
Quote from Silex official site:
Silex is in maintenance mode. Ends of life is set to June 2018. Use Symfony 4 instead. Read more on Symfony's blog.
Slim is better if you want to create apis as its light and fast. Hence slim provides you the DI and routes it is much more flexible to use your own libraries or plugins from laravel or symfony or any third party. For example you can use sentinel from laravel for auth
The fact that Silex didn't support PSR-7 (at the time of writing this) a huge let down. It has so many good point already mentioned above. There is a plugin/extension that let you do that, however I don't see the point in adding this overhead when you are looking for a lightweight framework
TL;DR Choose Slim 4. "At its core, Slim is a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response. That’s it.". That should be it.
Late to the party but nonetheless here's my 2 cents(!) on the topic especially for future-googlers about this topic (even though Silex has reached end of life); I'd go for Slim. Which I already did on my previous 2 projects and it never let me down. Before the "here's why" part I'd like to share my background in a nutshell; I've worked with CakePHP and Laravel (especially >=5.4, <5.8) (and also with Lumen) years and years ago, right before I introduced myself with Node.js. Since then almost all my work runs on Node.js in the cloud. Now there's Golang on the table... but that's another story. Due to the requirements (or I should say constraints) of the aforementioned 2 projects, I have to write PHP. Since all those years past with Node.js I suddenly realized that I've forgotten about PHP almost completely. But there were 2 things I remember crystal clear; I've suffered. A lot. Because of those frameworks. Don't get me wrong former is the eldest one and the latter is the hipster of the pack, I respect them, their authors and their community. Everything has a reason to exist. But one is behemoth and the other one is magical (both not in a good way - I mean did you ever try to debug the Laravel with those facades and static methods and stuff?). OK I hear you, they are frameworks and they should do things for you (have you heard of Hollywood Principle), not everything for you. What this does mean to me is that they always whispering to your ear "our way or highway" (sometimes even yells). "Surely you can do this (say push a job to a queue, query your database, send email, etc.) but first do this, and then that" (maybe couple of more steps but this is not that bad). The bad thing about this is (not accusing anyone) I don't know what do they mean to the framework. They must do something meaningful, obviously though, I don't know what it is. Should I know? Yes, of course. I'm writing this application with that framework for God sake, I should know what it does. Version X was easy to grasp, but what about version Y, Z, T... Have you seen the version dropdown on the Laravel's documentation site? I took those steps because I've been told so. Again that's OK, fair is fair, those steps makes me achieve something far greater. But gradually I'm in their (respective authors') control. After that, even small change takes lots of searches on SO, GitHub issues, Google... Sometimes ends up with a success and most of the times don't. Either way the war against the framework must be declared. In my point of view this is not how an open-source framework should be. I am vendor locked-in in some sense. Maybe I want to adhere PSR (not that because I'm an advisor recommendation freak, because PHP-FIG is a well-known group with standards almost for every aspect of the language - this is important; for the language, not for any framework). Let me ask you something; do you use Composer? If so why? Because it's standard (I'm not sure if it is)? Because everyone uses it? Because the needed package of yours recommends this way of installing? Actually the answer doesn't all that matter, at the end of the day you use it. And you can use it practically for every PHP framework/project. The Composer requires you to have PHP installed on the system at bare-minimum and coincidentally it's the only requirement. This is freedom, and I want that. I want to pick and choose a router or a container for my taste. Today this package, later something else.
Slim gave me that freedom, especially on version 4. It's community is small, it's foreseeable; it does so much less than the other, full-blown frameworks. Actually it's a micro-framework (although I wrote an MVC application and REST API server with it). Other packages' communities are what matters right now. You need a container, composer require php-di/php-di. Now think about it's community, since "your" application (hence the framework) is a part of it. You have a problem? Ask for help specifically for that package. Maybe someone using another framework (or someone using no framework at all - if there's any left nowadays) might help you with your problem. So you've gone framework-agnostic thanks to your setup. Don't you like PHP DI, well find yourself another PSR-11 compliant package. Same applies for almost every part of Slim - except the router (Nikic's FastRouter should ring a bell), although it's already a foundation for other routers I see so far.
Before I finish I should say that too, Lumen and Silex has big brothers. I've been through a handful of frustration moments with Lumen; when I say "I can't do [fill here with a not-so-common problem] with Lumen version X.Y" they say "Use Laravel instead, it is really easy to upgrade". It should be for God sake! They share the same blood. I wasn't ask for that. If I were like to use Laravel I would choose it in the beginning and not use the Lumen in the first place. There were some reasons I did choose Lumen, like there were some reasons the author write it too (which I don't know why, but still...). Lumen should be a lighter weight, micro-framework alternative to Laravel, not a stepping stone.
Choosing Slim has it's disadvantages too but I think it's about the perception. I want to know what's happening on my application given the circumstances. Isn't reasoning about actually that? Even if I'm going to this rocky road at least I know at the end my application will do exactly as I commanded, nothing more nothing less.
Thank you for your time and please excuse me for formatting.
