Show HN: JSONScript – Asynchronous scripting language using JSON format (opens in new tab)

I also prefer writing code to DSLs etc. Unfortunately, just writing code doesn't solve the problems mentioned here: https://github.com/JSONScript/jsonscript#problem

Sending code in some existing general purpose or scripting language makes it either difficult/inefficient to parse, or insecure (if, e.g. JavaScript or bash eval is used), or both. Limited privileges only partially protect the host and usually leave some vulnerabilities...

JSONScript is both very easy and efficient to parse (a JSON-Schema is used to evaluate the script) and it is secure because it executes the script in a "sandbox" having access only to those system resources that the host environment explicitly exposed to the interpreter.

My two main use cases are 1) scripted processing on top of existing API (implemented) and 2) proxy allowing scripted processing across multiple APIs in the same location (soon).

Agreed.

I agree that this isn't an SOA architecture. I see this more like an SQL stored procedure where you want to get simple code closer to the data for performance and efficiency.

I would like to see some use case thoughts about where this would work better than other alternatives.

It's out of stock - https://www.amazon.co.uk/Service-Oriented-Architecture-Conce...

Joking aside, why do you think it is any more untestable than any other batch endpoint out there? The concerns you are listing are all valid and can be addressed.

That's good to know that it was done before with JSON, I've only seen XML attempts. It probably shows that there is a need, doesn't it?

Syntax is a matter of opinion, JSONScript seems more concise than REL in the link.

Thanks for the comparison.

JSON-RPC allows simple batching but it doesn't allow any server side logic between calls. Individual calls to external instructions in JSONScript are indeed similar.

The full syntax can be used if you need to evaluate some of the fields, it's also easier to parse. Short syntax is implemented as a macro - it's expanded to full syntax before evolution. Given that it in most cases short syntax is better I was going to hide full syntax a bit...

It's funny that I've always been annoyed myself that I need to click around to find the language sample all the time, and yet I've put all the examples on the Langauge page (http://www.json-script.com/language.html). Thank you for the suggestion, I will add some example to the home page.

Added script example to the home page: http://www.json-script.com/

Indeed :) Self- documented is always better. Unfortunately, it's easy to add though :)

Really hoping that was sarcasm...

Redis's implementation of Lua is extremely limited, and even then there is no easy way to validate the script apart from sending to the server. JSONScript can be simply validated against the JSON-schema, no execution is required to check it's validity. I see this solution as server-side script processing on top of existing REST API(s), as I wrote below. Using Lua for this purpose is possible I guess; but I want the solution that is easy to implement, extend and maintain. And I am happy to write and maintain this code; whether it's "spaghetti" depends on the way it is written, as for all languages.

Many people use YAML instead of JSON by the way - a bit fewer characters.

Sorry, whats the moral of this story?

Funny story indeed :)

That is indeed a valid concern. I thought about an option to limit the evaluation time and the memory used. Although I don't think it's possible at the moment to request something that would cause an endless loop. There are no loops (yet), it can only iterate arrays (can be large, but limited), and I did not plan to support recursive function calls. Denial of service is also a valid concern when you handle individual requests (although the solutions for it exist).

You know that feeling you get when a series of completely sensible choices in themselves have somehow led you to a point that - if you could step back and take in the whole picture - would strike you so very clearly as a rather bizarre place to end up...

It's very late here and I'm tired so I can't come up with anything especially constructive but something doesn't feel right about this.

Thank you. YAML will look more like plain text and still will be easy to parse.

I don't think the intention is to "increase the amount of code" but that's what always ends up happening! You're definitely on to something here with JSONScript but it's missing "something". That killer feature that immediately indicates to the developer/end user, "Yeah, that could definitely make my life easier."

I've implemented something similar with my own projects in the past and I think others have and ultimately will as well. "What problem causes us all to ultimately implement something like JSONScript or JSON RPC?"

I think there's two problems and I think JSONScript went a bit too far/got too specific as to how to solve them:

    1) How to specify (multiple) destinations when delivering API requests and their order of execution.
    2) How to execute actions safely despite potentially dangerous payloads.

I suggest removing the "path" part as it can easily be included in the top level of the object (e.g. {"someapp: destination": "payload here"}. I also suggest removing the "get" and "put" nomenclature. That's so old fashioned and synchronous :) . Shouldn't such things be determined by the destination functions?

Interesting indeed. Thank you.