Hoodie: very fast web app development

hi

I am trying very hard not to be dumb, but this is beating me

seemingly Kanso? and Hoodie both have JS stubs at the client and server end, these synch with each other, then synch with whatever you are using at client (say backbone) and server (node? CouchDB? My Postgres server behind my python app?)

If thats roughly right, why do I do this? I control my server apps no? Why wrap them in another layer? Json->backbone is hardly a difficult synch operation - I mean its called synch().

I really am interested in understanding the philosophy and driving ideas here - everyone has a moment of clarity where they can see how to build an app or a framework, and how it will come together - I am not attacking you (yet !) - please describe your moment of clarity.

Key difference: kan.so is Couch specific. Hoodie is not. We do not try to make another nice library to wrap CouchDB. We try to make a nice JavaScript API for the most common backend tasks.

We start with a dream API, and build from there.

Or one that, you know, is based on what its developers actually use.

this is many-client-server. p2p sync enables you opening your Hoodie app on your browser, smartphone and tablet at the same time and make it all work, even when some or all of the devices are offline for short or long periods of time :)

> I am not clear on that - is that "someone who does not / cannot develop on a tradiational server backend (LAMP etc). How does Hoodie help them

  $ hoodie new app
  $ cd app
  $ jitsu create
  $ jitsu push

(simplified)

> How do you handle network downtime?

Waiting.

> or two clients changing one backend resource with downtime?

p2p sync with conflict detection as provided by CouchDB.

> that was more what are the benefits to me as a LAMP / backbone dev to using Hoodie, as opposed to are you enjoying yourself, which seems evident :-)

While you are capable of doing all the heavy lifting, why not focus on building great apps? Or if your thing is running backends for people who build the apps, why not give them Hoodie and take the day off? :)

Okay, first off, let's discuss a standard three tier webapp architecture:

    Browser      Server      DB

You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hope. :)

It's simple and it justs works. Almost every website you use works this way. But for webapps, it's not always ideal. Let's discuss some of the issues:

First off, this architecture is "always online". If the browser loses connection to the server, then when your user clicks on a button nothing will happen. Not too bad in a desktop environment, but with laptops or - especially - mobile clients this isn't ideal.

Worse, what if you're trying to keep the state in sync with multiple clients (like Trello does)? You're probably using websockets or long polling or similar techniques so that the server can tell clients about the actions of other clients. A network hiccup might cause you to miss one of these updates; detecting and recovering from this sort of sync error is problematic. Generally the solution is to throw away the last few bits of work the user did, and force a full reload and re-fetch the current state. Which is fine, in most cases. Unless the work the user is difficult to replicate, or if the application state is quite large. Trello takes a second or two to grab the current cards; if your app takes 30s to grab its data, you may want to avoid this though. :)

In fact, the more you want to replicate the feel and functionality of a classic desktop app, while allowing multiple users and clients, the more you start to struggle against this architecture.

What other architectures are there? Well, there's one obvious one:

    Browser      CouchDB      Workers

CouchDB is kind of unique among databases because it speaks HTTP natively. It can serve your app to the client, and then turn around and have the clients connect directly to it. It can't, eg, send emails, but what you can do is use CouchDB as a queue. Add a document that says "send an email to X", then you spin up some worker processes that monitor it and process any documents like that as they appear.

CouchDB also has a _changes feed that makes a lot of sync tasks very easy. It also does master/master replication, and is generally a really nice database to work with from a devops point of view. Still, we're missing a crucial bit of magic to really improve over a classic three tier webapp. And that is...

...local DBs, in the form of PouchDB for browsers or TouchDB (apparently called Couchbase Mobile these days, although confusingly it's unrelated to Couchbase, which in turn is unrelated to CouchDB. Don't ask.) for Android/iOS. CouchDB is really really good at syncing and replicating, so now we have a new architecture:

    Browser/Mobile App    PouchDB/TouchDB    CouchDB    Workers

This isn't appropriate for every task. For one thing, it's quite a lot more work to implement (partly due to inferior tooling which projects like Hoodie are, thankfully, addressing). But if you really want the best possible user experience, you want it to work even if your on an airplane or in a tunnel, you want a really snappy UI, you want each client to see the changes made by other clients in as close to real time as practical, you want a consistent experience for native mobile apps and webapps running in a browser...then this is the architecture for you.

So to directly answer your questions:

First, Kanso (by default) wants to do something like:

   Browser    CouchDB

Which is a really slick, really easy way to do single page applications that don't need local persistence or server processes. But it's not hard to add them on, in which case you have the architecture above. You seem to be imagining something like this:

   Hoodie Client    Hoodie Server   CouchDB

But that's not the idea at all. You're also asking why not do this:

  Backbone    Python     Postgres

And that's a perfectly fine architecture. It works, it's rock solid, and it's easy to code. For many apps (maybe most) it's the best possible architecture (well, I'd suggest Knockout over Backbone, but that's personal preference).

But for the project I'm working on right now, we decided that wasn't quite good enough. :)