JsonLogic

by sebmellen • 5 years ago

223 249 5 years ago

millerm• 5 years ago

Seems like a really silly lisp with string operators and is incredibly hard to read when not trivial. This will probably be the first and last time I ever ask this question, but why not just use something like clojurescript?

eevilspock3• 5 years ago

Thank you. I'm going to take a look at this for the project I mentioned in my other comment.

sebmellen21• 5 years ago

I’m trying to define a matrix for the conditions under which a given “credential” can be accepted/is valid. The goal is to embed that matrix within the credential schema itself, such that it’s almost self-verifying, depending on the context of the credential’s usage/presentation. (A bit hard to explain without diagrams.)

Using JSON to do this would allow schema portability throughout the different languages in our stack, but of course it’s an imperfect solution. Open to hearing any other options (I have looked into YAML as well but that’s a whole other ball of wax)...

mixedCase3• 5 years ago

S-expressions do all of this, which is why everyone is suggesting you've reinvented Lisp. They're trivial to parse and easier to read than JSON for this use case.

renewiltord• 5 years ago

I might be misunderstanding, of course, but would you be able to use the JSON protobuf serializers and just define your conditions as Protocol Buffers?

Might be heavyweight.

joshlemer5• 5 years ago

ClojureScript does not complete in a deterministic amount of time, on account of it being a turing-complete programming language.

eevilspock3• 5 years ago

Essentially JSON s-expressions.

I'm doing something similar in a side-project of mine as a temporary stop-gap to avoid writing (or generating) a parser for a proper s-expression syntax.

ktpsns• 5 years ago

And this is how LISP is invented.

Any sufficiently complicated program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. (Greenspun's tenth rule)

adamkl2• 5 years ago

Here’s some great instructions on how to use JSON to do just that:

https://stopa.io/post/265

joshlemer5• 5 years ago

Are there any competing dialects of Lisp which have deterministic runtime? If people are reimplementing half of Common Lisp, then they are not implementing something that competes with this project because their language is probably turing complete. From the JsonLogic website:

JsonLogic has no setters, no loops, no functions or gotos. One rule leads to one decision, with no side effects and deterministic computation time.

pydry4• 5 years ago

It's Turing incomplete. Like HTML.

LISP is, on the other hand, a programming language. It's rather famous for it.

mbrodersen• 5 years ago

I have been programming for 40+ years and have never ever seen this in practice. And I am the kind of guy who have implemented my own Lisp more than once. Just for fun. However I would never use it in my day job.

code-is-code• 5 years ago

I also did this some year ago. A big learning was that you should define the allowed input types in the logic object.

https://github.com/pubkey/secure-json-logic#readme

sebmellen21• 5 years ago

Thanks for the input. I submitted this because I’m looking around for ways to define a matrix for accepting a given “credential” within the schema of the credential itself — a bit hard to explain without getting into it. This is the best model I’ve found so far to do what I’m trying to do, but it’s still very imperfect.

IshKebab3• 5 years ago

Ha they heard of "truthy" and "false" but apparently stopped reading before "... are a really really terrible idea!".

mcphage6• 5 years ago

What's terrible about truthy and falsy? How do you even have a language without a definition of what is truthy and what is falsy?

coldtea3• 5 years ago

There are several languages that only allow booleans in such comparisons.

There you can't do e.g. a bare:

  if (a)

for things that e.g. in C/Java etc would be "truphy" (like 0, null, etc). Instead you need to do:

  if (a != null)

(that is, check with an expression that returns an actual boolean true or false, not anything truthy/falsy that "coerces" to true/false).

In the same way, where in Python you'd do:

  a = ""
  if not a:
     print "this will be printed"

there you'd do it like:

  if not (a == "") -- or if not a.isEmpty():
    ...

or some such.

IshKebab3• 5 years ago

What's terrible about truthy and falsy?

Basically it's very error prone. It's difficult to remember the rules which are usually quite complicated which leads to mistakes.

Much better just to be explicit.

How do you even have a language without a definition of what is truthy and what is falsy?

You make it so that `if` only works on `bool` types, and don't implicitly convert other types to `bool`. For example if you want to check if string is non-empty, then you have to do `if (the_string != "") {` rather than `if (the_string) {`, which may cause your code to unexpectedly fail if e.g. the string is "false".

telekid• 5 years ago

That's a strange lisp...

A few other strategies for solving this problem include something along the lines of the Small Clojure Interpreter (1) and Defunctionalization (2, 3)

[1] https://github.com/borkdude/sci

[2] https://blog.sigplan.org/2019/12/30/defunctionalization-ever...

[3] https://www.cis.upenn.edu/~plclub/blog/2020-05-15-Defunction...

joshlemer5• 5 years ago

The difference between this and a full lisp like Clojure is that this must be turing-incomplete. From the description:

JsonLogic has no setters, no loops, no functions or gotos. One rule leads to one decision, with no side effects and deterministic computation time.

Also it appears that sci is still experimental: "Experimental. Breaking changes are expected to happen at this phase. "

rauhl2• 5 years ago

The difference between this and a full lisp like Clojure is that this must be turing-incomplete.

Sure, but one could still implement a Turin-incomplete language in S-expressions. It would be more readable and more succinct, too.

kemitchell• 5 years ago

This has been independently reinvented countless times, in countless languages. Would be nice to get a somewhat generalized standard in place.

TeMPOraL2• 5 years ago

It's called, "use a Lisp, dammit!".

Seriously. There are Lisp languages that could replace whatever language you're using, and, there are also Lisp languages/runtimes that you could embed in whatever language you're using, to avoid rewriting it from scratch like this.

skybrian3• 5 years ago

Which lisp though? There are still too many choices.

The fact that people say "use a lisp" instead of "use Lisp X like everyone else" should tell you something.

It's like the difference between "use SQL" and "use SQLite" or "use Postgres."

bob10292• 5 years ago

We do something almost like this, but we didn't try to invent any of the hard bits. We serialize our domain instances into JSON documents which also happen to contain the business rules as in-line SQL properties, and then project this JSON document into SQL databases as required for evaluating business logic.

Ephemeral, in-memory instances of SQLite can be incredibly powerful tools for building an extensible business logic engine.

idolaspecus2• 5 years ago

Could you expand on this idea a bit more? My curiosity has been piqued, but I'm not sure I really understand the system you've described.

mplanchard• 5 years ago

We built a rust version of this that provides a Python package via CFFI and a node package via WASM, because we found that the different implementations for different languages were pretty buggy and would sometimes resolve expressions differently. Also the original project in JS seems to be largely unmaintained. The rust version goes to great lengths to reimplement weird JS typecasting so as to be fully compatible with the original.

https://github.com/Bestowinc/json-logic-rs

I am currently working on an extension to add functions and more strongly typed operators to avoid the hassle of JS’ type conversion. That extension will probably be released as a separate package, because I am no longer with Bestow.

sebmellen21• 5 years ago

Wow, awesome. Thank you! Just the kind of thing I’m looking for :)

goodpoint3• 5 years ago

rust version of this that provides a Python package via CFFI and a node package via WASM

I honestly thought it was parody around the unnecessary complexity of modern software.

rendall3• 5 years ago

For some reason, this project seems to be drawing rather nasty comments. I'd like to remind everyone of the guidelines:

Be kind. Don't be snarky...

Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

commandlinefan2• 5 years ago

"This is a bad idea" is neither nasty nor snarky.

kvnhn• 5 years ago

It is, however, a shallow dismissal.

rendall3• 5 years ago

Non-sequitur. While true, it has zero to do with what I wrote.

rendall3• 5 years ago

sebmellen, I looked at its repo and it's just the license? Am I missing something?

sebmellen21• 5 years ago

Just to be clear — not my project, but I’m trying to use this or something like it. I found it pretty compelling though also somewhat lacking, and HN is a great place to get more discussion and maybe read about some alternatives :)

joshlemer5• 5 years ago

A lot of shallow, smug snark coming into the comments section from people who know what s-expressions are and I guess want to brag about that for some reason. S expressions are cool but that's just _a syntax_, there are other possible syntaxes for expressions, and it's perfectly fine that somebody chooses to embed a language in JSON rather than s-expressions. Everyone suggesting to use Scheme or Clojure or Common Lisp and dropping the meme-quote that everyone eventually reimplements Lisp are missing the fact that this language is designed to be evaluated deterministically, so it does not support looping or functions and is Turing-Incomplete, unlike Clojure/Scheme/CommonLisp.

whalesalad• 5 years ago

Ultimately it’s all data. The difference between this and lisp is just a bunch of extra characters and noise in the stream.

What is really the meaningful difference between this and an s-expression language? “” and {}, really. It’s a different way to serialize the same thing.

So I’d argue a lot of the criticism is valid.

We do, as an industry, tend to run in circles.

sebmellen21• 5 years ago

The most important difference to me is that this is usable within already extant JSON Schemas that can be patched up or added to.

pydry4• 5 years ago

What is really the meaningful difference between this and an s-expression language?

Turing completeness.

So I’d argue a lot of the criticism is valid.

I'd argue they should have paid more attention in college. This is far from a superficial difference.

You might as well call HTML a programming language. Seriously.

forgotmypw17• 5 years ago

I think it's just a natural law that information tends to "crystallize" into certain patterns, and we're just the implementors of those repeating patterns. :)

athrowaway3z• 5 years ago

I remember years ago when i first came to hackernews there was a project very similar to this. An engineer blog proud of the AST they encoded as JSON.

I had only a vague idea of what an AST was, but the highest upvoted comment was clearly saying: This is dumb, we have dedicated formats for turning text into ASTs. ( i.e. a programming language ).

In the past decade+? i have learned what an AST is and have now twice, in a professional setting, prevented an engineer from re-inventing this very concept.

If i had to choose if hackernews is a place where smug snark comments crack down on re-inventing known concepts or a happy place where every idea is a good one i will choose the former.

And once every blue moon we get to laugh and look back at snarky comments such as this: https://news.ycombinator.com/item?id=9224

brundolf3• 5 years ago

The difference is the collection of extremely powerful parsers, tooling, language support, etc that already exist for this syntax. There's a proper Content-Type header, blazing-fast native parsing in web apps, you could store it directly in MongoDB or the like without an extra serialization/parse step, you could query it with jq. Heck, you could statically-check these expressions using TypeScript.

Lispers are always pointing out how the parenthesis-and-whitespace notation is just incidental; how s-expressions are really something deeper that isn't bound to a specific syntax, and how this is a strength. The OP is a demonstration of that strength.

joshuamorton• 5 years ago

https://github.com/joshuamorton/tidbits/blob/master/lispy.py...

yongjik• 5 years ago

I think comparison to s-expressions are a red herring. In Lisp, I guess, s-expressions are an integral part of how you code. As a piece of general code, it can be great or terrible. This "JsonLogic" thing is explicitly intended to be "logic-inside-configuration" because (I hope) nobody's writing program with JsonLogic. Unfortunately, logic inside configuration is almost always a bad idea. (It doesn't matter whether you're using json or xml or s-expressions.)

brundolf3• 5 years ago

Don't most of the problems with "logic-inside-configuration" come from turing-completeness? This spec has neither control-flow nor reusable functions (recursion); it's nothing but simple expressions. That seems safe to me.

tgbugs• 5 years ago

They may be shallow comments, but they have a point. JSON is fundamentally unsuitable for anything numerical for a variety of reasons [0]. Thus, it actually can't ever even get to the point of being a suitable replacement for expressions in the languages you listed. Most web tech has insidious anti-intellectual designed baked in, and the end result is that people end up rolling their own mutually incompatible bespoke solutions to problems that were solved before the web was even a glimmer in the eyes of the advertising industry.

0. https://stackoverflow.com/questions/1423081/json-left-out-in...

shawnz• 5 years ago

With s-expressions where that functionality is simply not provided as part of the underlying syntax at all, then every solution is a mutually incompatible bespoke solution. You could just use all string values in JSON and get the same effect.

ironmagma• 5 years ago

Most web tech has insidious anti-intellectual designed baked in

Citation? I don’t know many people who would call Brendan Eich anti-intellectual for instance.

eevilspock3• 5 years ago

Here's the thing: I implemented exactly this for a side project where I needed users to be able to express simple logic for custom data handling rules. Here are some examples:

    level = new Expression(['map', ['char', ['tail', 2], 0], {'=': 1, '-': 2}]) 
    body = new Expression(['parse', ['trim', ['body']]])
    name = new Expression(['replace', ['trim', ['body', 1]], /[ \t\r\n]+/, ' '])
    target = new Expression(['first', ['body', 2], ['body', 3], ''])

The arg to `new Expression` is a Javascript object (i.e. can be sourced from JSON). The first element in each nested array is a function name/operator. It was absolutely trivial to implement. All the functions are implemented in a few lines of code within cases of a switch statement, and nested expressions are handled recursively.

For me this is just a temporary throwaway solution while I work on other more critical stuff first. I will replace it with an s-expression based DSL later. Like JSONLogic, it won't be Turing complete.

It just seems to me that JSONLogic is making a huge deal for what's really just a small reusable library.

karmakaze• 5 years ago

I was all set to not like this. Without even getting into the depths of it I can tell I misjudged it from the name.

JsonLogic has no setters, no loops, no functions or gotos. One rule leads to one decision, with no side effects and deterministic computation time.

It's like eBPF for applications!

The fact that it use JSON instead of your favorite serialization format isn't the thing to be talking about.

geuis• 5 years ago

Could someone explain why this or similar projects are useful?

coldtea3• 5 years ago

For defining (and allowing users to touch) more powerful than static configuration and/or business logic, that you don't want to be turing complete.

fomojola• 5 years ago

It is a DSL for additional logic that can be: - Stored in your existing data store (assuming your data store can store a string) - Executed without eval() or any other potentially dangerous method - Executed in bounded time

You think of things like Lua in Redis: this is one take on a not-quite-as-capable alternative for logic that can be safely executed in restricted environments (barring errors in the implementation of the parser).

There will be editing/verification requirements: writing any moderately complex logic structure without a designer/test evaluator would be a nightmare, but as a generic way to specify/embed custom logic in a system that is language independent, has effectively no additional parser requirements (given that just about every single language has a JSON parser that is probably already in use in your project) it isn't a completely bad look. S-expression parsers do exist, but I'd wager many more people are familiar with the JSON parser in their language than the S-expression parser available in their language.

I will say: it isn't complete. It lacks clarity about the behavior in the face of missing/invalid operation arguments. Something like

    {"<" : ["ham", 42]}

I'd assume would throw an evaluation exception of some kind, but that should be clear in the spec.

The playground at https://jsonlogic.com/play.html is a start, but before you try handing this to a non-developer, you'd really want a visual editor with node folding of some kind (so you can hide deeply nested structures away while you work on other things), variable completion (so you specify a sample data object and if you're typing in a variable you get completion options) and operator parameter verification (to stop you from writing in incorrect/unsupported values based on the operator).

ar-nelson• 5 years ago

I've been trying to invent a JSON-Lisp language like this for a long time. My first attempt was Jaspr (https://github.com/ar-nelson/jaspr), which has its own syntax that compiles to JSON. But I'm working on a new, Turing-incomplete variant called MiniJaspr that fills a similar niche to config languages like Jsonnet or Dhall.

beaconstudios• 5 years ago

if you're wanting to reuse the same logic on both backend and frontend, you can just use JS on the frontend and backend and pull your functions/utilities in from a shared library - either a git submodule, private NPM package or (my preference) have all three running inside a yarn workspaces monorepo.

dvt• 5 years ago

This is a fun project and a cute reinvention of Lisp, as people have already mentioned. I think people are snarky because if this was just a fun project, that would be the end of it. But it seems like JsonLogic is trying to be an actual thing.

And this latter point is why it's just a monumentally terrible idea. I mean.. just look at the Custom Operations wiki[1]. It's honestly just horrible -- horrible -- and may actually even summon Zalgo[2]. This is exactly how we ended up with the XML nightmare of the late 90s/early 2000s. JSON is not meant to be programmable. Please, for the love of all that is holy, stop.

[1] https://github.com/jwadhams/json-logic-js/wiki/Custom-Operat...

[2] https://stackoverflow.com/a/1732454/243613

vesinisa• 5 years ago

Please, for the love of all that is holy, stop.

Yes! Oh my god, this. I remember how XML ended up being abused to express Turing complete logic in too many instances. Then they even specified an XML format to transform other XML documents, called XSLT, which is itself Turing complete. It really makes my head hurt.

I think why people gravitated away from XML was because it had become a convoluted mess. The JSON specification is terse on purpose, famously enough so to fit on a business card. If you want to abuse JSON to express logic, please keep it as your dirty little secret.

nitwit005• 5 years ago

The moderator's note on #2 adds a lot to the amusement.

ctoth• 5 years ago

This project reminds me quite a bit of [0] which I'm currently using to write rules to parse tags from Openstreetmap. Having a standard way to share expressions does seem quite useful, especially when it's multilingual.

[0] https://github.com/google/cel-spec

sebmellen21• 5 years ago

Very nice, had not heard of this before. I will take a close and careful look.

dan-robertson• 5 years ago

This sort of rule language you can put in configs is often useful. They tend to eventually cause problems as logic that should have been implemented properly gets embedded in the mini language and the little rules get more and more complicated (or even auto-generated from a simpler specification), but they are invaluable while they do work.

One thing that surprised me was the inclusion of map/reduce/cat. Allowing these operators can make runtime exponential in the size of the program. I feel like that is against the spirit of the language.

mcphage6• 5 years ago

I don't understand why they represent it as a object with a single key, whose value is an array:

- If it's an object, then nothing is going to enforce there only being one key.

- If it's a unary operator, then the value doesn't need to be wrapped in an array, but then how does it distinguish between an unary operator, whose operand is an array, vs. an n-ary operator?

Both of these problems would be solved by having each clause be an array, with the first value being the operator, and the rest of the operands being the parameters. That way having multiple operators isn't even syntactically possible, and having multiple operands is just as simple as the unary operand case.

flying_sheep• 5 years ago

IMHO coding logic in JSON is similar to puzzle game. I would recommend to use jq instead.

spankalee• 5 years ago

I think avoiding a parser by using JSON is kind of neat, but it really isn't that difficult to write a parser for a small expression language and you get the benefit that you can expose a much nicer syntax to end users with the same parser - rather than having an standard AST and need a parser anyway to have decent UX.

I work on and off on a very simple syntax language for things like templates, but would be well suited towards business rules and such too. It was the first parser I wrote outside of school and pretty easy to understand, small and fast too: https://www.npmjs.com/package/jexpr

ivan888• 5 years ago

Probably the biggest benefit of using something like JSON is the fact that you can safely and easily generate dynamic code without having to worry about different quirks of the particular grammar

weatherlight• 5 years ago

man, I implemented a rules engine library where i expressed, the rules as S-Expressions (basically a lisp) that mapped to ruby lambdas. that way when finance would come back and be like, "what was the logic and the rules at a given point of time, I could point to what the rule was, what was it configuration, and who changed the configuration or the rule." and the rule execution strategy. It works, I'm proud of it, the lisp layer is completely abstracted away from the developers and the users who configur ed the rule.

I thought I was so clever :) Apparently, engineers have a habit of doing this.

ardit33• 5 years ago

And the circle of life continues! I have seen exactly this method in 2004-2006 but with XML.

If you are reading this, and you think it is a good idea, please don't follow it as it is not.

Back in 2006-2009 I worked at MobiTV, which we had the same exact way/method of programing our mobile apps, on J2ME/feature phones. The made up language was called CEF which was based on XML. While the idea is sound in paper, This turns really fast into an ugly, debug everywhere type of scenario, where it is hard to both develop and debug properly.

The only way this is ok, is when you have some fully automated UI tool, that stores some kind of state, and retrieves it back, but with no human intervention and some very very limited logic. Otherwise you are in a world of pain. If you try to include real application logic into something like this it is going to hurt your business long term.

It will turn your business logic like some Maven configuration, full of gotchas and more.

jchw3• 5 years ago

I am not saying that you are wrong. Not at all.

However, something I’ve come to learn is that some ideas I thought were bad were actually not bad. They were poorly executed and the exact reasoning why they did not work well in a given application was not well-understood.

So I can see an argument for “this was horrible back when it was done in the early 2000s” simultaneously with “this could actually still be a good idea for some use cases.”

janderland• 5 years ago

Currently reading about agriculture throughout human history. It made me wonder how many people failed to domesticate a single kind of crop and assumed crop domestication as a whole isn’t a good idea.

I realize that people need to make decisions based on their personal experience, and I don’t have a good rule-of-thumb for when to try a variation of a “bad” idea.

valenterry6• 5 years ago

Sharing code between frontend and backend isn't a bad idea, yes. However, using Json for it is. And the problems and limitations with json can't be "fixed" in any way.

healsjnr1• 5 years ago

I think the key point on this is `some use cases`.

For people who've spent a lot of time with ANT, you might be familiar with this article from its creator: https://web.archive.org/web/20041217023752///x180.net/Journa...

It was possible and even made sense to use XML as the format for a build tool, however, it got stretched way to far. The idea was applied in use cases that were less and less appropraite, as a result years later you end up with something that is unwieldy and doesn't make sense and, generally, thought of as "terrible".

There are use cases were JsonLogic might make a lot of sense, and for those that is great.

Generally, I'm sceptical as there is high risk of increasing couplings in a way that will make change much harder. This will be particularly true if it is applied to use cases that don't truly warrent this kind of solution.

enriquto2• 5 years ago

exactly this method in 2004-2006 but with XML.

Of course! JSON is the modern equivalent of XML. In 10 years everybody will mock JSON just like today we mock XML.

juped• 5 years ago

JSON mania has given me an appreciation for XML not having been so bad after all.

fastball4• 5 years ago

I dunno, for me JSON will always be better than XML due to it just being nicer to read / work with.

Pxtl2• 5 years ago

People mock JSON today. No comments, hideous multiline strings, and weak schema support.

theamk2• 5 years ago

The problem is XML is _markup_ language and it was forced into data serialization -- hence endless mocks and people hating it.

There are people who actually use JSON for markup... the resulting schemas are usually very bad, and they disappear quickly without even gaining fraction.

When used properly -- XML for markup, JSON for serialization -- each format is pretty nice, and will probably last forever.

sebmellen21• 5 years ago

Maybe you can tell me if there's a better solution. I'm open to hearing any options because I'm at a loss of how to do this otherwise:

Say we have a schema which defines certain data. Let's say it's a "credential" which is a "COVID-19 Back to Work Credential." The credential is valid in the case that someone either 1) has a COVID vaccination or 2) has a negative COVID test in the past 72 hours. That data might look like this:

  {
    "credentialName": "COVID-19 Back to Work Credential",
    "credentialIssuer": "Acme Labs Inc.",
    "credentialData": {
      "rapidSarsCov2PCRTest": {
        "hasTestResult": true,
        "testResult": "negative",
        "testTime": 1622145851
      },
      "covid19Vaccination": {
        "hasVaccination": false
      }
    }
  }

Now, say I want to define the conditions under which this "credential" is valid or invalid, but I want to include this "matrix" within the schema (not any business logic, just matrix logic that pertains to the data within the schema itself).

Optimally, I'd be able to do this within the same schema or file.

With JsonLogic, that might look like this (probably flawed logic, just a demo, not using this in production, may cause your computer to go up in flames, etc.):

  {
    ...

    "parsingMatrix": {
      "if": [
        {
          "or": [
            {
              "===": [
                { "var": "credentialData.rapidSarsCov2PCRTest.testResult" },
                "negative"
              ]
            },
            {
              "===": [
                { "var": "credentialData.covid19Vaccination.hasVaccination" },
                true
              ]
            }
          ]
        },
        "valid",
        "invalid"
      ]
    }
  }

Can you think of another way to do this that doesn't rely on using JsonLogic or something like it (or a cleaner method for doing it in JSON)?

asah3• 5 years ago

I'm not sure how to express how much I loathe everything about this "solution."

To answer your question, what you have is (effectively) code, and just use a programming language for this, call it a function, give it a name, arguments, test suite and register it as a plugin to your platform. Oh, and documentation, change history, etc.

Seriously - the "overhead" more than pays for itself when 100 other yahoos do this nonsense and you end up with data files containing untestable code that breaks when combined with other code, breaks when the platform is changed, etc etc

goto114• 5 years ago

How about representing the logic as a JavaScript expression:

    (credentialData.rapidSarsCov2PCRTest.testResult==='negative')
      || credentialData.covid19Vaccination.hasVaccination) 
          ? 'valid' : 'invalid'

Seem easier to read and maintain to me.

0xFACEFEED3• 5 years ago

Straw man.

With all due respect, you're making a classic mistake: presenting the solution to a problem without tracing the problem back to the use case.

Why do you need to include the logic matrix in the schema? I can promise you that the real world use cases where you'd need to this are virtually non-existent. You wouldn't even do this for some extreme case like Mars rover software.

Your business logic should have a single source of truth. The vast majority of the time you can just write an API for other software to synchronize with.

Otherwise just ship new builds of your software package to the client instead of a new schema. If you need to be modular then use modular primitives such as shared libraries.

Again, there's virtually no real world scenario where you need to ship a logic schema (in any format) to a client. You might as well ship a shared library, importable module, a completely new binary, etc, etc.

contravariant2• 5 years ago

What about:

    ["if", ["or", ["===", ["var", "credentialData.rapidSarsCov2PCRTest.testResult"  ], "negative"],
                  ["===", ["var", "credentialData.covid19Vaccination.hasVaccination"],  true     ] ],
           "valid",
           "invalid"]

?

mmcdermott• 5 years ago

Clojure Spec works really well for this sort of thing. It doesn't serialize to JSON, but it would be able to check for it.

You could also think about Dhall as a front-end. You could represent the whole credential as a union type. This isn't deeply thought out, but this should give an idea as to how this would look:

    let TestResult = < Positive | Negative >

    let ScreeningTestDetails =
          { hasTestResult : Bool, testResult : TestResult, testTime : Natural }

    let CredentialData =
          < Vaccinated | RapidSarsCov2PCRTest : ScreeningTestDetails >

    let Credential =
          { credentialName : Text
          , credentialIssuer : Text
          , credentialData : CredentialData
          }

    let result
        : Credential
        = { credentialName = "COVID-19 Back to Work Credential"
          , credentialIssuer = "Acme Labs Inc."
          , credentialData = CredentialData.Vaccinated
          }

    let result2
        : Credential
        = { credentialName = "COVID-19 Back to Work Credential"
          , credentialIssuer = "Acme Labs Inc."
          , credentialData =
              CredentialData.RapidSarsCov2PCRTest
                { hasTestResult = True
                , testResult = TestResult.Negative
                , testTime = 1622145851
                }
          }

     let prop0 =
      λ(x : ScreeningTestDetails) →
        assert : greaterThan x.testTime 1522145851 ≡ True


    in  result2

Notice here that the type for credential data can only be vaccinated or a test result. It can't even represent unvaccinated. You could probably take it farther with dependent types and assertions.

Edit: added an assertion to model the 72 hour requirement.

shaunxcode2• 5 years ago

I cant help but imagine what it would like like in EDN:

    {... 
     parsingMatrix
     (if (or (=== (var "credentialData.rapidSarsCov2PCRTest.testresult")
                  "negative")
             (=== (var "credentialData.covid19Vaccination.hasVaccination")
                  true))
         "valid"
         "invalid")}

rauhl2• 5 years ago

Can you think of another way to do this that doesn't rely on using JsonLogic or something like it (or a cleaner method for doing it in JSON)?

This strikes me as nice:

    (parsing-matrix
     (if (or (= (var "credentialData" "rapidSarsCov2PCRTest" "testResult") "negative")
             (= (var "credentialData" "covid19Vaccination" "hasVaccination") "negative"))
         "valid"
         "invalid"))

nanis• 5 years ago

With JsonLogic, that might look like this

Here is the thing...There is already a crappy way to describe JSON Schemas[1,2].

It is hard to grok by visual inspection and expressing conditions like "this element can either be a list containing a subset of these values or a hash with keys that belong to the same set" etc make it unwieldy.

The schema ends up being really brittle and hard to modify. 100% green-lit test coverage don't mean a thing when it is soooo easy to end up with a false negative.

Now take that and add logic to it? One has to question the existence of all the programming languages in use if we are going to end up subjecting ourselves to that torture.

[1] https://json-schema.org/ [2]: https://json-schema.org/draft/2020-12/json-schema-core.html

pydry4• 5 years ago

It sounds like your language didn't steer clear of Turing completeness.

That's usually how this type of thing goes wrong. I've seen similar things both work and fail for that reason.

This language made it an explicit goal, though.

marktolson• 5 years ago

I have successfully implemented this exact project in the past. The project allowed for runtime logic modification however tracking states was built into the platform to make debugging simple. As with every other library or framework, JsonLogic is a great tool if you implement it responsibly.

commandlinefan2• 5 years ago

If you are reading this, and you think it is a good idea

I came to the comment section here hoping that the site was actually a joke...

solidsnack9000• 5 years ago

Maybe it's a kind of having your cake and eating it too: enjoying the flexibility of passing code around and running it with eval, while not having the security, stability and runtime problems implied by eval.

There are limited scopes in which this can work but it seems to be more about the environment or code loader than about the programming language, per se: for example, plugin systems for build tools and servers. The plugin might be isolated by runtime features (like in the JVM) or by processes (as some web servers do, or as Postgres does) but it's not language features that tend to be useful.

Tensorflow models and CSS selectors are both examples of fairly useful plugins that still have limited enough semantics to be sandboxed effectively.

rhacker• 5 years ago

LOL, I am just going to leave this here, but to those that complain about JSON or XML or any future format X: It's always going to be shitty, messy and hard to read. You can only do so much to get rid of extraneous symbols but at the end of the day the format is hard to read because there is hierarchy and repetition. It seems like everyone is waiting for a format that will make reading 2000 configurations "easy". I'll have to say, good luck.

noduerme• 5 years ago

I agree that there's basically never a good use case for shipping logic from server to client or vice versa in a formal application setting. BUT. I could definitely see a scenario where something like this would be handy for farming distributed processing out to naive nodes or workers that don't / shouldn't have access to the core logic.

Too• 5 years ago

One valid use case for solutions like this is if users are allowed to run their queries inside a database or api.

I'm often in the situation where you try to add all kinds of parameters to a query-field in the UI but no matter how hard you try there will always be a power user with the request to do some combination of AND/OR/CONTAINS/NOT with nested parenthesis that is not supported.

After hundred such requests you get sick of it and just want to expose the raw DB-query to the front end, which obviously is a bad idea for security reasons. Having a safe intermediate representation that is sophisticated enough for some logic can be a good idea. Instead of reinventing your own, using this language can be done, as long as it has a mapping into each database query language.

smitty1e3• 5 years ago

there will always be a power user with the request to do some combination of AND/OR/CONTAINS/NOT with nested parenthesis that is not supported.

If that power user is properly skilled, authorized and authenticated, why not give them a read-only connection to the DB and let them write their own SQL?

How many times has the UI been nothing but an impediment?

oreally• 5 years ago

Precisely. If you want to do logic, use a programming language, not a data format.

arthurcolle2• 5 years ago

Not sure why this is getting so much hate, I think it's pretty cute. Can't really imagine when I'd use it, but i like it.

papito2• 5 years ago

Imagine trying to configure rules in a CMS without touching code. I work at a place that does it. They may... be using this.

laurent123456• 5 years ago

Hmm... unversioned, untestable code saved in a database. What could go wrong.

jsd1982• 5 years ago

The logo is pretty clever

diegoholiveira• 5 years ago

I did a rules engine to the company that I work based in this specification, but using go language. It is a very successful project because our clients can create rules without tech people around in our frontend, it's very easy to translate our rules into json and store it.

I even did a library to implement it in go language: https://github.com/diegoholiveira/jsonlogic

lloydatkinson• 5 years ago

Is this a recent project? Anything using that ancient theme looks... ancient.

closeparen• 5 years ago

We are quite successfully using Starlark for an embeddable, executable config language. For example, I can take a Starlark expression at the command line and use it to filter elements of a collection.

https://github.com/bazelbuild/starlark

karambir• 5 years ago

We used this at an early version of ad-network where Advertisers would write JsonLogic against a set of user properties with all the operators. And this was checked at runtime when ad was to be shown. At the time, I thought this was a neat and quick way to give advertisers some form of targeting. We had ~500 active ad campaigns at any given time(not much growth beyond that) and this worked really great.

But I always thought there should be better way for this kind of application. I see a lot of comments about Lisp. My question is: Is Lisp better for above scenario or there is even better way?

natn• 5 years ago

I built something like this once for defining form validation rules. It was fun. I was very proud of it. I'd probably just use JSONSchema now though.

sheminusminus• 5 years ago

At Routable we use this to power a significant portion of our dynamic UI (super complex forms with interwoven dependencies, etc). Super cool and useful library with a surprisingly low number of gotchas for what it's doing.

We did a little write-up about our experience with it here if anybody is interested:

https://blog.routable.com/tablematic-a-tale-of-server-driven...

sebmellen21• 5 years ago

Thank you, this kind of real-world experience and feedback is exactly what I was looking for when making this post! I will take a read through that blog :).

remram2• 5 years ago

What is the advantage of this being JSON? Couldn't the language be more "terse, consistent, secure, and flexible" if it wasn't JSON, with the possible advantage of parsing faster and being friendlier to write?

The website lists the ability to easily send it "between front-end and back-end code, and even store it in a database", is there an advantage to it being JSON for any of these goals?

pjerem• 5 years ago

We blindly use JSON for everything because one day, someone discovered that JavaScript embedded a JSON parser called eval(). Yup, that’s where our civilization is.

skybrian3• 5 years ago

Programmers are already familiar with the surface syntax, including gotchas like only having doubles.

Also, the logic can be embedded in an already-existing JSON file.

This is useful if you occasionally need to look at the file, but usually you don't, so it's not worth putting any more effort into nice tooling.

dec0dedab0de• 5 years ago

I can see using this for writing validators that can be written once, then ran on the api and frontend. I'm struggling to think of another use.

ekimekim• 5 years ago

The niche that immediately came to mind when I saw this was allowing a user to specify a filter expression for some query, either as a simple text-based language or using some sort of UI (with drop-downs and such). Having a well-established spec with existing libraries for turning these kinds of expressions into an AST for transfer, storage, execution later, etc is valuable. I've definitely implemented a simplified, domain-specific version of this kind of thing in various projects over the years.

brundolf3• 5 years ago

Mapbox's API has something similar, except they use the first element in an array for the operator instead of an object key: https://docs.mapbox.com/mapbox-gl-js/style-spec/expressions/

Some will recognize that these are basically just Lisp s-expressions (as JsonLogic also seems to pretty much be)

"Code as data" indeed

daenz• 5 years ago

Like wasm, the idea of portable logic is interesting.

Unlike wasm, this is the wrong vehicle for it. And this implementation's very-limited nature means that anyone who buys into it will need to rip it out when the limited logic inevitably doesn't scale with the rest of their applications.

forgetfulness• 5 years ago

Since you can't expand rules into any other rules, yes, it's pretty restricted. Kind of a feature though.

rubyist5eva• 5 years ago

I worked at a marketing company and we had a targeting engine that was basically this, but not as elegant. Will give this a try this weekend and see how it compares in practice, cool project.

codeulike• 5 years ago

https://en.wikipedia.org/wiki/Inner-platform_effect

That said, I think everything has uses in some circumstances; there are no rules in software that are beyond debate

erulabs• 5 years ago

Probably not appropriate for a large poly-glot organization, but I really like creating shared JS libraries that can be used in the browser and also in Node.js apps. For game development, having the game logic in a shared library makes server-side validation and client-side prediction really easy and prevents code duplication.

I'm sure there is some reason it's all a horrible idea but almost all my projects these days use React front-ends and Node.js back-ends and a shared library used by both, ideally containing most of the complex logic. This seems like a neat version of that that might be useful in an organization which uses many different languages.

orasis• 5 years ago

This is almost always a bad idea. It’s best to find a way to use a full blown programming language for these types of customization.

shadeslayer_• 5 years ago

Not to be that guy but didn't we agree about moving business all business logic into a single place, back in 2012?

atatatat• 5 years ago

What if I use this as a read-only API of sorts for sending regular reports from a Blazor app db to legacy systems?

asah3• 5 years ago

please no. just no.

asah3• 5 years ago

please no. just no.

"Logic" is lazy word for "code" and we saw what happened when Excel "macros" grew up into major applications.

To be safe under maintenance, safe vs security, etc code needs at least these things: - source control - docs (and ideally, examples) - tests (and ideally, CI)

alex7o• 5 years ago

Can I ask why do we need to embed lisp in JSON, can't we just serialise our lisp to JSON?

bww• 5 years ago

The idea of representing an expression as an abstract syntax tree for interchange is not an inherently bad idea. Trying to shoehorn a general purpose data interchange format into a highly specialized application like that is a common anti-pattern, however.

When I see this sort of thing (which I assume was inspired by MongoDB's own atrocious "query language") I'm always surprised by the fact that many engineers don't seem to be aware of how easy it is to write a parser that is actually designed for the data you're trying to represent. At least "easy" in the context of undertaking a project that is attempting to generalize this exact problem.

JSON is a fine interchange format until you need a specialized runtime to evaluate the data, which is what is happening here. At that point there's zero benefit to using a general purpose interchange format just because it already exists: just write a DSL.

A good place to start: https://www.antlr.org/

imoverclocked• 5 years ago

I get it. I do ... it still rubs me the wrong way because:

1) You are leveraging a JSON parser to get strings 2) The strings contain tokens that need to be "parsed" 3) You turn this double-parse into an AST

I see this pattern all too often. If you create (or re-use an existing) grammar that is specific to the problem domain then you get a much faster parse, smaller data transfer/storage, and a more human-readable format.

mmaug• 5 years ago

Congrats! You've invented a verbose version of LISP...

gloryless• 5 years ago

There are a ton of scenarios where this would be useful. Not everything has to be the new paradigm shift. It's just a tool

lootsauce• 5 years ago

There are legitimate uses for such things. We are currently implementing a processing rules configurator UI and backend that must ultimately be executed in sql. It must support arbitrary nested boolean logic and comparison expressions. Last time we did this we ended up developing a custom data structure for the front-end and a custom printer for the sql output. This is a standardized version of solving just that problem.

My question is if not a solution like this how then SHOULD I be implementing communication of such rules from the frontend to the backend?

garren• 5 years ago

It reminds me of this [0] post from a few months back which implements something more or less similar using js arrays as a kind of sexp.

I’m working with a system that relies extensively on logic implemented as json structures. We’re not using this lib, I found it to be difficult to follow and more difficult to debug. Ymmv, but I’d definitely think hard before leaning on something like this.

[0] https://stopa.io/post/265

devit• 5 years ago

That seems worse than using the common C/Java/JavaScript syntax for operators and function calls, that can be easily parsed with any JavaScript parser.

Lapsa• 5 years ago

eval("temp < 110 && pie.filling == 'apple'")

nsonha• 5 years ago

it's only a matter of time before you are called gatekeeper because "json is a programming language"

I remember when I was an university student thinking writing java in XML (Spring) was cool. Man I was dumb.

AcerbicZero• 5 years ago

I am firmly on team “anything but YAML” so perhaps I’ll give this a try next chance I get.

nikolay• 5 years ago

So, pretty much everything we've done in XML is now available in JSON. Wasn't the purpose of JSON supposed to be getting rid of XML's complexity?! Same with JavaScript - it was supposed to be a dynamic typing language, now most of the serious code migrated to the type safer TypeScript. We just keep going in circles and wasting so much energy! This is not progress; it literally is chasing our own tail!

chrismorgan• 5 years ago

The one thing that’s bugging me about this is the particular JSON structures employed. They’ve gone for this:

  {"*operator*": [...args]}

With one special case:

  {"*operator*": single_arg}

(This special case confirms that JsonLogic isn’t using arrays as a top-level construct, otherwise it’d be ambiguous. Well, it confirms either that or that it’s even worse-designed than it looks. Anyway, I’m going to assume arrays are free to use as a top-level construct.)

In short, you end up using an object and an array for each element. Yet the object is strictly being used as a two-tuple, and objects are a roundly bad idea for this application: the only way you’re ever going to be looking at it is “it’s an object, confirm that it has only one pair in it, then pull the first key out, and pull its value out”. This is quite inefficient in both memory and runtime performance. The only thing it really has going for it is that it guarantees that the key is a string, which is significantly overrated given the other more expensive bits of validation and access costs that it forces.

So the whole thing would be made more efficient (and arguably even more robust) by just changing it to an two-element array:

  ["*operator*", [...args]]
  ["*operator*", single_arg]

And then the natural next step is to say “why are we using two arrays rather than just one?” and flatten it into this:

  ["*operator*", ...args]

This is conveniently shorter to type, and eliminates the nasty single-argument special case too.

That’s very probably going to be more efficient on fixed-arity operators (which is most of them) and on potentially-unary operators, though it’s possible that it may be more expensive on larger calls if you need to slice the array during evaluation in order to exclude the operator.

So the end result I’ve suggested here is simpler, more consistent, smaller on the wire and in memory, faster, more robust across diverse languages and environments—in short, superior in pretty much every way. The only real place it might not be superior is auto-formatting, where you lose probable separation of arguments from operator (subjectively often desirable) but reduce the indentation level by one (more strongly desirable). It’s also more S-expressiony!

Seb-C3• 5 years ago

I've been there, done (Something like) that and I'd rather duplicate code than doing this ever again.

wyqydsyq• 5 years ago

If you’re looking for a way to share logic between front-end and back-end code

So... exactly like isomorphic/universal JavaScript?

What exactly is the practical benefit in this, compared to say, JS functions shared by serialising them as strings or by abstracting them into a common dependency package which can be ran both on front-end and back-end?

justsomeuser• 5 years ago

I think I would rather just let the logic-writer user use JS directly, and then verify the AST only uses certain language features.

This way you can ensure the code is a subset of JS (the same subset of JSON-Logic), whilst using all the tools and runtimes of JS.

ashneo76• 5 years ago

Uhh.. json doesn't have comments. There is no code readability in here. If you are trying to represent code in data, night as well go use a language for that.

This is still a cool project. It issues a lot of effort to build something like this.

But I wouldn't use it for production until this has been around for a while and json gets comments.

hmmx32• 5 years ago

Looks like a lisp

hmmx32• 5 years ago

Looks like lisp

JsonLogic

Related Stories