Skip to main content
Start of main content.

The Future of Symfony Messenger in Drupal

by daniel.phin /

Share this post on social media

The thrilling conclusion to this eight-part miniseries includes the next steps for the SM project and the Symfony Messenger ecosystem.

Symfony Messenger and the SM integration permits time savings and improved DX for developers, making the pipeline and workers more flexible.

Real business value is added when messages can be processed in real-time, providing potential infrastructure efficiencies by permitting rescaling resources from web to CLI. End user performance is improved by offloading processing out of web threads.

Further integrations provide feedback to end users such as editors, informing them in real-time when relevant tasks have been processed.

Messenger messages are an opportunity to offload expensive business logic, particularly those which would be found in hooks. Instead of using the batch API, consider creating messages and deferring UI feedback to Toasty rather than blocking a user’s browser.

Given these points, integration with Drupal core could prove quite valuable.

The design of the SM project focuses on core integration from the beginning. The highest priority has been to maintain the original Symfony Messenger services and configuration, while minimising the introduction of new concepts.

In the context of core integration, niceties like SM’s queue interception feature may initially be left on the factory floor, but could prove useful when deprecating @QueueWorker plugins.

Concepts like the consume command may be a tricky requirement for some, but there are always workarounds that can be built, in the same vein as request-termination cron. Workarounds wouldn’t allow for the main advantage of Messenger, which is its real-time processing capabilities.

Next steps for the SM project and the Messenger ecosystem include


Read the other posts in this series:

  1. Introducing Symfony Messenger integrations with Drupal 
  2. Symfony Messenger’ message and message handlers, and comparison with @QueueWorker
  3. Real-time: Symfony Messenger’ Consume command and prioritised messages
  4. Automatic message scheduling and replacing hook_cron
  5. Adding real-time processing to QueueWorker plugins
  6. Handling emails asynchronously: integrating Symfony Mailer and Messenger
  7. Displaying notifications when Symfony Messenger messages are processed
  8. Future of Symfony Messenger in Drupal

Related Articles

Adding real-time processing to QueueWorker plugins

Projects no longer need to rely on unpredictable processing time frames. The SM project can intercept legacy Drupal @QueueWorker items and insert them into the Symfony Messenger message bus, effectively giving existing core and contrib queue workers jobs real-time processing capabilities.