Guys congrats on the launch! I was wondering what was taking you so long ;) Very exciting stuff!
I'm amazed that we're on the same wavelength - we've had to build very similar infrastructure for ourselves for Unipost (www.post.fm). Can't believe we didn't collaborate on this, we'd happily be your first customer :(
A few interesting differences:
- Our approach is more like Meteor - web only, no iOS support
- The backend is a python tornado app that handles validation and conflict resolution before saving stuff to dynamodb
- We have a JS datastore backed by websql/indexeddb/memory that syncs with our backend datastore
- We have "live" Backbone collections that update themselves when datastore queries return different results
- We have a Backbone sync adapter that uses the datastore to persist data locally and kick off synchronization
- We sync a subset of the data (eg 3 months of mail) - thats a core requirement for us
- We sync all of the tables at once, not per bucket, cause queries are joining tables so the
datastore has to be consistent at all times
- No operational transforms cause it doesn't seem to apply to us - pretty "notepad" specific I think
- No versioning as we didn't see benefits for us
- We'll probably open source this stuff when we're done
Our goal on the client-side (compared to CouchDB) was simpler, more lightweight libraries that work well with existing tools that developers already use, like Core Data on iOS and sqlite/ContentProviders on Android.
Whereas CouchDB does master-master replication among instances of itself, Simperium can accomplish something similar with any database: e.g. sqlite on iOS, to MongoDB in our backend, and to whatever database you use in your own backend.
Just strange that you don't support offline for web apps, only iOS & Android, even though web apps can use websql.
That's probably cause you're used to writing native iOS apps, but we're attempting a web app that works via phonegap across all devices from one source code base.
So for us storing all the data in Backbone collections isn't an option - models add too much memory overhead, versus native JSON objects.
As I understand multiple collections update independently of each other? How do you deal with relational data in that case?
The map reduce paradigm isnt particularly core to PouchDB, it mostly in there for completion, I expect a fairly large amount of more powerful and easier to use querying mechanisms on top of PouchDB
I'm amazed that we're on the same wavelength - we've had to build very similar infrastructure for ourselves for Unipost (www.post.fm). Can't believe we didn't collaborate on this, we'd happily be your first customer :(
A few interesting differences:
- Our approach is more like Meteor - web only, no iOS support
- The backend is a python tornado app that handles validation and conflict resolution before saving stuff to dynamodb
- We have a JS datastore backed by websql/indexeddb/memory that syncs with our backend datastore
- We have "live" Backbone collections that update themselves when datastore queries return different results
- We have a Backbone sync adapter that uses the datastore to persist data locally and kick off synchronization
- We sync a subset of the data (eg 3 months of mail) - thats a core requirement for us
- We sync all of the tables at once, not per bucket, cause queries are joining tables so the datastore has to be consistent at all times
- No operational transforms cause it doesn't seem to apply to us - pretty "notepad" specific I think
- No versioning as we didn't see benefits for us
- We'll probably open source this stuff when we're done
What do you use for storage?