Announcing Firebase Mobile Offline Support | Hacker News Reader

Announcing Firebase Mobile Offline Support

firebase.com

52 pointstlarkworthy10 comments

Hi HN! I’m Jonny, one of the lead engineers who worked on this feature. I’m really excited about this release, and I’m looking forward to getting your feedback when you try it out.

Is there some sort of guarantee that Google won't just start killing features (including this) if its not a hit? Lot's of people here have been burned.

Also: there's no mention of conflict resolution which will be a lot more prevalent with the long disconnects, what are the available options for handling it?

Why is this just being added to the native API?

What about wrapped-js-apps, and single page apps?

We haven't forgotten about web developers! We prioritized offline for mobile first though since its a more critical use case there.

I noticed Firebase stores things in localStorage. That wasn't being used for handling being offline in webapps/mobile hybrid apps?

Yay. Though, fwiw, I am a primarily mobile developer :)

I just removed Firebase from my two personal projects and replaced them with a local storage library so I could keep developing them on the go :)

It'd be nice to know how it determines which writes to use if two devices are offline, have conflicting data, and try to write to the same database after they're both connected.

Vector clocks? Last write wins? Conflict resolution functions?

Firebase (even without offline persistence) uses a simple last write wins strategy. This will work well with most apps. However, if this is not enough, our security rules allow you to have more complex strategies based on client time, for example. Even without offline it really depends on the kind of conflict resolution you want in your app. For complex apps that require merges we recommend to build something like operational transform on top of Firebase (As an example look at Firepad [1]).

[1] http://www.firepad.io/

Could you add more detail as to what you mean by "last write" ?

Is it the time at which the write was performed locally, or the time at which it was sent to the server ? the difference can be quite large if for example you connect a device after having worked offline with it for a long time.

Isn't this mostly basically how Meteor works?

Reply on news.ycombinator.com