Request lifecycle

Same physics as the PHP tutorial - request in, response out. Symfony runs an HttpKernel + event pipeline before your controller.

The spine

Comments for the flow above:

• public/index.php still requires Composer autoload - nothing magical
• Kernel events = the wrappers you sketched as stretch goals on the mini-router (Symfony's "middleware" flavor)
• Router match is your {name} patterns grown up
• Response can be Twig HTML, JSON, redirect, file download…

Compared to the mini-router

// your toy version
$response = $router->dispatch($method, $path);
$response->send();

Symfony:

1. Creates a Request from globals ($_GET, $_SERVER, …) via HttpFoundation
2. Dispatches kernel events (kernel.request, kernel.controller, …)
3. Resolves the controller + arguments (route params, services)
4. Calls your action, wraps the return value into a Response
5. Sends it

You don't call echo and header() by hand anymore - return values / helpers do that.

Where "magic" actually is

• Service container builds controller dependencies and argument resolvers
• Event subscribers do session start, locale, security, etc.
• Doctrine lazy-loads associations if you aren't careful (we cover N+1 later)
• Twig compiles templates to PHP under var/cache

Once you see it as boot → events → route → action, Symfony code reviews get much calmer.

Next: declaring routes without writing a regex engine.

Best,

-- ł.