Adding computation to a data description language is always a bad idea. I've seen this done with XML. XSLT is a great example of why this sucks. This has been done with JSON before anyway. Here are several examples:
Okay, first of all, the current fascination with JSON is not fundamentally different from the previous fascination with XML. The only thing that anyone can agree on is that JSON is easy to parse just like its predecessor. This is why XSLT came into existence: firstly, it was easy to parse, secondly, ..., thirdly, profit (i.e. reuse, generalization, performance, etc. etc. etc.).
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.
I agree. This really makes me think of XSLT and all of the horrors that go along with it in real world usage. Maybe I'm not seeing the bigger picture but I don't really know how/where JsonLogic would be used and why it would be a better alternative than a programming language. Are there any examples that might clear it up for me? The linked site is documentation for the language but it's not helping me understand the need for this project.
Why is it always a bad idea? For example there can be content that is triggered by rules and these rules need to be edited by non-programmers. Furthermore these rules need to be evaluate in different execution contexts (in our case in Android and iOS) This is a situation that requires describing simple logic alongside data.
I see a lot of folks who are a lot smarter than me crapping on this, but I think it could be really useful. I've thought about the problem before of how to share complex rules between front-end and back-end safely, and came up with a UI for it:
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.
I would suggest that, at first glance, your structure is actually preferable for most applications where this would be useful. The real advantage of a DSL is when it provides a concise way to solve a specific problem domain. The OP just provides a verbose way to describe a general problem domain, without any benefit of regularization.
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.
So, a JSON AST. The whole point of programming languages is to give you something better than an AST to work with. Code is already data and we have functions for evaluating/compiling/interpreting said data natively/in-vms/in-interpreters.
People still make them. Because, you know, "everyone can use them" and they are "simple". In reality, only software developers are able to do anything with such a crap DSL and it takes a lot more effort and workarounds to get anything done vs a sane programming language.
Is there a security statement about this? I don't immediately see any dangerous operations, but code sharing should always be suspect. If this catches on, it won't be long before someone asks for something that would open vulnerabilities.
All that being said, this is a really interesting approach and having a language for shared, declarative logic is often useful.
Looking over the examples, I thought of MongoDB's aggregation pipeline. You pass in a similar tree of JSON-only logic to perform more complex database operations/transformations. In Mongo's case, the idea is to have direct access to "native" calls, skipping Javascript execution altogether.
These mini-languages almost always become really painful to work with. If I find myself needing to implement some sort of configurable shared thing more complex than a table of regular expressions I just jump straight to the endgame and embed lua or a lisp.
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.
I believe that eventually software development may move in general to structured serializations rather than plain text. The main thing holding that back is just that programming is defined by cryptic colored text and they are afraid they won't look technical enough if they don't stick to that. I am a programmer myself btw and of course I use text editors.
Pretty cool. Coincidentally I just spent the last couple days implementing configurable JSON-serialized rules in our app. The bigger part of the challenge for us was coming up with a human-friendly UI for defining the rules.
Been considering the same problem here - how to allow some sort of user-defined rules/ logic flow? The UI is indeed more difficult to (well) do than the data representation of said rules. Anything you can share?
When you're building a serverless framework with the goal of direct client access to managed infrastructure without writing server side code, rules languages like this are an awesome tool to have. You need to: authenticate users, authorize their actions, validate schema, ensure referential integrity, and perform business logic checks.
Most (if not all) BaaS platforms have something like this:
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.
I recently implemented a DSL for an environment that I wrote for a fairly niche purpose, accompanied with a graphical application to build "programs" in that DSL, because my users are non programmers that need to express domain specific logic.
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.
Code is fine in a trusted environment, however sometimes you need to give another process/user/actor a limited environment. You could give them a limited run time environment, however that is often difficult
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).
I've worked on a service that did something like this, except everything was passed through a middleman who was managing a bunch of live-reloading Groovy code where the actual business logic was stored. Would this have been a better approach? Maybe! But at the very least its an interesting idea and even if interesting ideas fail they might serve to inspire something new. I don't see a reason to be openly hostile just because it's a "DSL".
Sure, but what if you're building a serverless framework or other multi-tenant system and the goal is for an external developer to not write backend code? You need a compact way to represent and evaluate authentication and authorization, maintain schema or referential integrity, or do simple business logic checks.
ElasticSearch new Painless scripting language is a secure lava-like DSL language which is a superset to just logic. Although it seems to be jvm opinionated.
We built a system, where user can construct complex search criteria and submitted for result.
We were passing the criteria using a custom dsl (lot of coding in front-end to construct and parsing logic in back-end).
This will be a perfect match for those kind of cases.
I don't understand... Why just dont get all the complex logic from server/client, generate a .js with it and use in server/send to client? Why JSON?
JSON is not designed for this.
[+] [-] jcoffland|9 years ago|reply
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
[+] [-] keithb-|9 years ago|reply
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.
[+] [-] cabalamat|9 years ago|reply
Unless it is Lisp s-expressions.
[+] [-] Corrado|9 years ago|reply
[+] [-] dirtyaura|9 years ago|reply
[+] [-] formula1|9 years ago|reply
- 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
[+] [-] userbinator|9 years ago|reply
[+] [-] dabernathy89|9 years ago|reply
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!
[+] [-] couchand|9 years ago|reply
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.
[+] [-] foota|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] al2o3cr|9 years ago|reply
(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.
[+] [-] banachtarski|9 years ago|reply
[+] [-] SloughFeg|9 years ago|reply
[+] [-] virtualized|9 years ago|reply
[+] [-] ctvo|9 years ago|reply
The amount of salt in here from 1) Gross JSON! 2) why did you implement an AST?! is astounding.
[+] [-] emilong|9 years ago|reply
All that being said, this is a really interesting approach and having a language for shared, declarative logic is often useful.
[+] [-] pkghost|9 years ago|reply
[+] [-] michaelcampbell|9 years ago|reply
[+] [-] fbreduc|9 years ago|reply
[+] [-] fiatpandas|9 years ago|reply
[+] [-] shanemhansen|9 years ago|reply
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.
[+] [-] ilaksh|9 years ago|reply
[+] [-] Zecc|9 years ago|reply
Edit: or were you referring to data rather than logic?
[+] [-] eschutte2|9 years ago|reply
[+] [-] asciimike|9 years ago|reply
[+] [-] thom_nic|9 years ago|reply
[+] [-] dabernathy89|9 years ago|reply
[+] [-] asciimike|9 years ago|reply
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
[+] [-] sandGorgon|9 years ago|reply
[+] [-] iamleppert|9 years ago|reply
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/
[+] [-] GuiA|9 years ago|reply
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.
http://martinfowler.com/bliki/DomainSpecificLanguage.html
[+] [-] ta834939874|9 years ago|reply
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).
[+] [-] ng12|9 years ago|reply
[+] [-] asciimike|9 years ago|reply
[+] [-] itaifrenkel|9 years ago|reply
https://www.elastic.co/guide/en/elasticsearch/reference/mast...
[+] [-] donpdonp|9 years ago|reply
[+] [-] bbcbasic|9 years ago|reply
What would THAT language be like?
[+] [-] Liron|9 years ago|reply
[+] [-] ckarthik17|9 years ago|reply
This will be a perfect match for those kind of cases.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] chukye|9 years ago|reply