Why Slim? What problem Slim solves better?



I’m an old php programmer, but new with any kind of framework.

Why do you use Slim? What’s are the main advantages over “vanilla” php?
Which Slim’s feature is essential for your project?

If my question looks navy, please don’t be angry. Just ignore it! :slight_smile:


Since Slim is a small framework it’s main features are easily enumerable :slightly_smiling_face:, these are Route matching, a Dependency injection container and Middleware support.

Route matching
In old school PHP applications routes are often created just by placing .php files with the desired name inside the public web directory. In Slim you have a single front controller that among other things specifies the routes of the application and maps them to specific callables:

$app = new \Slim\App();

$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $response->getBody()->write("Hello, {$args['name']}");

    return $response;

// other route definitions...


Dependency injection container
The Slim App object comes with a built-in DIC ($app->getContainer()) that you can leverage to define the relationship between the classes of your application. Another example that builds on the last one:

$app = new \Slim\App();
$cnt = $app->getContainer();

$cnt['pdo'] = function($cnt) {
    return new \PDO('mysql:host=localhost;dbname=testdb', 'root', 'root');

$cnt['hello_action'] = function() {
    return new \My\Namespace\HelloAction();

$cnt['register_action'] = function($cnt) {
    return new \My\Namespace\RegisterAction($cnt['pdo']);

$app->get('/hello/{name}', 'hello_action');
$app->post('/register', 'register_action');


Notice that when defining a route the callable can be just the name of a service. Also, requests to /register will instantiate a \PDO object and open a database connection but requests to /hello/{name} will not (only the services that the matched route requires are actually executed).

Middleware support
Middlewares are code that you can hook between Slim and the callables seen above. For instance, you could define a “backoffice” group of routes and attach an “AuthenticatedRequestsOnly” middleware to it. Or a “RateLimiting” middleware to the whole app, etc.

Edit: Here are a couple of demo projects showcasing all of the above:


And the usage of a template engine (which keeps control over the VIEW part of your MVC application)


Wonderful answer!

I’m now using Slim’s router and Twig. Next step are dependency injection and middleware for authentication.

If I understand it all correctly, all my old .php pages now should turn into classes, instantiable from (let’s say) index.php. Does it make sense?

I’ll check your recommended references.

Thank you very much!


Yes, it does. By convention these classes are usually called “actions”, here are some examples from Rob’s project: https://github.com/akrabat/slim-bookshelf-api/tree/master/web/src/App/Action

And this is where they are mapped to the routes: https://github.com/akrabat/slim-bookshelf-api/blob/master/web/src/routes.php