JsonLogic – Build complex rules, serialize them as JSON
jsonlogic.com
jsonlogic.com
https://github.com/json-schema/json-schema/wiki/switch-(v5-p... http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/jso... https://www.npmjs.com/package/lib-jsl http://jsonnet.org/language/design.html
Also when real programmers have to interact with those systems (and my practice shows, that business users don't want to program, they ask programmers to do it), it's so much pain to use those GUI languages or whatever and it's so easy just to write some code in sane language.
It's also a potential security risk - the downloaded script could perform things other than logic and so would require sandboxing/whitelisting of commands.
Putting logic in JSON avoids both of these issues since the actual handling of the logic is performed by a client-side library.
My point is that for the purpose of letting some non-trusted instructions run safely in a program, encoding them as JSON or Lua will come with the same caveats. Ultimately, they are both interpreted and can be sandboxed thus. Neither contain any code that will be passed off as-is for the CPU to execute. In some cases, neither does an ELF blob.
On the other hand, this language is bananas because the programmer is writing the AST and that is what a parser is supposed to do for him/her. Manually coding the AST is like harvesting an acre of corn by hand. If you can find a more inefficient method, then by all means use it.
And just for good measure, XML is not a "data description language", it is a type system; probably the most complex type system I've ever seen and it wasn't a bad idea, it was simply more complex than any application would ever need.
I don't dislike XML, and I think it will continue to live just like Haskell because every generation will come to understand that its extreme faith in generalization has little practical use just about the same time that a new generation first discovers it. So while one is dying to simplify, the other is dying to espouse the existential core of computer science.
XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains. Granted, you can mark up a bit of data with a type, but you can mark it up with anything else as well.
I've even seen entire programming languages built upon XML.
That could actually be a really fun language: "you can write this in Haskell-syntax, Python-syntax, or C-syntax, we don't care, just make sure that you enclose it in the corresponding
<parse-as lang="c">
// ...
</parse-as>
Sort of like the PL equivalent of Lennon's Imagine.
This is the belief that Eric Browne argued against in 2003[1]. "exactly a description of the data" only works when a human looks at it, which is the same argument for JSON. These two things "describe" the same object:
<person><firstname>Eric</firstname></person> { "person" : { "firstname":"Eric" } }
But using Browne's argument, a parser might see these objects as:
<hshhd><uueus>Eric</uueus></hshhd> { "hshhd" : { "uueus":"Eric" } }
How does that description help the parser?
What I'm saying is that XML is system for defining types, subtypes, relationships, etc. and that this type system can be used by programs that are written to interact with document instances in a way that is not dissimilar from other statically-typed languages. In a sense, you're agreeing when you say that XML has been used for programming languages because, in that case, a document instance might contain blocks of programming statements not instructions for a machine. It must be parsed and compiled first which takes some knowledge of the type system, i.e. how to create AST's and transform them into instructions.
I'm also saying that the problem with XML comes from the inability to reason about type systems in a general way. I can give you my XSD but will you know what to do with my data? And if I give you the XSD, and I tell you what to do with the data, then won't we writing the same program? Wouldn't it be easier to just share a library?
[1] http://workflow.healthbase.info/monographs/XML_myths_Browne....
Of course, that flexibility is what burdened us with SOAP, XBRL, and other monstrosities; but I blame the creators of SOAP, not XML. XML is the "C" of the data markup world (simple but flexible), whereas JSON is more akin to "Java" (heavily restricted in capability, resulting in workarounds to represent complex concepts).
{ "hshhd" : { "uueus":"Eric" } }
Unless it is Lisp s-expressions.
- html/xml has become the definitive declarative ui language since it generally acts exactly how we expect it
- css queries and xpath have been effective at providing a way to search a structured tree
- regexp hqve provided us a way to search or structure strings
I dont find it absurd to believe that there can be a language for transformations
https://dabernathy89.github.io/vue-query-builder/
I honestly didn't put too much thought into the actual structure of the JSON, so I wonder if there is someway I can now integrate JsonLogic into the query builder.
Good work!
Your schema, on the other hand, uses explicit node names and types, which should make automated analysis much simpler and less error-prone. The few changes I'd suggest are mostly just cosmetic: standardizing the schema (the type radio seems to imply the operator equals), renaming properties (why selectedOperator when just operator will do?), and maybe compressing levels where appropriate, for instance the query-builder-group could itself have the logicalOperator property.
(1) We have a similar sort of "expression language" at my job; in our case, the value it provides is ready access to the pseudo-AST we parse it into. We transform that AST at runtime (along with subexpression results) into a human-friendly error message like "Total Amount must be less than $X when Blah Mumble is under Y". The downside is that that "configuration" data now behaves more like code but doesn't have any of the tooling of the host language: we've had to add specific code to provide a stacktrace-equivalent hint about where expression evaluation failed.
(2) The bummer design decision in JsonLogic, IMO, is the leakage of the JS equality operator into what could have been a language-agnostic description. That's going to be nasty to implement elsewhere.
In complex enough domains DSLs can be key to tackle that complexity and they can take many forms.
The amount of salt in here from 1) Gross JSON! 2) why did you implement an AST?! is astounding.
All that being said, this is a really interesting approach and having a language for shared, declarative logic is often useful.
I think the target audience of JsonLogic is sharing code on the frontend/backend. I think these days javascript is common for that. A tiny lisp would be suitable as well.
There's a special place in hell reserved for people who make me edit ad-hoc turing complete configuration languages embedded in json or xml.
Edit: or were you referring to data rather than logic?
My approach however was to treat it as a literal syntax tree. we can represent trees reasonably well graphically, and if you connect the blocks sensibly you can make the visualization even flow well enough. Things start to decay past certain levels of depth; and I've addressed that with modularity. A tree can be "named" and become a single node within another tree. (yes yes rewriting programming languages badly or something).
Thus far the biggest problems I've had with this approach have been primarily just learning the words I need to use to search for the right concepts in web-UX space; I've actually been pretty damn happy with the view.
Tech wise, just a grid, jquery, bootstrap.
This does conditional formatting for a report designer. We thought a lot about how to limit the complexity the UI exposes and still have enough power to achieve most things people would need. We worked pretty closely with the customers to make sure it made sense to them (via mockups etc) before building anything.
Most (if not all) BaaS platforms have something like this:
- Firebase: Database Rules (https://firebase.google.com/docs/database/security/), Storage Rules (https://firebase.google.com/docs/storage/security/)
- Parse: Roles and ACLs (https://parseplatform.github.io//docs/js/guide/#roles)
- Horizon: http://horizon.io/docs/permissions/
- Couchbase Mobile: http://developer.couchbase.com/documentation/mobile/1.3/deve...
- Deepstream: https://deepstream.io/docs/server/valve-permissions/
When used for AuthN/Z, most seem to align with Role Based Access Control (RBAC), while others go for Attribute Based Access Control (ABAC). The former is generally easier to reason about and build, while the latter is more powerful though harder to build and explain.
Most IaaS IAM systems (like those in AWS [http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_po...], GCP [https://cloud.google.com/compute/docs/access/iam]) are RBAC, while BaaS solutions seem to trend to ABAC for schema validation + business logic.
Kubernetes also has a cool way of doing this: http://kubernetes.io/docs/admin/authorization/
Disclosure: I work on this at Firebase
If you want to make a different programming language that's fine. Data is code.
Maybe what you really want is a finite state machine? http://machina-js.org/
why groovy?
The problem is that it's almost entirely optimized for a machine to read, and not for a human.
Next thing you know, you've written something a little complex in this new format and realized it's pretty hard to maintain. So what should you do? Create a program to generate it, perhaps, from a higher level, easier to read, representation. In other words, a compiler.
That said, I'd argue this notation probably isn't a super concise representation for config over code. Implementing a JS evaluator so you could instead write "request.auth != null" and having JS like expressions is easier than the Prefix notation. Cool idea nonetheless!
For example, consider you have a stream of events that you need the user to be able to filter server side, such as all events that have a field of "name":"bob".
I will agree with you that these systems often increase in complexity until you have finally built a small language runtime. It can be difficult to distinguish where the descriptive language ends (eg binary operations) and the other begins ends and the other begins (eg sliding window, custom algorithms).
It has saved us hundreds if not thousands of man hours on something mission critical to the company, all while empowering the end users, giving my programmers more latitude to operate, and separating nicely the generic environment from the specifics that are irrelevant to it.
There are many ways to solve a problem, and the right one is highly context dependent. Dismissing something just on the basis of "we already have a way to express logic; it's called code" seems very narrow minded and not like the best way to produce solid engineering work.
I can also highly recommend Fowler's "Domain Specific Languages" book, which gives me the backing to say that I am far from alone in having success with that approach.
If I'm thinking what it is, the graphical editor/composer is what has saved you a lot of time, not the DSL. Your users likely are never touching the DSL, they are simply using your GUI application to build their use cases at that point. This is a common pattern that has nothing to do with DSLs; you just happen to target one as the intermediary format. It's important to understand this distinction.
But feel free to provide more details if this is not the case.
Yes, I could have embedded Lua or Python or JS and made them interact with an API that the environment exposes, but designing my own DSL let me make it a declarative affair, which greatly simplified things, as well as take various shortcuts in representing some abstractions that'd have been much more of a pain otherwise. This was in a CPU/memory bound environment, where the declarative, compact DSL approach (with all of the properties of the resulting program inferrable at parse time) turned out to work quite well. And generating that DSL is much more straightforward than generating code in a full scripting language.
The graphical editor was indeed a big reason for the success, and my users didn't interact with the DSL, but my developers did and it was much more straightforward for them than having to deal with lua/Python/etc. Ultimately we'd have still ended up with a DSL, albeit one represented in a programming language where 99% of the features are unused.
I'm not sure I get why you're so opposed to the notion altogether. Sure, there's plenty to quibble with if one so desires with OP's implementation in a vacuum, but perhaps consider that people just as experienced and knowledgeable as you have found value in the DSL approach over others for certain projects. If you're interested in diving more into it, check out Fowler's book.
It looks as a way to move business rules entirely to the backend, but still have the frontend executing them. I can see the value in that if you desperately need to reduce the load on your backend.
From the looks of it, I agree. It feels like an AST serialization format in JSON, but it's unclear whether it's optimized for any specific use cases or merely a toy implementation.
Turing complete markup-based DSLs have been created before - e.g. ant/maven/xslt - and in those cases it was a huge mistake to create an entirely new language that powerful.
If the DSL logic doesn't require a turing complete language - something much less powerful, it might be worth doing a DSL that has limited computational power.
IMHO this is a core principle underlies most computer languages: https://en.wikipedia.org/wiki/Rule_of_least_power
https://www.elastic.co/guide/en/elasticsearch/reference/mast...
Would be nice to have a COM port on smart phone.
What would THAT language be like?
Yep, it's come full circle!
This will be a perfect match for those kind of cases.
OK, I’m done shitting all over what’s probably a perfectly cromulent library now…
As the library itself, i would't touch this with a 100 foot pole. Serializing logic shatters encapsulation as well as cohesion, both cornerstone object oriented principles. Also, when you serialize logic, you leave yourself handicapped to fix code bugs, as your code bugs are now data bugs by definition. Imagine solving an off-by-one style error in persisted JSON logic. Your choices would be regex (shiver) or a script to parse all json blocks and modify accordingly? Yikes.
As an experiment, this is quite nice. Perhaps too nice. Given the quality of presentation, i feel bad for the shops that decide to adopt this into production usage.
Seriously, though, there's nothing wrong with using this for a presentation layer. Define a group of user-selectable client-side filters in a JSON constants document, which will have a much smaller "error surface" than defining custom filter functions. Just because it looks like JSON doesn't mean it necessarily needs to be serialized.
That said, there are a number of inefficiencies in the implementation. Certainly not production ready, but a great effort.
This seems to be an orthogonal architectural problem. If you need to be able to reprocess after changes to logic, chances are that you are storing your original source document somewhere and can retransform if necessary.
In my experience, folks writing code come to need a VCS ("oops, didn't mean to change that"), a debugger ("why did it do that?"), a test environment ("what happens if I change that"), and perhaps an audit trail ("who changed that?").
Set against that, the effort required to parse expressions is trivial.
Especially s-expressions.
would something like this help?
Probably OK on someone else's machine but not mine? :-p