yolo007wizard
JudgeJson - An Elixir rule engine where rules are json objects
Links
Github: GitHub - dderooy/judge_json at v0.1.1-beta · GitHub
HexDocs: JudgeJson — judge_json v1.1.0
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
Most Liked
yolo007wizard
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 ![]()
codeanpeace
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
Popular in Announcing
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









