This was the issue I had with Parse when looking at it, while I think it is a great service, we need more than just a data store, there has to be some way to perform logic behind the REST service, because it is just not an operation that you can trust the client to do. You may be able to get away with a mobile device to card authorization but a JavaScript client should not be trusted to orchestrate it. So for me, with these services that look like a data store there is a core piece missing and that is the ability to perform business computation and orchestration that the client should not be responsible for.
You can see the screenshot here:
* Editor: http://iknode.com/images/tour/appeditor.png
* Assembly Upload: http://iknode.com/images/tour/asmupload.png
You can create your application that becomes a service endpoint and then just call your logic.
You can call your application using a REST POST like this:
https://api.iknode.com/Applications/execute/<application...
And in the body just put your parameters:
{ parameters: "{ myParam1: myValue1, myParam2: myValue2 }" }
We are planning to support IronPython and IronRuby in the future. In the case of Lisp, we looked at Clojure, which can run on top of the CLR. But we have no plans for it so far.
You'd still need something to handle transactions which can not be allowed to be performed by a user, such as credit card transactions, web service account-linking authorizations, etc. You could have an app on your iPhone written in JavaScript that just queries for transactions to process and does all the heavy lifting, in effect being the "backend" on your phone. But again, that would be really annoying.
We have frameworks and libraries for a reason: to make writing the monotonous backend quicker and easier. When you utilize the right tools it shouldn't be too much work. But yes, you could probably offset a lot of crap on the server with simple key/value sets sent from the client. Whether or not that's a good thing i'll leave up to the users to decide.