Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

peer-to-peer synch? So this is not client server? But browser to browser? WebRTC-enabled? Much cooler. And not even eventually consistent. Please point me at theories :-)

  jQuery / backbone dev can be productive with

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? How do you handle network downtime or two clients changing one backend resource with downtime?

Why? - 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 :-)

View on HN

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? :)

> p2p sync enables you...

That isn't what "peer to peer" means, though. Peer to peer means that peers (the aforementioned browser, smartphone and tablet) communicate directly with each other.

Also, how does CouchDB keep things secure if clients can sync apparently any data? I'm assuming there's something there, but nobody else has explained this.

The trick is twofold:

First, CouchDB supports security and validation.

Second, for CouchDB replication is just another client connecting to a DB; it's handled the same way anything else is.

As a result, we have the notion of filtered replication. The server-side CouchDB won't tell anyone secrets they don't need to know - be they clients or client-side DBs. At at the other end, the client-side CouchDB has some validation to stop "bad" data going into the database by accident, and then the server-side CouchDB has the same validation again. People can compromise their client DB all they want, but eventually it all ends up on the wire as plain old HTTP requests interacting with a plain old REST API.

In many ways - as far as security goes - the client DB is a red herring. The server ONLY speaks a well-defined REST API, and has validation and security to deal with malformed or malicious API requests. The fact that those requests are generated by a client-side DB based on data entered into it via JS commands is neither here nor there; a Backbone app would generate the exact same requests based on more-or-less the same JS commands. If you can secure any REST API, you can secure CouchDB.

Yet again, spot on, thanks @Lazare!

Reply on news.ycombinator.com