Hacker News Reader

Comment by jnbiche | Hacker News Reader

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 persistence. StackMob is well-positioned to take advantage of both the surge in mobile apps and these new trends in desktop web development.

View on HN

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.

JSONP should only be used for public web services. otherwise, any third party website could make privileged calls.

The BaaS architecture is actually a perfect situation for making privileged calls with CORS, because the server is wholly responsible for the user's identity and permissions.

JSONP only works for GET requests. It's not 'proper' AJAX. You wouldn't be able to POST, PUT or DELETE.

OAuth 2 + JSONP might be a good solution to the cross-origin issue.

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.

We use CORS at spire.io.

True, but don't those services require schema definitions and similar setup? It seems like a lot of prototyping could be sped up by simply inferring relationships based on RESTful URLs and relying on schema-less storage.

Seems like that would only work in the simplest of cases. And then why would I pay someone for the backend of a trivial app?

I'm not sure. It certainly couldn't handle every use case, but maybe with some convention-style configurations (e.g. a record created via a POST to /users would hash any "password" field) you could handle a bunch of typical web app scenarios.

And if that doesn't work, perhaps the schema-less prototyping is a free tier with a more robust backend service offering for the paid tier?

"The password field is handled differently than the others; it is encrypted on the server and never returned to any client request."

https://www.parse.com/docs/rest#users

Reply on news.ycombinator.com