4 ms·

p2p sync is actually a hard problem, you might want to look into the theory :) The value of Hoodie is putting everything together into a way that a jQuery / ba

by janl 14y ago

p2p sync is actually a hard problem, you might want to look into the theory :) The value of Hoodie is putting everything together into a way that a jQuery / backbone dev can be productive with. It sounds like you are way more advanced, as such, you will have a way easier time managing all the pieces. > Why? Because we like building apps that way :)

lifeisstillgood 14y ago
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 :-)
- janl 14y ago
  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? :)
  - tarabukka 14y ago
    > 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.
    - Lazare 14y ago
      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.
      - janl 14y ago
        Yet again, spot on, thanks @Lazare!
nborwankar 14y ago
Hi Jan, another way to think about this (from the old days) is that disconnected mode data is a given because the rate of growth of data is far greater than the rate of growth of bandwidth. So everyone can't always be accessing all their data in the cloud through an always on infinite bandwidth connection. So you're going to need to carry a subset of your data with you - the subset that's "hot". Now having said that keeping hot data in sync with the larger data store is a hard problem - p2p or not. And what these architectures (CouchDB, PouchDB, ...) do is take the sync problem and make it an infrastructure issue so it only has to be solved once by the infrastructure creator (CouchDB team) rather than again and again and again by each app developer who wakes up in the middle of the night and realizes they have to solve "sync" in their app as an application problem. Then they have a nightmare and when they wake up they are babbling. The additional anti-pattern-badness with sync-in-the-app is that that kind of sync is usually incompatible with another app's bespoke sync. But when sync is in the infrastructure then a much larger group of people who use that infrastructure can share data across apps if they want to without having necessarily to share a schema. This is the real power of making sync part of the underlying computing fabric. Finally when this infrastructure is open source the real -danger of lock-in such as when you use Dropbox is mitigated, should you want to have that freedom. Cheers.

by janl 14y ago

lifeisstillgood 14y ago

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

janl 14y ago
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? :)
- tarabukka 14y ago
  > 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.
  - Lazare 14y ago
    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.
    - janl 14y ago
      Yet again, spot on, thanks @Lazare!

nborwankar 14y ago

Hi Jan, another way to think about this (from the old days) is that disconnected mode data is a given because the rate of growth of data is far greater than the rate of growth of bandwidth. So everyone can't always be accessing all their data in the cloud through an always on infinite bandwidth connection. So you're going to need to carry a subset of your data with you - the subset that's "hot". Now having said that keeping hot data in sync with the larger data store is a hard problem - p2p or not. And what these architectures (CouchDB, PouchDB, ...) do is take the sync problem and make it an infrastructure issue so it only has to be solved once by the infrastructure creator (CouchDB team) rather than again and again and again by each app developer who wakes up in the middle of the night and realizes they have to solve "sync" in their app as an application problem. Then they have a nightmare and when they wake up they are babbling. The additional anti-pattern-badness with sync-in-the-app is that that kind of sync is usually incompatible with another app's bespoke sync. But when sync is in the infrastructure then a much larger group of people who use that infrastructure can share data across apps if they want to without having necessarily to share a schema. This is the real power of making sync part of the underlying computing fabric. Finally when this infrastructure is open source the real -danger of lock-in such as when you use Dropbox is mitigated, should you want to have that freedom. Cheers.