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
- implementing a first class Drupal database transport to remove the doctrine dependency
- adding retry functionality, for handling exceptions thrown in Messenger handlers
- continuing work on Symfony Mailer support both in contrib and core
- accelerating integration with contrib projects requiring execution of time-sensitive tasks, such as Scheduler, Scheduled Transitions, and Rules.
Read the other posts in this series:
- Introducing Symfony Messenger integrations with Drupal
- Symfony Messenger’ message and message handlers, and comparison with @QueueWorker
- Real-time: Symfony Messenger’ Consume command and prioritised messages
- Automatic message scheduling and replacing hook_cron
- Adding real-time processing to QueueWorker plugins
- Handling emails asynchronously: integrating Symfony Mailer and Messenger
- Displaying notifications when Symfony Messenger messages are processed
- Future of Symfony Messenger in Drupal
Related Articles
Displaying notifications when Messages for Symfony Messenger are processed
A trio of modules provide a unique experience for sites utilising SM and Symfony Messenger messages: Common Stamps, Pusher Mini, and Toasty. This combination ultimately shows UI toasts in the browser when Symfony messages relevant to the user are processed.
Handling Emails Asynchronously: Integrating Symfony Mailer and Messenger
Take advantage of Symfony Mailer’s first-class integration with Symfony Messenger brought to Drupal via the SM project, allowing your site to send emails asynchronously.
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.