NRules maturity

[Thor Arne Johansen]

Hello,

We are looking into .Net rules frameworks for our product and found NRules. We plan to use NRules to handle payments and invoice generation based on rules created dynamically in code.

From the docs it looks quite interesting and appear to have a solid design and architecture, but we have a couple of questions regarding its maturity.

* Can you share whether or not NRules is used in production today? 

* Would you recommend using it in production?

* What are the main issues or features missing wrt. production readiness?

* Will you accept pull requests?

--

Thor A. Johansen

Oppad AS

[Sergiy Nikolayev]

Hi Thor,

Let me give you some background on how NRules came to being, Throughout my career, I worked on several different rules-based systems that are currently actively used in production. For various reasons I couldn't just opensource that work, but, at the same time, I noticed a glaring gap in the open source community - lack of a developer-centric open source .NET rules engine. So, I started this project with a goal to close that gap.

Answering your direct question - I have not used NRules in production myself, but judging from the questions on this forum, some people did. And, as I mentioned, there are closed source rules engines of my writing that are used in production.

I would recommend using NRules in production if you are willing to accept the risk of being one of the first adopters, and if you are willing to work with me to close any gaps you may find.

I will accept and welcome pull requests if you work with me to make sure what you are trying to do fits the architectural and design principles that I set for this project.

Regarding production readiness and missing features. This obviously highly depends on how you are going to use the engine, but I'll try to answer the best I can.

• First-order logic - currently NRules supports everything except universal quantifier, which is coming up in the next release roughly within the next month. Also, the engine currently does not support grouping condition with the OR operator, which is also coming up in the next release. Other than that, full support for fact assert/update/retract, existential and negative quantifiers, forward chaining.
• No support for backward chaining (and likely not going to support it in the nearest future).
• No support for injecting parameters into rules. But if you are going to generate rules at runtime, this should be irrelevant to you.
• No external DSL (i.e. rules language). Again, if you are going to generate rules at runtime - not relevant.
• Diagnostics, logging, tracing, etc. The engine deliberately does not log anything, nor does it produce any tracing. It raises events and lets you take care of the diagnostics in a way that is suitable for your application. This may be the area where real production experience with the engine highlights some gaps, but I'm certain those can be addressed pretty quickly.
• Stability - performance, memory leaks, memory footprint. I'm fairly confident the engine is solid from this perspective. I spent quite a lot of effort profiling both performance and memory usage.
• Functional correctness - it's been tested for a wide range of use cases, but mainly through the Fluent API that sits on top of rule builder API, and is more limiting than the rules builder. So, if you use rules builder to the full extent, there is risk you may find issues for some exotic use cases. But I'm also certain these can be identified and fixed quickly.

High-level roadmap is:

• Release full support for the first-order logic, stabilize that release and announce version 1.0.0
• Add support for temporal facts and implement complex event processing
• Build a rules language on top of the engine

To summarize, if you decide to use NRules for your project, you are accepting some risk of being one of the first adopters. It's also currently just me running the project in my spare time. Nevertheless, I can guarantee you one thing - that I'm committed to continuing investing into this project.

Let me know you have any further questions.

Sergiy Nikolayev 

[Thor Arne Johansen]

Thank you for taking the time to provide such a comprehensive answer.

We are certainly looking forward to exploring how NRules can be utilized in our project.

When you mention that an external DSL is missing, do you mean a way to author rules without writing c# code? (As the class based rules could also be considered a fluent based DSL, right?)

Also, do you have any long-term plans to turn this into a commercial product?

[Sergiy Nikolayev]

Great, let me know if I can answer anything else. And, as you explore, please share your feedback, so that I can improve the engine and fix any shortcomings.

Regarding external DSL, yes, I mean a language that's not C# (though it will probably use a subset of C# for actual conditions and actions). Class-based fluent DSL that comes with NRules right now is what I consider internal DSL, since rules are written in the same language as the rules engine itself.

Regarding turning into a commercial product, my position is that the core of the engine (that is, the execution engine, canonical model and internal DSL) will always remain open source and free (as in free beer).

I can hypothetically see myself building commercial products on top of that core (i.e. IDE integration, external language, execution server, etc), but to be honest I don't have any specific plans yet.

[Michael Shmalko]

Hi Sergiy,

Would you be able to provide more information on performance of the NRules engine. In particular, I am interested in how performance degrades with increase of number of rules.

Thank you,

Michael