

Backend-as-a-service for web apps? - davewasmer
http://davewasmer.tumblr.com/post/14952823756/backend-as-a-service

======
6ren
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 processing) rather
than the client app itself.

 _EDIT_ There's a general problem with RESTful APIs: they are fixed and can't
be adapted to every use. You might end up doing a lot of transformation on the
client side to assemble the info you want, and it might take several calls,
causing latency. What's needed is something like relations and SQL, so you can
extract the data in whatever structure you need, taking into account latency
(assembled on the server, the message short though including oft-needed
related data, and minimizing slow network trips). An obvious solution is for
the server to just accept SQL directly - i.e. for _that_ to be your RESTful
API.

This doesn't sound right - it's certainly not a conventional RESTful API - but
what exactly is the problem with it?

I think we don't have it yet, because there isn't a need for it in these early
days - because, so far, it's common for one server to be used by just one
client application, so that they are specifically customized for that one use-
case. But what will happen when several different client applications want to
use the same server? Secondly, these APIs are new, and there has been little
time for them to change much, so the problem of compatibility with old clients
hasn't arisen much.

SQL solves both these problems, of different application and of changes, but
these problem don't exist so far. And I guess it's not certain that they will
exist - if clients are always silently upgraded; if for a second app you just
create a second RESTful API for it (so the integration occurs further back, at
the database, instead of at the API).

~~~
colin_jack
> There's a general problem with RESTful APIs: they are fixed and can't be
> adapted to every use. You might end up doing a lot of transformation on the
> client side to assemble the info you want, and it might take several calls,
> causing latency

This isn't REST as such, in fact you have the same issue with any service API.

Solutions include creating composite resources, see Subbu's (excellent)
REST/HTTP book which discusses it.

Its also worth noting that more granular resources can have advantages
particularly when mutability is considered. So if you combine mutable data
with immutable data, and in addition the mutable data changes to very
different schedules, then taking advantage of HTTP caching becomes more
difficult. So if you create more granular resources but some of them are very
cacheable then you can actually in some cases get less latency.

> SQL solves both these problems, of different application and of changes, but
> these problem don't exist so far.

I haven't had time to play with it but ql.io is designed to address these
issues and might be worth a look:

<http://www.infoq.com/news/2011/11/ql-io-release>

~~~
dyoder
Nailed it. Composite resources and good use of caching with fine-grained
resources can go a long way.

HTTP is a pretty sophisticated protocol, when all is said and done. That means
there is a learning curve in using it effectively. However, a good BaaS takes
care of that for you, including providing default client libraries that know
how to take advantage of the API properly.

(Full-disclosure: my company, spire.io, has recently launched a REST API BaaS
that attempts to address exactly these concerns.)

------
adelevie
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 for a production app. I've found that the schema-lessness and
zero-db-admin makes prototyping a snap.

I'm fairly active in developing it, and would really like some feedback,
feature requests, and contributors.

~~~
csmajorfive
Parse co-founder here.

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.

~~~
dools
Hmm that sounds intriguing. With Decal we're basically avoiding building any
"features" or "modules" and instead using a totally SOA means of providing
extensibility so the presence of services that provide a "plug n play"
capability is something we're banking on.

------
jasonmccay
The MongoHQ API is making great strides moving in this direction and as was
mentioned in another post, the team is dog-fooding it so much that they are
building the next version of the MongoHQ web app on top of it.

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.)

~~~
fduran
Hello Jason, this is unrelated to the thread but since I have one of the
MongoHQ founders here let me abuse a bit and ask:

I'm considering using mongo in the cloud but the problem I see is that there's
no way to create a secure (encrypted) connection. Mongo doesn't support SSL
and I can't create an SSH tunnel like against a server I control. I don't want
my db data in the clear on Internet and I may not want to use AWS so that
we're on the same 'network'.

I cannot be the first with this issue, is someone looking into adding
encrypted connection to mongo? (I just see in mongo's site an open ticket
about this) thanks!

~~~
benwyrosdick
Hey I'm Ben, the other founder of MongoHQ.

Encryption is a common request for mongo and you can actually compile it with
ssl support (scons --ssl), but it just isn't in the build by default.

Since most of the drivers support ssl already we leverage that and do offer
encrypted mongo in a beta. If you would like to use an encrypted version of
mongo in the cloud then shoot us an email to support@mongohq.com

~~~
fduran
thanks for the answer, that's great news!

------
srhyne
I've written a small ajax wrapper for Parse.com's API.

<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.

------
nl
See CouchDB.

What is CouchDB?

A document database server, accessible via a RESTful JSON API.

Ad-hoc and schema-free with a flat address space.

Distributed, featuring robust, incremental replication with bi-directional
conflict detection and management.

Query-able and index-able, featuring a table oriented reporting engine that
uses JavaScript as a query language.

<http://couchdb.apache.org/docs/intro.html>

~~~
matc
Schema-free != handling data model changes transparently.

~~~
nl
I don't understand the distinction.

In CouchDB, if you want to change your schema you just save the new data.

Your code will have to handle the old and the new form, but that is always
true. In CouchDB the data is just a JSON document, so handling the changed
model is about as easy as it gets.

What am I missing?

~~~
matc
This is what you are missing: > _but that is always true_

You may have an old form you can't change.

For example:

\- 10 apps connected to the same database. Changing the model breaks 10 apps.
And you may not have access to change the code to any of those apps.

\- In healthcare, when either the database or app go down people literally
die.

This isn't as easy as it gets: no database vendor has a solution for this to
date.

(Edit: formatting)

~~~
nl
Okay.....

I'm not sure what your point is. As you say, this is hard, and no one else has
a solution either.

But the nature of CouchDB _can_ help here - views can be used to create
backward compatible versions of new data, and reading a JSON document with
extra fields won't break existing code.

It's true it's not magic, though, if that is what you are after.

Edit: I see now you are working on <http://chronicdb.com/> which looks like it
tackles this problem.

 _10 apps connected to the same database. Changing the model breaks 10 apps.
And you may not have access to change the code to any of those apps._

"Database as an integration layer" is an antipattern that should always be
avoided (except possibly in the case of reporting applications). CouchDB isn't
unique there.

 _In healthcare, when either the database or app go down people literally
die._

Yes, and? CouchDB is reliable, distributable, etc etc. If your point is that
you should be careful when you upgrade, then yes, I agree.

~~~
matc
Views are the reflection of the light at the end of the tunnel, but solve less
than half the problem to date. Views work on SELECT, but not on
UPDATE/INSERT/DELETE.

Also, what makes you say that database as an integration layer should always
be avoided?

~~~
nl
_Also, what makes you say that database as an integration layer should always
be avoided?_

15 years of writing software. Every time I've had to deal with a shared
database it has caused problems, and every time I've built a system avoiding
that antipattern it has worked much better.

But it's not just me, here's some references:

 _Enterprise Integration Anti-Patterns # - The Shared Database_ :
<http://ianfnelson.com/archives/2010/11/08/shared-database/>

_Database as an IPC Antipattern_ (which is a subset of the broader shared
database antipattern): <http://en.wikipedia.org/wiki/Database-as-IPC>

There is a good reason why SOA was created, and why exposing applications'
data via defined interfaces is very popular.

~~~
6ren
Database-as-IPC is about the transport aspect, not the logical integration
(which is the problem of back-compatibility).

Ian F Nelson's blog post is about a DB that is tightly-coupled to the app:
_“my” application is using NHibernate as an ORM layer, so until this invasion
we have been able to perform database schema refactorings with relative
impunity._

Conventionally, RDB schemas are designed in terms of the data itself, not a
particular app. In the Enterprise (where RDB are most used), data typically
outlives different applications for the same task over decades, often written
in different languages. Typically, the data needs also to be accessed by
several different applications.

But here I'm talking about _logical_ back-compatibility (surviving version
changes) - the blog makes good points about "caching and application-level
security". Where those vary with the application, it makes sense to separate
them from the DB. But like Database-as-IPC, they are closer to the transport
layer than to logical structure.

------
gvnn
Sick of seeing projects that use twitter's bootstrap I'm building a simple api
only cms: <https://github.com/gvnn/flatwhite>. It's a simple project that I'm
using to teach myself node.js... in the future would be great if users can
define their data structure and execute CRUD operations via REST calls

------
kijiki
The wheel of reincarnation spins.

We distributed the intelligence from the mainframe to minis/workstations and
then later PCs.

Then we re-centralized it to the datacenter/cluster with the web browser 1.0.

Now we're redistributing it to the browser (thin clients finally win).

Sadly, it appears that the democratizing effects of the PC revolution won't
apply when the code is delivered from a centralized server. Doing the
computation at the edge doesn't subvert control if the code comes from the
center. That (absent possibly impossible in practice cryptographic measures)
jailbreaking edge devices is possible isn't terribly relevant if 99.999% of
folks can't even understand the things they could do with a jailbroken device.

------
Barnabas
I was looking at kinvey.com mentioned in the comment of the article while
researching an alternative for Adobe Publish at work. Their 1-2-3 explanation
on the home page is compelling, except for the 1 part. Yes, one should have
the option of creating or extending a custom model, but why not have a library
of pre-built solutions? "Here's our e-commerce starter kit, it's got a cart,
products, customers, tax tables, and inventory management. Also we built an
awesome back-end and some integrations with these payment processors." If
you're building a BAAS, why not pick three or four common web-app types and
make the models for them.

------
jnbiche
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.

~~~
timfletcher
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)

~~~
davewasmer
If it were to operate as simply a REST API, then the service could simply
return everything via JSONP to avoid the CORS trap.

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

------
devs1010
Isn't this what frameworks like rails, grails and spring roo are for? They
make creating a basic CRUD app trivial. If you just need a trivial app then
use one of these frameworks, anything more is obviously going to require
customization on the backend code. I suppose there could be a niche for
managed RAD (rapid application development) packages, or something like that,
where they help people build an app using rails, or something, and then host
it, but its not nearly as groundbreaking as seems to be suggested, these
frameworks are fairly trivial to use as is to get basic CRUD functionality and
if you need more customization then you're already moving out of the territory
of having the backend as a service without having to pay custom development
rates.

~~~
mgkimsal
I've thought for a while about a service that would allow you to define a set
of basic models/domains, including basic validation rules and relationships on
them, then offer to generate the CRUD code, but in a variety of frameworks -
grails, zendframework, rails, asp.net, django, etc. Beyond being a 'neat idea'
though, I couldn't find any real use case for it.

~~~
devs1010
Yeah... the people who can make use of this sort of thing already would
probably be able to do the steps of generating the code in the RAD framework
so I just don't think there's much room to actually make money on something
like this but maybe if integrated with something like Heroku it could have
potential.

------
ramn
On the REST part it is not ideal for complex object based system where there
are multiple resources which have n number of relationships and different http
verbs on them can be mean different operations when exposed in a different
way. ( I know its confusing.. :)). I just look at it as a design pattern which
makes client side devs consume your services easily. It definitely helps in
creating simple webservices but REST as a whole I would say doesn't satisfy
everything a backend developer would want to expose or do in an efficient way.
Think of batching... in REST.

------
sashthebash
Many developers are already using our StorageRoom CMS
(<http://storageroomapp.com>) for this.

An administrator configures content types, editors manage the content and
developers fetch the content through the RESTful JSON API (including CORS &
JSONP support).

How is it different to Parse/StackMob/Kinvey? It is more about delivering
editorial content to mobile or web apps and not about a read/write backend.

------
ramn
This highly depends on the kind of apps which needs to be done. Its highly
difficult to generalize a backend for a n number of apps. I am not comparing
the term "backend" here with Parse or YQL or aggregating datasources which is
great. You write a backend to custom suite your app so that its highly
performant both on the client and server side and you have paas hosting
services for the language of choice. I would personally not like to have a
generalized backend.

------
larubbio
Disclosure, I work for Zipline Games on Moai Cloud.

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.

------
SoCool
There cloudmine.me also. They are providing similar services. I think mobile
BAAS is a limited market. But, domain based BAAS is a huge market. You can
never build a backend model to suffice the needs of different mobile apps. It
will be difficult to build a backend model for EMR system but providing a
backend model to convert dicom data for consumption on a mobile platform will
be a good service.

------
zeratul
Is there a more strict definition? Would this work:

    
    
      SAAS - HTML = BAAS
    

Too broad or too narrow?

------
aespinoza
My startup is building a BaaS that focuses on flexibility and any client not
just mobile. We are working on Javascript bindings to improve ease of use but
it has REST endpoint that uses JSON. You can read more about it at
<http://iknode.com>

------
mrtimo
RunMyProcess a startup from Paris, France does this.
<http://www.runmyprocess.com> . I teach university students how to use this.
Impressive product. Sort of like an enterprise-level configurable IFTTT.

------
dools
That's what these guys are doing: <http://www.ibcom.com.au/> despite a bit of
a naff web presence I've had a peek under the hood and they're doing some
really interesting stuff.

------
nestlequ1k
Rest apis on mongolab and mongohq look extremely promising.

------
ksajadi
We are also doing the workflow and job scheduling bit at
<http://www.thecloudblocks.com>

