Re:JsonLogic – Build complex rules, serialize them as JSON
by asciimike on Monday October 24, 2016 @10:48PM
(#12784876)
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.
[ Parent
| on HN ]
Re:JsonLogic – Build complex rules, serialize them as JSON
by andrewstuart2 on Monday October 24, 2016 @11:03PM
(#12784942)
This is code. Instructions codified into a machine-readable format. It's just really verbose and complex code. It reads almost exactly like Polish notation [1], assembly code, an abstract syntax tree. Except encapsulated in JSON trees rather than space-separated lists.
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.
Re:JsonLogic – Build complex rules, serialize them as JSON
by asciimike on Monday October 24, 2016 @11:28PM
(#12785055)
I don't think I ever said it wasn't code, I said it wasn't "backend code". We've exchanged some config (sure, basically an AST) for writing some express/django/rails middleware. I'd much rather check authentication status by writing "{"!=", [request.auth, null]}" than writing more backend code, especially if someone else has done a bunch of the work for me.
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!
Re:JsonLogic – Build complex rules, serialize them as JSON
by inopinatus on Monday October 24, 2016 @11:05PM
(#12784947)
All configuration is programming. Glib but true. It's practically axiomatic. And it follows immediately that all configuration can be represented by code. Learning that it should be is a matter of experience.