JudgeJson - An Elixir rule engine where rules are json objects

Your Libraries & OS Mentoring Libraries
,
1

Links

Github: GitHub - dderooy/judge_json at v0.1.1-beta
HexDocs: JudgeJson — judge_json v0.1.1

Summary

JudgeJson is an Elixir rule engine where rules are json objects. The judge evaluates a json payload and sees if any rules match.

Rule = condition + action

JudgeJson is storage and action agnostic. Ideally you can store/load rules from a DB and evaluate on incoming json payloads. Handler code can then evaluate rules and action however you like.

Rule engines are great for separating business logic from execution logic.

This was also designed with gui form fills in mind. Longterm I’d like to see if I can get a dynamic phoenix form going to create new rules.

This is a beta release so please let me know if any ideas / improvements. Thanks!

Example

payload

{
    "data": {
        "person": {
            "name": "Lionel",
            "last_name": "Messi",
            "likes": [
                "soccer",
                "hot dogs",
                "sports"
            ]
        }
    },
    "rules": [
        {
            "id": "123456",
            "conditions": {
                "all": [
                    {
                        "path": "/person/name",
                        "operator": "equal",
                        "value": "Lionel"
                    },
                    {
                        "path": "/person/last_name",
                        "operator": "equal",
                        "value": "Messi"
                    },
                    {
                        "path": "/person/likes",
                        "operator": "contains",
                        "value": "soccer"
                    }
                ]
            },
            "action": "collect_signature.exs"
        }
    ]
}

iex> JudgeJson.evaluate(payload)

Returns a list of matched rules

3 Likes
2

Your example is not bad but can you give us a more complete example of what is this code achieving in a real business project?

3

Funnily enough, there’s a long history of rules engines used in the business world – probably why it’s often known as a business rules engine!

In addition to the examples above, there’s

  • targeted advertising based on user demographics
  • clinical recommendations/alerts based on patient information
  • awarding badges based on user activity e.g. discourse, stack overflow
1 Like
4

Yea rule engines have various purposes. I’ll admit they are probably overkill / out of scope for most hobby projects. At my work we have an in house engine that reacts to security alerts and its now the secret sauce of the biz.

A general design pattern:

  • collect / observe incoming data
  • evaluate against rules for any matches
  • trigger reactionary actions

Imo they fit really well with event hooks, event handling, and ETL flows. Generic webhook endpoint → rule match some condition → route / handle payload.

The main benefits:
You can change your business logic on the fly during runtime. Essentially hot swap your business logic without reloading an app or changing code. It also makes changes much more maintainable with faster turn around time.

Another understated benefit; you can isolate team and company concerns. One team / group can manage business rule CRUD lifecycle while another specialized dev team manages execution logic (action flows etc). This is a huge benefit imo - none coders can create new rules through a form gui and quickly change automation flows. Slap on some manager audit process for new rules and you have a self-serve process with no more Jira tickets for your dev team :wink:

5 Likes
5

Late to this party but have a need for a rule engine for my project and wondering if going this way has advantages over adding users to a database table. I have two use cases:

  1. Determine if each user has been given/assigned a golden ticket (today we keep in PostgreSQL db table: userId=user1, hasticket=true or false, Isregistered=true or false, date=datetime)
  2. Rule based scenario:
    Condition: If user1 is from department1 (we get from the user property) and has golden ticket,
    Action: Send congrats email and ask to register for factory tour.

Just wondering if it would be best to use the same rule engine like (judge_json) to do both or just keep it as simple DB query?

Thanks!