It ships with the framework. It has retry logic, native AMQP support, first-party documentation. Our setup looked artisanal by comparison.

Fair question. We took it seriously. Here’s what we found.

Wiring the topology by hand

Swarrot is a consumer library that wraps the PECL AMQP extension. It reads bytes from a queue, runs them through a chain of processors (their term for middleware), and lets your code decide what to do with the payload. That’s really it.

The middleware chain is the interesting part. Processors are nested decorators, each wrapping the next. The outer layers handle infrastructure concerns before the message even reaches your business logic:

middleware_stack:
    - configurator: 'swarrot.processor.signal_handler'
    - configurator: 'swarrot.processor.max_execution_time'
    - configurator: 'swarrot.processor.exception_catcher'
    - configurator: 'swarrot.processor.doctrine_object_manager'
    - configurator: 'swarrot.processor.ack'
    - configurator: 'app.processor.retry'

signal_handler sits at the top because it needs to catch SIGTERM before any other processor sees it. ack sits near the bottom because you only acknowledge the message after processing succeeds. The order is not arbitrary, and it’s entirely visible in configuration.

The topology is equally explicit. You declare everything yourself: exchanges, routing keys, retry queues, dead-letter queues:

messages_types:
    content.ingest:
        exchange: e.app.content
        routing_key: q.app.content.ingest
    content.ingest_retry:
        exchange: e.app.content
        routing_key: q.app.content.ingest.retry
    content.ingest_dead:
        exchange: e.app.content
        routing_key: q.app.content.ingest.dead

Three entries per logical message type: main queue, retry queue, dead-letter queue. Everything that exists on the broker is named right here. The config is verbose but honest: no inference, no convention over configuration. If a queue exists in RabbitMQ, you can trace it to a single line of YAML.

When the class name becomes the route

Symfony Messenger operates one level higher. You define a message class, a handler, and a transport. The library handles serialization, routing, retry, and failure queues automatically.

class IngestContent
{
    public function __construct(
        public readonly string $contentId,
        public readonly string $source,
    ) {}
}

framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                retry_strategy:
                    max_retries: 3
                    delay: 1000
        routing:
            'App\Message\IngestContent': async

Messenger serializes the object, puts it on the transport, and deserializes it on the other end into the correct class. No manual topology, no explicit exchange names. The class name is the routing primitive.

That last sentence is exactly where things got complicated for us.

Where typing becomes coupling

Messenger assumes that the producer and the consumer share a PHP class definition. That’s fine for a single app, or for services that share a dedicated contracts package. In a monorepo of independent Symfony applications, it creates coupling that simply doesn’t exist today.

Take a content ingestion message that twelve services consume. With Swarrot, each service reads the raw JSON payload and picks the fields it cares about. Adding a new field means updating the producer. Consumers that don’t need the field keep working without any modification.

With Messenger, IngestContent must be defined somewhere that all twelve services can reference. That means either:

• A shared PHP package, versioned, deployed, and maintained across services. Every schema change becomes a cross-service coordination exercise.
• Duplicated classes in each service, which drift silently apart under pressure.

Neither is free. The shared package approach inverts the ownership model: the message schema becomes a dependency rather than a contract defined at the boundary. The duplication approach is just the original problem deferred.

The root difference is what a message represents. Messenger is designed for typed commands: an object that carries meaning and dispatches to a specific handler. Swarrot treats messages as opaque data: bytes that flow through a topology, processed by whatever consumer happens to be listening. If your messages are data, the extra abstraction Messenger adds doesn’t help you. It creates friction.

The blocker

The serialization problem was the decisive one. In a monorepo where services are autonomous, sharing PHP classes between them isn’t architecturally neutral: it’s a coupling decision that makes future changes harder. We would have been trading a nominally “legacy” library for a more modern one while introducing exactly the kind of tight coupling we’d spent years avoiding.

There were secondary concerns too. The PECL AMQP extension gives direct access to broker features (message priorities, per-queue TTL, headers exchange routing) that Messenger abstracts away. And migrating fifteen consumers without a flag day means running both libraries in parallel, which is a real operational constraint.

But the serialization issue alone would have been enough.

Data or commands: that’s the question

The choice isn’t about library quality. Messenger is well-maintained, well-documented, and integrates cleanly into the Symfony ecosystem.

The question to ask first is: what are your messages?

If they are typed commands with a known schema and a single authoritative consumer, Messenger is a natural fit. You write a class, a handler, configure a transport, and the infrastructure handles the rest.

If they are data payloads consumed by multiple independent services, each of which owns its own deserialization, the abstraction Messenger adds works against you. Swarrot’s explicit topology and raw payload model give you more control where you actually need it.

One real limitation to keep in mind: Swarrot is tied to the PECL AMQP extension, which only implements AMQP 0-9-1. That means RabbitMQ (or a compatible broker) is a hard dependency. If your infrastructure ever moves toward an AMQP 1.0 broker (Azure Service Bus, ActiveMQ Artemis), Swarrot can’t follow. Messenger’s transport layer abstracts this cleanly: changing brokers means changing a DSN, not rewriting consumers.

If broker portability is a requirement, or likely to become one, that changes the calculus significantly.

Swarrot isn’t legacy to migrate away from. For now, it’s the right fit: AMQP routing as the primitive, messages as data, RabbitMQ as a long-term infrastructure choice.

That could change. A shared contracts package, a new broker requirement, a greenfield service that doesn’t carry the existing topology weight: any of these could tip the balance toward Messenger. The library isn’t wrong for this platform. It may just be the right answer for a future version of it.

4.0 is a different philosophy. The Symfony Standard Edition, the monolithic starting point that bundled everything and left you to remove what you didn’t need, is gone. In its place: a microframework that grows.

Flex

Symfony Flex is a Composer plugin that changes how you install Symfony packages. Before Flex, adding a bundle meant: install via Composer, register in AppKernel.php, add config to config/, update routing if needed. Four steps, all manual.

With Flex, installing a package runs a “recipe”: a set of automated steps that registers the bundle, generates a config skeleton, and wires routing. Installing Doctrine:

composer require symfony/orm-pack

That command installs the packages, creates config/packages/doctrine.yaml, adds the env variable stubs to .env, and registers everything. One command, zero manual steps.

Recipes are community-contributed and hosted on a central server. Quality varies, but for major packages they’re maintained alongside the packages themselves.

The new project structure

The Standard Edition layout (app/, src/, web/) is replaced by a leaner structure. Config lives in config/ split by environment. The public directory is now public/, not web/. The kernel is smaller. Controllers are plain classes, no extends Controller required.

More importantly, the default services.yaml uses the 3.3 autowiring defaults that make explicit service configuration mostly unnecessary. New projects start minimal and grow by adding what they actually need.

Services private by default

4.0’s biggest BC break for existing apps: all services are private by default. You can’t fetch a service from the container directly anymore, it has to be injected. This is the right call from a DI perspective, but it breaks anything that used $this->get('service_id') in controllers.

The migration path is AbstractController, which provides the same convenience methods through lazy service locators rather than raw container access.

What was removed

4.0 is clean because it removes everything deprecated in 3.4:

• The old form events, the old security interfaces, the old configuration formats
• Support for PHP < 7.1.3
• The ClassLoader component
• ACL support from SecurityBundle

The removals are aggressive. Apps that skipped fixing their 3.4 deprecations will have a rough time. Apps that did the cleanup beforehand have a smooth path.

Symfony 4.0 is the reset the framework needed. The Standard Edition had accumulated years of “this is how it’s done” that Flex sweeps away in one shot.

Environment variables that actually know their type

Before 3.4 and 4.0, environment variables were strings. Always. Trying to inject DATABASE_PORT into an int parameter would silently break or blow up with a type error. The fix was ugly: cast in PHP or avoid typed parameters entirely.

4.0 ships with env var processors that handle the conversion at the container level:

parameters:
    app.connection.port: '%env(int:DATABASE_PORT)%'
    app.debug_mode: '%env(bool:APP_DEBUG)%'

Beyond casting, processors can decode base64, load from files, parse JSON, or resolve container parameters within a value. The json:file: combination turned into a clean pattern for loading secrets from mounted files in containerized deployments:

parameters:
    env(SECRETS_FILE): '/run/secrets/app.json'
    app.secrets: '%env(json:file:SECRETS_FILE)%'

You can also write custom processors by implementing EnvVarProcessorInterface and tagging the service. Looks like overkill until the day you need it.

Tagged services without the boilerplate

Before 4.0, collecting all services with a given tag into one service meant writing a compiler pass. Forty lines of PHP to say “give me everything tagged app.handler.”

3.4 introduced the !tagged YAML shorthand, and 4.0 carries it forward:

services:
    App\HandlerCollection:
        arguments: [!tagged app.handler]

The collection is lazy by default when type-hinted as iterable, so services aren’t instantiated until you actually iterate. This replaced a whole category of compiler passes that existed for the sole purpose of building lists.

PHP as a configuration format

YAML has been the default for so long it feels required. It isn’t. 4.0 ships with PHP-based configuration using a fluent interface:

// config/services.php
return function (ContainerConfigurator $container) {
    $services = $container->services()
        ->defaults()
            ->autowire()
            ->autoconfigure();

    $services->load('App\\', '../src/')
        ->exclude('../src/{Entity,Repository}');
};

Same approach works for routes. The practical benefit: IDE autocompletion, type checking, and actual PHP logic in configuration without the % parameter interpolation syntax. YAML isn’t going anywhere, but now you have a choice.

Argon2i, because bcrypt was already aging

Symfony 3.4/4.0 added Argon2i support, winner of the 2015 Password Hashing Competition. Configuration is one line:

security:
    encoders:
        App\Entity\User:
            algorithm: argon2i

Argon2i is built into PHP 7.2+ and available via the sodium extension on earlier versions. Like bcrypt, it’s self-salting, no need to manage salt columns. Unlike bcrypt, it’s designed to resist GPU-based attacks with configurable memory usage. If you’re starting a new project on 4.0, there’s really no reason to reach for bcrypt.

The form layer gets a Bootstrap 4 theme

The existing Bootstrap 3 form theme has been around since Symfony 2.x. Bootstrap 4 ships as a first-class option in 4.0:

twig:
    form_themes: ['bootstrap_4_layout.html.twig']

More useful in practice: the tel and color HTML5 input types are now available as TelType and ColorType form types. Before, you had to write custom types or override raw widgets for those.

Local service binding

Global _defaults bindings apply to all services. Sometimes you need a binding scoped to a specific class or namespace, like different logger instances for different subsystems.

4.0 supports per-service bind for exactly that:

services:
    App\Service\OrderService:
        bind:
            Psr\Log\LoggerInterface: '@monolog.logger.orders'

    App\Service\PaymentService:
        bind:
            Psr\Log\LoggerInterface: '@monolog.logger.payments'

Same interface, two different implementations, no factory, no extra configuration. Small feature, but it kills a whole category of awkward workarounds.