Symfony Runtime: front controller as a callable

public/index.php, unchanged since I learned Symfony. Create the request from globals, run the kernel, send the response, terminate. Symfony 5.3 arrives next month, and the Runtime component rewrites this file. It looks like a small refactoring. It is a statement about where PHP is going.

Baked into those few lines is one big assumption: one process, one request, then we die. FPM made the assumption true for fifteen years, so nobody saw it as an assumption.

With Runtime the file stops doing and starts describing:

require_once dirname(__DIR__).'/vendor/autoload_runtime.php';

return function (array $context) {
    return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
};

You return a callable that builds the application. How it runs is no longer your business. Under FPM it runs once and dies, as always. Under RoadRunner or Swoole a different runtime keeps the kernel alive and feeds it requests in a loop. Same application code, different process model, chosen by a Composer package.

The real price is not in this file. It is in the habits the old model allowed. Static properties as convenient storage. Superglobals read in random places. Services that accumulate state and count on the process dying before it becomes a problem. FPM was a garbage collector for our sins, restarting the world forty times a second. Long-running PHP takes that away.

So I read Runtime as a warning shot. The abstraction is ready before most application code is. Check your own project against one question: what breaks here if the process handles two requests instead of one?

I asked it about ours. I stopped writing the list at the session handler.