How to store and process rules and logic with JsonLogic
Have you ever tried to implement some sort of data structure for storing or transferring a set of rules ? It is usually what happens when you’re asked to create some sort of interface for the user to create queries or such directives with drag&drop ing or simply selecting from appropriate options. A decade ago , it wasn’t considered so impractical to build such tools from scratch , just to wait for the user to deem them useless and throw them away.
Most popular and familiar ones must be the SQL query builders and “detailed filter query” builders for about any specific product. The general idea is to identify the “valid operands” and the parameters that can be applied to said operands. And this is what JsonLogic does: but in a very familiar way and a perfectly battle-tested data structure.
“Build complex rules, serialize them as JSON, share them between front-end and back-end” is how the home page for JsonLogic starts describing the library. 1–2 years ago I was looking for a way to store and process rules for a RestFUL API based BPM product we are developing, for using the structure for the workflow processing, and instead of making the mistake of creating one from scratch , i simply googled “json logic” and found the obvious match !
A foreword for anyone hoping to use JsonLogic in production environment: It’s not a well-known entity and there’s no organization behind it , but the main idea is so intuitive that it just keeps giving. And anyone can easily add to the project as they see any lacking feature.
Structure
Everything is explained a lot better on the home page but I will try to go on with what I want to point out. There are two parameters to use for an outcome : rule and data. Data is any simply JSON Object, and rule is always in the form of {“operand”:[value1,value2….]}
Above is an example from the home page : a compound rule , two rules combined with an and operand that is . In jsonLogic , every json object needs to evaluate to some result, till there’s a final result.
There are many operands and the whole set can be considered rich. There are the simple operands like “<” ,“>” and “==” , and more complex array operands like “map”,”reduce” and “filter”, and string operands like “cat” and “substr”. And on top of all , you can extend it with your own operands, if you’re using the javascript parser.
Something a little tricky is that , the final result does not have to be a boolean result. Because some operands are able to output other types of values , and some decently written drivers(“wink wink”) take care and notice of that. There are operands like “var” , “missing” and “merge” , that might return any type of object. So , for example, on the java driver, the rule and data evaluate to a Result object and you can simply call the different types as `Result.asBoolean()` , `Result.asInteger()` and such.
There are drivers , actually parsers , available in JavaScript , Ruby, Python and PHP linked from the home page but you can find many other implementations on github. I personally forked and extended the work of someone on Java driver , as it was lacking most of the operands and there is still work that’s needed to be done. I tried to contact the creator , for listing the Java parser on the home page as well , but no luck so far.
Performance
We have been using JsonLogic (with java parser) on our new product for over a year now and have been evaluating tens of thousands rules daily, without any performance problems. Even though there was not much to worry about , to begin with. If you have any inconsistency problems , I advise you to just check the implementation you’re using first. We had serious problems with the python parser in the beginning.
Bonus
While trying to make JsonLogic even more user (or developer?) friendly, a colleague of mine coded a drag&drop editor for creating json logic rules , based on blocks. You can find it on GitHUB as well.
