Slim: an HTTP microframework for PHP

The only evidence used is the Slim 4 documentation home page supplied as a source packet. Where that page is silent, this guide says so.

What Slim is

The Slim documentation describes Slim as a PHP micro framework for writing web applications and APIs. In its words, at its core Slim is a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response. The page positions Slim for APIs that consume, repurpose or publish data, for rapid prototyping, and for full web applications with user interfaces. It contrasts Slim with larger solutions such as Symfony or Laravel, saying Slim provides a minimal set of tools.

Classification

Slim is a framework. It is not a standalone PHP runtime, an alternative interpreter, or a CMS product. It runs on PHP and is served by whatever web server and PHP integration you configure. PHP core is the language and its engine. Slim is a library layer on top. A CMS such as Drupal is a different category again: a content product with its own storage and administration model. Slim has no built-in content model in the supplied material, so you decide how data is stored and presented.

The supplied page does not mention Swoole, Open Swoole or any persistent-worker integration. Those are separate projects and are not covered here.

Architecture

The documentation describes this flow:

• A web server such as Nginx or Apache sends all appropriate requests to one front-controller PHP file.
• That file creates the Slim application, defines routes and runs the app.
• Each route has a callback that receives the current request and response objects and must return a PSR-7 response.

The docs navigation lists the main concepts: application life cycle, PSR-7, middleware and dependency container. It also lists routing topics (placeholders, names, groups, route middleware, container resolution) and packaged middleware for routing, error handling, method overriding, output buffering, body parsing and content length. The packet shows only the table of contents for these pages, so details are not asserted here.

The sample app on the page shows an ordering rule. Routing middleware should be added before error middleware, and error middleware should be added last. The error middleware flag for displaying error details is documented as something to set to false in production.

Execution model

In a classic request lifetime, PHP starts handling a request, your front controller builds the app, runs it and the request ends. Objects created for that request are normally discarded afterwards. The documented Slim flow fits this model: the front-controller file instantiates and runs the app.

A persistent worker keeps PHP code and objects in memory across requests. The supplied page does not describe running Slim that way, so support for it is unknown. If you use any adapter or worker runtime with Slim, check that project's own documentation. Persistent workers bring state leakage risks:

• Static properties, singletons and container services can keep data from one request into the next.
• A user, locale, request ID or cached permission stored in a long-lived object can be served to the wrong visitor.
• Open database transactions, file handles and buffered output can survive longer than intended.

Cleanup means building per-request state fresh, resetting or avoiding mutable shared services, closing resources, and testing that two consecutive requests cannot observe each other. Keep that discipline even though a classic lifetime hides most of these bugs.

Bring your own components

Slim 4 uses PSR-7 messages, and AppFactory needs a supported PSR-7 implementation installed. The page names Slim PSR-7 as an example, with its server request creator included. It also mentions first-party components (Slim-Csrf, Slim-HttpCache, Slim-Flash) and third-party packages from Packagist. The navigation lists add-ons for Twig and PHP templates and cookbook entries for CORS, file uploads and Doctrine. Those are components you opt into, not a full-stack product.

Practical use cases

• A small JSON API that maps routes to callbacks.
• A prototype where you want routing and PSR-7 objects without a large framework.
• A service that assembles your own choice of container, templating and persistence.
• A teaching project for understanding front controllers, middleware and HTTP messages.

Installation approach

The packet lists an Installation page but does not include its contents. The example below therefore uses Composer to add the Slim framework and the Slim PSR-7 implementation, which the home page names. Confirm the exact steps on the official Installation page before relying on this guide. Version numbers, PHP compatibility, license of the software and support status are unknown from the supplied evidence. The learning track uses PHP 8.4 with PHP 8.5 planned. The example avoids version-specific syntax, but compatibility of the installed Slim version with PHP 8.4 must be verified by an integration check.

The example uses PHP's built-in development server bound to 127.0.0.1. It is for local learning only. Do not expose it publicly, and never expose FastCGI publicly.

Deployment

The docs home page says to configure Nginx or Apache so that requests reach one front-controller file. The Web Servers and Deployment pages are listed but their contents were not supplied, so server configuration, rewrite rules, caching and production hardening are unknown here. Before deploying, turn off error detail display, review logging, and keep the web root limited to the public directory so that source and vendor files are not served.

Strengths

• Small conceptual surface: request, route, callback, response.
• PSR-7 interfaces make messages standard and portable.
• Middleware and a dependency container are documented core concepts.
• You choose your own templates, persistence and extra components.

Limitations

• It is not a full-stack framework, a CMS or a runtime.
• You must assemble many decisions yourself.
• Lifecycle status is unknown from the supplied packet. The page documents Slim 4 and links to Slim 3 docs, but gives no support dates.
• The page claims Slim is fast, but no measurements are supplied, so this guide makes no performance claim.
• The documentation text is under a Creative Commons non-commercial, no-derivatives license. That applies to the site and docs; the software license is not stated in the packet.
• This example is not a browser exercise. It needs Composer and a local PHP CLI.

{
    "name": "learnphp/slim-hello",
    "description": "Minimal Slim 4 learning example",
    "type": "project"
}

<?php

declare(strict_types=1);

use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;

require __DIR__ . '/../vendor/autoload.php';

$app = AppFactory::create();

// Routing middleware before error middleware, as in the Slim docs example.
$app->addRoutingMiddleware();

// Development only: error details enabled. Set the first argument to false in production.
$app->addErrorMiddleware(true, true, true);

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

$app->get('/ping', function (Request $request, Response $response): Response {
    $response->getBody()->write(json_encode(['status' => 'ok'], JSON_THROW_ON_ERROR));
    return $response->withHeader('Content-Type', 'application/json');
});

$app->run();

composer require slim/slim slim/psr7
php -S 127.0.0.1:8080 -t public
curl http://127.0.0.1:8080/hello/World
curl -i http://127.0.0.1:8080/ping