Yesterday a client asked us to install Rules module (again, repeating an earlier request, when he had missed my answer that we had installed ECA instead). I went out to Drupal.org and was shocked to see that after ~8 years of very little activity, Rules has had a resurgence of work done, complete with a stable release and steady activity for the past 6 months. Then later I saw an issue in the Drupal queue asking for an honest comparison of the two. I've been heavily involved with ECA for more than 2 years -- I've blogged about it extensively, used it on dozens of sites for some really sophisticated functionality, fixed bugs, created plugins. I've done a presentation on ECA at DrupalCon, and last month wrote 24 posts on automations for our Advent Calendar, most of which feature ECA.
Both of these are automation platforms that allow you to make a Drupal site do a huge range of activities automatically.
Rules
Rules is a module that did heavy lifting in Drupal 7, on hundreds of thousands of sites. Drupal Commerce depended upon it to put together checkout and payment flows. We used it heavily on a bunch of sites, for hooking up miscellaneous automations.
It was always a bit clunky, and it usually took longer to create a rule than to just write code to do something -- and when we started using Drupal 8, writing code got a whole lot easier.
The big issue with Rules is that it never got a stable release for Drupal 8. Nor Drupal 9. Not even Drupal 10, until last June, when the core update to Drupal 10.3 broke some critical functionality that the alpha Rules module depended upon, forcing action from developers -- because even though it didn't get a stable release for more than 8 years, it was still in widespread use.
There are still fundamental issues with Rules that aren't yet fixed -- for example, the ability to reliably run a rule on a schedule (which is one of our main needs!). Rules in Drupal 10 is very similar to Rules in Drupal 7.
ECA
Meanwhile, the Events, Conditions, and Actions (ECA) module came out about 3 1/2 years ago. The developers of ECA completely re-thought how you should be able to build automations, taking advantage of Business Process Model and Notation (BPMN) as a framework to build automations in a more user-centric, industry-standard way. And because they didn't try to support any legacy modules, they were able to start right in Drupal 9 using the latest APIs that weren't at all available when Rules started.
This got ECA to a mostly working state, very, very quickly.
I stumbled across it around 2 1/2 years ago, and once we started using it, there was no going back to Rules -- it's better in pretty much every way.
The details
ECA plugins are really simple to create. ECA also supports just about every event Drupal dispatches, and supports core action plugins as well as ECA action plugins -- this means there's a lot of existing code that "just works" with ECA even though they were built with other systems in mind. That means you can do more with ECA!
Rules, on the other hand, requires you to create custom plugins for any action you want a rule to do. Both require custom event and condition plugins. Plugins in general are easy to create -- but somebody needs to create them. Jürgen Haas in particular has gone to great lengths to create hundreds of plugins for ECA to cover a huge range of possible actions.
Architecture differences
Aside from code, I see one significant architectural decision that seems different: Rules seems tightly integrated with Typed Data, whereas ECA is tightly integrated with Token. I see on the Rules page that they changed their tokens from Token module syntax to Twig syntax, calling out that this allows them to leverage the TypedData system to support any data property on the various objects involved, as long as the TypedData is set up correctly -- and point out that Token is generally limited to strings.
ECA on the other hand has expanded its use of tokens to include objects and lists, as well as wrapping them in "DTO" - Data Transfer Objects. So this basically means the two systems have made a very different decision on how to solve the same problem -- passing structured data around. Both of these seem legitimate to me -- the typed data approach might lead to better (or at least easier) validation of data objects, but less flexibility. So that means it might be easier to find the data elements you need when working with Rules, compared to ECA where you're using the Token Browser which doesn't always show exactly the token you need.
That said, I think there's a lot more support for tokens than TypedData, so that's another area where ECA might have the edge in terms of pure breadth of available "stuff" you can do with it, while possibly being harder to discover exactly how to hook it all up.
Other differences
The other differences that come to mind, take my feedback with a grain of salt -- we've been all in on ECA for over 2 years, and I have not looked at Rules since we switched over -- but here are my informed opinion of ECA vs uninformed opinion of Rules:
- Lists -- ECA has a "list" token built in that allows loops, entire subroutines acting on each item of a list (or row of a view). Loops in Rules are cumbersome and confusing -- and "Rules Components" which allow you to do subroutines are on entirely different admin pages
- BPMN -- I would not minimize how powerful it is to be able to visualize the flow of events, particularly when talking with stakeholders and less involved people.
- Documentation -- there's still a lot of room for improvement here, a lot of stuff that's missing -- but Jürgen has done a fantastic job of setting up a documentation site, making it so all actions/events/conditions link to a doc page that lists tokens, etc. and is full of examples. He also did a series of videos that walk through a lot of different scenarios. But it's not just documentation of ECA -- in the BPMN modeler, it's easy for you to document your models. This is huge, particularly when you come back years later to change some functionality. There's a documentation field in each action, flow, and event where you can put notes, and you can attach freeform notes anywhere you want in the model. The Rules documentation seems woefully out of date -- but on the other hand when I last looked at it it was quite similar to Rules in Drupal 7, so maybe there's some old docs that still apply?
- Performance - original versions of ECA might've carried a small performance penalty because it had code called for every event in the system which had to then check if there was any ECA model to execute. That's one reason why there are so many submodules - so you could turn off swaths of functionality. Now that's no longer the case -- ECA manages its event handlers so they are only run if the event exists in a model. I haven't seen any benchmarks of either ECA or Rules, and I don't know what sort of performance impact Rules 4.x has.
Regarding stability, the move from 1.x to 2.x was a bit rocky -- a bunch of our models broke, silently. 2.x does have a lot better validation, and the event performance improvements which I think were really the cause of the breakage -- in 2.x the event registration is centralized and standardized, which meant a lot of the tokens that were defined in the original event plugins now need to be properly declared. These were easy to fix, but caught us by surprise. On the other hand, I'm seeing lots of issues in Rules that still seem to block a bunch of scenarios, and it wasn't marked stable for nearly a decade -- is it really stable, or just enough pressure to declare it so that it (finally) starts getting security team coverage and enterprise adoption (which is not meant as a slam, that seems totally legitimate to me). I think ECA has had so much more attention and excitement from the active Drupal community than Rules in the past couple years.
So all in all, I think ECA wins in just about every category - the one thing Rules has that ECA doesn't is that tight integration with Typed Data.
Want to learn more?
My presentation from last year is online -- watch it here!
Add new comment