21–30 of 68 posts
Earlier quoted context omitted.
The problem with webapps using a BAAS intended for mobile apps is the same origin policy. I've yet to find any providers that support Cross-Origin Resource Sharing. This restriction doesn't apply to mobile apps (or Chrome extensions)
If it were to operate as simply a REST API, then the service could simply return everything via JSONP to avoid the CORS trap.
The added benefit that we see is that we are experts in managing, optimizing and scaling all of the backside data structure for you, while offering solid analytics, performance metrics and visual tools that allow you significant control over your data as well as critical insight into what is happening.
Really excited about this type of development going forward and good to see other offerings in the works!
(full disclosure: I am one of the founders of MongoHQ.)
In fact, there are several such backend-as-a-service offerings in existence already, including StackMob -- a ycombinator company if I'm not mistaken. And note that any such BAAS that can be used for mobile development can just as easily be used for desktop web development. More and more desktop web apps are doing most or all of their logic locally using Javascript and then accessing their servers RESTfully for data p…
The problem with webapps using a BAAS intended for mobile apps is the same origin policy. I've yet to find any providers that support Cross-Origin Resource Sharing. This restriction doesn't apply to mobile apps (or Chrome extensions)
The primary client for an API I'm currently working on is an iOS app, so for the web version of the client, it just made sense to build on top of the same OAuth-authenticated API. Instead of traditional sessions, we store the access token in a cookie and sign each authenticated request just as you would any third-party API.
If a "BaaS" for a web app sounds appealing, try http://github.com/adelevie/parse_resource . It lets you use Parse in a Ruby/Rails app with a very ActiveRecord-y API. By using it, your web app gets the following for free: documented REST API, documented iOS and Android SDKs, and the guy who helped scale Scribd is your DBA. I've been using parse_resource to make some throwaway apps, and I'm currently "dog-fooding" it f…
We do believe the BaaS model can extend far beyond our current mobile focus. We have a full REST API upon which many people build rich web apps, desktop apps, and much more. Third party libraries like Alan's excellent ParseResource have been great enablers.
I'd encourage everyone to give Parse a try and keep an eye out. We plan to expand our selection of officially supported SDKs soon.
Moai Cloud (http://getmoai.com), while focused on enabling backends for mobile games provides some of what you describe. We use mongo on the backend to provide schemaless storage and are building out a set of RESTful apis. Additionally if you need to you can write and run your own custom code on the server.
https://github.com/srhyne/jQuery-Parse
Just $.parse.get/post/put/delete is needed; served from file:// or a Chrome extension and you have a completely client side prototype or internal business tool.
I'm really excited to see StackMob, Parse, and MongoHQ take off. Talking to one of the MongoHQ guys at MongoDB Seattle and they mentioned they were working on some kind of client side authentication system. jsOAuth is cool as well with StackMob.
Pedantically, RESTful APIs do not maintain session state on the server. This is important for scalability. (Whether "pure" REST is appropriate for a given API, or will be adopted if it is, is another question.) If too much is done on the client-side, it loses some of the benefits of webapps, such as easier to pirate the working code; so the competitive advantage needs to be in the data (or in the server side processi…
It provides a very rich query API on top of basic http, and as you can see works naturally with REST services. I'm not aware of how other frameworks provide OData support, but some quick googling reveals that most web frameworks have odata libraries available.
It's an incredibly bad idea to allow SQL directly, for obvious reasons (would require executing user provided SQL among other things.)
I believe that having a single REST api that serves multiple front-ends (web, mobile, thick client etc) is the future as it removes the need to maintain an entirely different codebase just for a web interface. Indeed, many major websites have moved to this model.