
Show HN: JSONScript – Asynchronous scripting language using JSON format - epoberezkin
http://www.json-script.com/
======
prawnsalad
Feels very similar to JSON RPC.

This isn't a script at all but a way to call an RPC method. And over a non
duplex connection at that.

I often use something very similar with a few additions to support callbacks.
Add an ID field so that responses can be matched and you suddenly support
calls being made over a duplex connection such as Websocket or TCP connection;

Shorthand and longhand formats complicate things so stick with one type. The
whole $ prefixed params are also un-needed, especially if your'e expecting
them and have the important values under your own expected keys anyway.

But then after all this you start turning into json-rpc.

~~~
epoberezkin
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...

~~~
epoberezkin
Re '$', there is no expectation on the location of the script instructions in
the object structure, unlike JSON RPC. So it is used to differentiate
instructions from simple data structures that can be part of the script.

------
fallenshell
This exact concept has been done multiple times. And it never worked, because
the syntax was horrible. And it's just not convenient at all, it's good for
toying around with interpreters and the likes but it has no purpose or use.
See
[https://m.reddit.com/r/coding/comments/3akmn1/sums_this_rel_...](https://m.reddit.com/r/coding/comments/3akmn1/sums_this_rel_thing_up_pretty_well/)

~~~
epoberezkin
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.

~~~
macspoofing
>That's good to know that it was done before with JSON, I've only seen XML
attempts.

Both approaches are similarly flawed, but XML would actually work much better
for what you're trying to do with JSON - and much more readable.

~~~
epoberezkin
I've seen several XML based scripting implementations. This one for example:
[http://www.drdobbs.com/web-development/jelly-an-xml-based-
sc...](http://www.drdobbs.com/web-development/jelly-an-xml-based-scripting-
language/184405386)

I may have got used to the syntax I came up with, but all XML based scripts
seem more verbose and less readable. I guess, each to its own...

------
ingenter
This reminds me of my multiple attempts in writing a declarative scrapper
framework. In the end, I've chosen to just write the code.

What I see is a crappy ad-hoc scripting language. I feel bad saying so, but I
can only view this project as a bad solution to whatever problem you have.

You could have chosen to send actual code, be it JavaScript, Python, Java or
even Linux binaries, executed with limited privileges. How would that look
like? AWS Lambda.

~~~
epoberezkin
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](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).

~~~
woah
I still don't understand how this has any security advantages over just
sending code. You are sending code, just shoehorning it into a serialization
format.

~~~
epoberezkin
The difference is that general purpose programming languages usually provide
full access to the host environment, they are not designed to be received from
untrusted environments.

You need to reduce what is allowed, and that is more likely to leave
vulnerabilities, than explicitly whitelisting what methods can be called.

I think that any abstraction/DSL, not JSONScript specifically, with a
specialised interpreter on the server side is more likely to be secure than
processing general purpose language instructions received from the client.

------
secoif
Why do many language home pages not show a single sample of the language?

~~~
epoberezkin
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](http://www.json-
script.com/language.html)). Thank you for the suggestion, I will add some
example to the home page.

------
NelsonMinar
Finally, a programming language that frees me from the possibility of writing
comments!

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

------
tony-allan
I like the problem you are trying to solve and I like the idea of the JSON
data structure but I am not so keen on the language as JSON. I find it hard to
read, which would be worse in more complex real-world examples.

I guess I would like to see the code as plain text. Packaging all the data to
send as JSON is OK, and the code could be text in a single JSON data element.

Post a story to Hacker News once you get some experience using JSONScript with
some feedback on how you went and how the idea evolves.

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

------
alttab
This technique never ends well. When your service interface is some untestible
semi-script language your clients will hate you.

Nice work on building an interpreter, but I'd throw the entire SOA book at you
for deploying this in a production environment. I haven't even addressed
stability, latency and load of programmable Web interfaces, or security.

~~~
tony-allan
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.

~~~
epoberezkin
Thank you. One use case that's already working is an express middleware -
allows you to bold on JSONScript on existing express ap in a single line of
code. Another is a proxy to manage batch processing across multiple services -
going to make it.

------
epoberezkin
You can use it via the middleware for Express to implement advanced batch
processing in a single line of code.
[https://github.com/JSONScript/jsonscript-
express](https://github.com/JSONScript/jsonscript-express)

------
macspoofing
I think it's a cool proof of concept and you tried out a bunch of ideas that
could work, but I don't think you should use this approach for anything. JSON
is not conducive for encapsulating complex logic, and it shows. Who is going
to write and maintain that spaghetti code? Anyway, code execution at the
datasource, is not a new problem, and there are approaches to solving it.
Redis for example allows you to upload and execute Lua scripts at the source -
way easier, way more readable, makes infinitely more sense. So why not use Lua
or just use JavaScript - since your front-end code is all JavaScript anyway?

~~~
epoberezkin
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.

------
epoberezkin
Thanks for all the comments, some are really useful. JSONScript is an
interesting experiment and the time will show whether it's useful and whether
we use it. What I find really interesting is why most higher level
abstractions that reduce the amount of code to be written polarise normally
friendly people to such extent, and "just writing code" is seen as the only
"sane" choice. On the other hand, tools that increase the amount of code are
usually very welcome. Any idea why it is happening?

~~~
riskable
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?

------
jiyinyiyong
If you write it all in arrays, then you can reuse Cirru's text syntax and
would look shorter, hope you are interested:
[http://cirru.org](http://cirru.org)

~~~
epoberezkin
Interesting indeed. Thank you.

------
woah
I know this thread is dead at this point, and any rational argument is
probably lost on the author, epoberezkin, but this has made me think of BobX:

[http://thedailywtf.com/articles/Classic-WTF-We-Use-
BobX](http://thedailywtf.com/articles/Classic-WTF-We-Use-BobX)

The scariest part is that epoberezkin has mentioned using this new innovative
language at his job. I hope someone stops him.

~~~
gajus
Sorry, whats the moral of this story?

------
_nalply
How to prevent Denial of Service? For example when a customer sends an
infinite loop to the server?

~~~
epoberezkin
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).

~~~
MawNicker
GraphQL has similar problems. It seems somewhat inherent to batching
solutions.

~~~
epoberezkin
Interesting. I saw GraphQL; I thought that given that it's query language it
won't have this problem... Although if you'd exposed SQL it would have been
super easy to kill the server. I am about to start using JSONScript for
internal apps/services we have, where DoS is not a concern. For the public
usage it needs some improvements to implement the limits I mentioned.

~~~
MawNicker
I should have said the _implementations_ of GraphQL have similar problems.
Since it's just a query language you _can_ implement your own server with
limits. Facebook is ultimately just punting on this problem but the
declarative query boundary is helpful. Your DSL is much more imperative.
You're in a _very_ practical niche between individual ad-hoc endpoints and a
completely new way of doing things (GraphQL). Especially for use with existing
systems. There are a lot of people out there (at least one) who just want
batching and don't need a new abstraction. They know exactly what requests
they want made; They just want them to be made on the server. That being said
I think you should change your presentation. The thing that's "not right about
this", as mentioned in another comment, is that it seems to be a programming
language and not a web development tool. It is a programming language but
that's incidental to it being a web development tool. I think your scope is in
danger of creeping towards a turing-complete homo-iconic scripting language
based in _JSON_. There _is_ something not right about that. Lol. It's a
scripting language with syntax derived from the object literals of another
scripting language which was in turn syntactically perverted in order to
attract the users of non-scripting languages. It's an abominable version of
lisp.

~~~
epoberezkin
Lol. Thanks for the suggestion about presenting it, I need to think about it.
"A niche between individual endpoints and completely new way of doing things,
batching without new abstraction" \- seems like a good way to position it
indeed.

------
epoberezkin
I'm working on it now. Any questions and feedback are very much appreciated.

~~~
andybak
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.

~~~
epoberezkin
Yes, this feeling happens quite often indeed :)

