|
|
|
|
|
by fomojola
1854 days 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). |
|