Next steps for the event bus

[aldesantis]

We've had an event bus for quite some time now, but we're only using a fraction of its potential, because we only publish a very small number of events.

This means that extensions/apps can't easily use the event bus for implementing their own logic, which is a shame: a proper event bus, plus the existing class configuration hooks would allow us to get rid of decorators in the vast majority of use cases.

This, in turn, would lead to a cleaner, more reliable customization flow for Solidus apps.

I'd like to make the event bus a first-class citizen in Solidus 3 by publishing more events, providing better developer tooling for working with events, and relying more on events in our own code (which will force us to evolve the event bus over time).

Publish more native events in the core

The first and most obvious step is to publish more events. While we should pick these carefully and not overdo it, we should also be a bit more generous in which events we fire.

At the very least, everything that has some kind of state machine (orders, payments, shipments, reimbursements) should fire events on all transitions. Some work on this has already been started, see #3762.

We should also look at our extensions for inspiration: any decorator which is simply adding code instead of replacing existing Solidus code can potentially be replaced with the event bus.

Provide better tooling for working with the event bus

There's currently no dev tooling for working with events:

• If you fire an event and want to test that the event is fire, you need to stub Spree::Event yourself.
• If you write a subscriber and want to test that the subscriber is doing its job, you need to figure out how to properly test the subscriber in isolation yourself.
• There are no best practices around event naming and payload structure.

We should, at the very least, provide the following:

• Helpers for testing event emission and event subscribers. More information on this is available here.
• Documentation on best practices around event emission/testing and subscriber implementation/testing.

Provide a compatibility layer for extensions/apps

A recurring problem with the event bus is that, when a new event is added to the core, we want to encourage developers to use it immediately in extensions/apps. However, this isn't always possible:

• Extensions need to support all the officially maintained Solidus versions. If an event is added to the latest Solidus release, the extension can't use it until all the previous releases have been discontinued.
• Applications may not be able to upgrade their Solidus version immediately for other reasons.

This has been traditionally solved, both in extensions and applications, by providing a compatibility layer that fires the event on those versions of Solidus that don't support it. This way, the final code can still leverage the event and doesn't need to check the Solidus version, which leads to a more orthogonal and cleaner architecture.

While this can work with apps (because there's only one codebase), it's not a good idea to do it in extensions. If two extensions provide a compatibility layer for the same event (e.g., order_recalculated, which is available in Solidus 2.11 but not in 2.10), that event may be fired twice, depending on how the compatibility layer has been implemented. This will lead to the subscribers being called twice, which is a waste of CPU cycles at best, and a bug at worst.

One solution to this would be to provide a compatibility layer in the form of an extension (e.g., solidus_events_compat?) which contains a bunch of decorators to fire all the events supported by the latest version of solidus_core, no matter the current Solidus versions. Extensions and apps could specify this compatibility layer as a dependency and, because the compatibility layer and its decorators are only included once, they wouldn't run the risk of firing duplicate events.

Whenever a Solidus version is discontinued, we could update the compatibility layer and remove all of the events that were introduced in the discontinued version.

This could make a huge difference in the speed of adoption for the event bus and new events.

Rely on events internally

Lastly, once we have all of this tooling in place, we can start relying more on the event bus internally, to create a more orthogonal architecture that decouples the main business flow from auxiliary, unrelated logic.

Future opportunities

• Allow Solidus to fire outbound webhooks! 🚀
• Implement real event sourcing for better observability/debuggability.

[jarednorman]

Anything we can do to make events more the primary strategy for augmenting functionality in Solidus I'm in favour, so providing a compat extension seems like a great idea.

[spaghetticode]

💯 🎉 I think the plan looks great, I especially like the idea of taking inspiration from the existing extensions codebase for finding the best areas to be augmented with events.

[kennyadsl]

Great plan Alessandro! What about just adding this compatibility layer into solidus_support? That gem is already acting as a compatibility layer for core, apps and extensions and it's probably already included everywhere.

[jarednorman]

I feel like we'll need to be careful if we do that... but it would be kind of amazing and seamless if we can pull that off.