4 ms·

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

epoberezkin 10y ago
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 10y ago
  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 10y ago
    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.

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 10y ago
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 10y ago
  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.