Synchronous run about json-rules-engine HOT 3 CLOSED

@CacheControl makes totally sense. Thank you so much for the answer, it was totally a question not a need of having a synchronous run.

About the syntactic part, I don't think it's a problem, but it could mislead assumptions like rules are ran asynchronously, when the only thing that may be async is getting the facts in case they are dynamic, and the rest of it is completely sync. Plus, obviously the Promise handling that may end up having some impact in performance too.

Again, thanks for taking the time, and anyways I'm open to help in case it's needed.
Have a nice day!

from json-rules-engine.

@ivanetchart Can you help me understand the desire for a synchronous run()? What would that enable?

from json-rules-engine.

Also, to answer your question as to why the promise based interface exists, there are several reasons, primary of which is related to dynamic facts. Although some users of json-rules-engine will exclusively use constant facts, others have more complex requirements which necessitate loading data on the fly for both performance and practical reasons. Having a single promise based interface for all users allows the engine to support all use cases.

While not having a synchronous run() may be slightly annoying from a syntactic standpoint, having a consistent interface regardless of the way rules and facts are configured is paramount. Finally, asynchronous programming is a core fundamental of the javascript language, and as pointed out in the other issue, language improvements like async/await have considerably reduced the cognitive load of asynchronous interfaces; I really don't see it as a major inhibitor.

Glad you're enjoying the library!

from json-rules-engine.