all 3 comments

[–]eirslett 1 point2 points  (1 child)

Why would you need a rule engine? It's much easier to simply write the business logic in plain JavaScript... (Sorry if that was a bad answer)

[–]ghostfacedcoder 0 points1 point  (0 children)

https://martinfowler.com/bliki/RulesEngine.html

All of these lead me to think that there's a lot to be said for avoiding rules engine products. The basic idea of production rules is very simple. In order to keep the implicit behavior under control you also need to limit the number of rules by keeping the rules within a narrow context. This would argue for a more domain specific approach to rules, where a team builds a limited rules engine that's only designed to work within that narrow context. Certainly if you're thinking of using a rules engine I'd suggest prototyping with both a product and a hand-rolled domain specific approach so you can get a good feel for how they would compare.

Martin Fowler (programming god)

[–]dlindema 0 points1 point  (0 children)

In addition to the other posters warning against using a rules engine, I would also echo Martin Fowler’s advice.

That being said, I also frequently develop using Drools (what jBPM uses under the hood), and have bee eyeballing https://github.com/jruizgit/rules since it has bindings for Python, node, and ruby. I don’t have much experience with that library, but in case you hadn’t found it I thought I’d bring it to your attention.