4 ms·

Good stuff. The push-invalidation-plus-refetch technique is sometimes referred to as "hinting". Some more info here: http://blog.andyet.com/2014/09/23/send-hint

Good stuff. The push-invalidation-plus-refetch technique is sometimes referred to as "hinting". Some more info here: http://blog.andyet.com/2014/09/23/send-hints-not-data http://blog.andyet.com/2014/09/23/send-hints-not-data I've also been working on a protocol definition for REST updates called LiveResource. Anyone interested in this problem space, please send feedback. :) https://github.com/fanout/liveresource https://github.com/fanout/liveresource

rakoo 12y ago
A lot of what your protocol enables can be done with CouchDB, with the notable of Webhooks and websocket. CouchDB's protocol has been worked on, implemented and used in production for years now, with several implementations. I'd love to see CouchDB used more and checked first as a starting point for anything in the space of live update of data, because it just works so well. Too many people re-invent the wheel left and right in this domain.
- jonahx 12y ago
  Could you provide any links for using CouchDB in this kind of use case? I wasn't aware of it as a solution to this problem (but only as a document db) and would like to learn more.
  - rakoo 12y ago
    CouchDB takes things a step further: instead of having all your data on a server and gradually sending changes to each interested party, CouchDB's way is to have a data store on each "node" (the server and all clients in a traditional web server model) and synchronize data (ie documents), possibly continuously. Then on the clients you react to changes and update the UI. Your application only manages the data locally, and the CouchDB components manages everything network-related. To do it, one useful component is PouchDB (http://pouchdb.com/ http://pouchdb.com/), which is a data store in the browser. You just hook it to whatever backend you want and access the data with a straightforward javascript API. There's also the much larger (in scope) Hoo.ie, but I can't talk much about it... Unfortunately I don't have any links for you, I'm looking for experiences just like you ...
    - JoeAltmaier 12y ago
      Is CouchDB still a thing? I thought it didn't scale past 6 instances or some such. And scaling was the whole point.

rakoo 12y ago

A lot of what your protocol enables can be done with CouchDB, with the notable of Webhooks and websocket. CouchDB's protocol has been worked on, implemented and used in production for years now, with several implementations. I'd love to see CouchDB used more and checked first as a starting point for anything in the space of live update of data, because it just works so well. Too many people re-invent the wheel left and right in this domain.

jonahx 12y ago
Could you provide any links for using CouchDB in this kind of use case? I wasn't aware of it as a solution to this problem (but only as a document db) and would like to learn more.
- rakoo 12y ago
  CouchDB takes things a step further: instead of having all your data on a server and gradually sending changes to each interested party, CouchDB's way is to have a data store on each "node" (the server and all clients in a traditional web server model) and synchronize data (ie documents), possibly continuously. Then on the clients you react to changes and update the UI. Your application only manages the data locally, and the CouchDB components manages everything network-related. To do it, one useful component is PouchDB (http://pouchdb.com/ http://pouchdb.com/), which is a data store in the browser. You just hook it to whatever backend you want and access the data with a straightforward javascript API. There's also the much larger (in scope) Hoo.ie, but I can't talk much about it... Unfortunately I don't have any links for you, I'm looking for experiences just like you ...
  - JoeAltmaier 12y ago
    Is CouchDB still a thing? I thought it didn't scale past 6 instances or some such. And scaling was the whole point.