13 ms·
Show HN: JSONScript – Asynchronous scripting language using JSON format
- epoberezkin 10y agoYou 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
- _nalply 10y agoHow to prevent Denial of Service? For example when a customer sends an infinite loop to the server?
- epoberezkin 10y agoThat 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 10y agoGraphQL has similar problems. It seems somewhat inherent to batching solutions.
- epoberezkin 10y agoInteresting. 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 10y agoI 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 10y agoLol. 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.
- deleted 10y ago[deleted]
- epoberezkin 10y agoI'm working on it now. Any questions and feedback are very much appreciated.
- andybak 10y agoYou 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 10y agoYes, this feeling happens quite often indeed :)
- ingenter 10y agoThis 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.
- fallenshell 10y agoAgreed.
- epoberezkin 10y agoI 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).
- tony-allan 10y agoThe safety of a simple language is appealing.
- woah 10y agoI 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.
- fallenshell 10y agoThis 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_thing_up_pretty_well/ https://m.reddit.com/r/coding/comments/3akmn1/sums_this_rel_...
- epoberezkin 10y agoThat'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 10y ago>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 10y agoI've seen several XML based scripting implementations. This one for example: http://www.drdobbs.com/web-development/jelly-an-xml-based-scripting-language/184405386 http://www.drdobbs.com/web-development/jelly-an-xml-based-sc... 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...
- fallenshell 10y agoNot necessarily. It just shows people are willing to experiment with JSON, even though it might end up badly.
- macspoofing 10y agoI 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 10y agoRedis'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 10y agoMany people use YAML instead of JSON by the way - a bit fewer characters.
- NelsonMinar 10y agoFinally, a programming language that frees me from the possibility of writing comments!
- epoberezkin 10y agoIndeed :) Self- documented is always better. Unfortunately, it's easy to add though :)
- fallenshell 10y agoReally hoping that was sarcasm...
- prawnsalad 10y agoFeels 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 10y agoThanks 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 10y agoRe '$', 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.
- alttab 10y agoThis 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.
- epoberezkin 10y agoIt's out of stock - https://www.amazon.co.uk/Service-Oriented-Architecture-Concepts-Technology-Computing/dp/0131858580 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.
- alttab 10y agoThey can be addressed, but you'd have to address them anyway with a simpler interface and it would be less work to do so. This is more untestable because the service that provides the scripting interface needs to have a test bed that is similar to the test bed of an entire language itself. Are there corner cases? Can a client cause a script to loop indefinitely? Is there a test case for every known combination a client would attempt? If so, why not just support each use case explicitly? There are 1000 reasons why being additionally clever causes more headaches than its worth. I'm not too upset about it - because I'm confident those that don't heed this warning will learn the lesson the hard way.
- tony-allan 10y agoI 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 10y agoThank 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.
- secoif 10y agoWhy do many language home pages not show a single sample of the language?
- epoberezkin 10y agoIt'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.
- epoberezkin 10y agoAdded script example to the home page: http://www.json-script.com/ http://www.json-script.com/
- tony-allan 10y agoI 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 10y agoThank you. YAML will look more like plain text and still will be easy to parse.
- jiyinyiyong 10y agoIf 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 10y agoInteresting indeed. Thank you.
- woah 10y agoI 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.
- epoberezkin 10y agoFunny story indeed :)
- gajus 10y agoSorry, whats the moral of this story?
- epoberezkin 10y agoThanks 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 10y agoI 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?