Symfony: full-stack framework and reusable components

Nothing here has been executed or checked by a human, and the only evidence used is the official Symfony documentation index page. Where that page is silent, this guide says the answer is unknown.

What Symfony is

The documentation index presents Symfony as a full-stack framework with reusable components. It describes two things:

• A framework for building applications. The Getting Started section covers setup, pages, routing, controllers, Twig templates and configuration with environment variables.
• A set of stand-alone libraries. The index lists a Symfony Packages area described as stand-alone libraries that you can use in any PHP project. It also lists Symfony Bundles, described as third-party packages that add features to your applications.

Classification

Symfony is a framework. It is not a standalone PHP runtime, an alternative interpreter or a web server. It runs on PHP, so PHP core (the language and its engine) stays a separate thing from the framework code you install on top of it.

Symfony is also not a CMS product. A framework provides building blocks such as routing, a service container and forms. A CMS such as Drupal is a complete content-management product. The source packet does not describe any CMS, so this guide makes no claims about how any CMS relates to Symfony. Treat framework components and CMS products as different categories.

Architecture as documented

The index lists these architecture topics:

• Requests and responses
• The Kernel
• Services and dependency injection
• Events
• Contracts
• Bundles

A reasonable mental model follows from those names. A request comes in, the kernel handles it, and your code produces a response. Services are wired through dependency injection, and events let other code hook into the flow. Bundles package features for reuse. The index page does not explain how these pieces interact, so read the linked Architecture articles before relying on this summary.

The index also lists many feature areas: Doctrine databases, forms, tests, sessions, cache, logger, console, mailer, validation, messaging and queues, scheduler, notifications, serialization, translation, security (authentication, voters, passwords, CSRF), AssetMapper, Symfony UX, Webpack Encore, HTTP client, filesystem, locks, workflows, UID, YAML and webhooks. It lists a Symfony AI entry without further detail. The index does not say which of these are separate packages and which ship in a default project.

Execution model

The index does not describe a request lifetime. In a classic PHP setup, each request starts a fresh process or worker state and discards it afterward, so memory does not carry from one request to the next. Whether Symfony is meant to run under persistent workers is unknown from this source, and so is any runtime-specific configuration.

Persistent workers are a different model. A long-running process handles many requests and keeps objects in memory between them. That brings state leakage risks:

• Static properties, singletons and cached service instances can hold one user's data and expose it to the next request.
• Open resources, such as database connections and file handles, can go stale.
• Authentication or session data, or request-scoped values, can survive when they should not.

Cleanup in a persistent worker means resetting or recreating anything request-specific after each request. Verify what your runtime and framework version actually do before relying on it. This is general PHP guidance, not a Symfony claim. The Swoole and Open Swoole projects are distinct, and neither is covered by this source.

Practical use cases

The index points to several kinds of work:

• Full web applications, following Getting Started, with Twig, Doctrine, forms and security.
• Console tools and background work, using the Console, Messaging and Scheduler topics.
• Using individual components in a PHP project that is not a Symfony application. The example below does this with the HTTP request and response objects.
• Building a custom framework from Symfony packages, which the index offers as a way to learn Symfony internals.

Installation approach

The index links a Setup / Installation article but does not reproduce its steps, so this guide gives no full-stack installation commands. Follow that official page for a full application. The index also names the Symfony Demo application for learning by doing, and the Symfony Quick Tour, described as interactive with nothing to install.

The example below uses Composer to pull in one component. Composer is not mentioned in the source. The package name and class names come from general knowledge of the project and have not been checked against these sources. The manifest uses an unpinned version requirement because the supported versions are unknown here. Pin a version after review.

Strengths documented

• Multiple official learning routes: the Quick Tour, Getting Started, a free video course, the Demo app and the official book.
• A broad documented feature set.
• Reusable components designed for use outside the framework.
• Published best practices, described as optional.

Limitations and unknowns

• The current version, PHP compatibility, support windows, deprecations, license and performance are all unknown from this source.
• Persistent-worker support is not described.
• Lifecycle is marked unknown because the page gives no support status.
• The index mentions Symfony 7 training courses but does not say which version is current, so that mention should not be read as a version claim.
• The index is a table of contents, so detailed behavior needs the linked articles.

Deployment

The index lists a Production section covering Deployment, Performance, HTTP Cache and Cloud / Upsun. It gives no procedures. Read those articles and plan deployment from them. Do not expose the PHP development server, or any FastCGI service, to the public internet.

Learning track

The track uses PHP 8.4, with PHP 8.5 planned. Whether Symfony components support PHP 8.4 is not stated in the source. The example requires PHP 8.4 only to match the track, and the integration check must confirm that Composer can resolve compatible packages.

Example

The example reads a query parameter through a Symfony request object and returns a plain-text response. It needs a local PHP CLI, Composer and network access to download packages, so it is not a browser exercise. It binds to 127.0.0.1 only.

{
  "name": "learnphponline/symfony-component-demo",
  "description": "Demo using a Symfony component outside a full application",
  "type": "project",
  "require": {
    "php": ">=8.4",
    "symfony/http-foundation": "*"
  }
}

<?php

declare(strict_types=1);

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

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

$request = Request::createFromGlobals();

$query = $request->query->all();
$name = isset($query['name']) && is_string($query['name']) && $query['name'] !== ''
    ? $query['name']
    : 'world';

// Keep the greeting short and printable.
$name = substr(preg_replace('/[^\p{L}\p{N} _-]/u', '', $name) ?? '', 0, 40);
if ($name === '') {
    $name = 'world';
}

$response = new Response(
    'Hello, ' . $name . '! Path: ' . $request->getPathInfo() . "\n",
    Response::HTTP_OK,
    ['Content-Type' => 'text/plain; charset=UTF-8']
);

$response->send();

composer install
php -S 127.0.0.1:8000 -t public
curl http://127.0.0.1:8000/
curl "http://127.0.0.1:8000/?name=Ada"