Question

My question is a follow-up to this topic. I love the simplicity and performance of Firebase from what I have seen so far.

As I understand, firebase.js syncs data snapshots from the server into an object in Javascript memory. However there is currently no functionality to cache this data to disk.

As a result:

  1. Applications are required to have a connection when they start-up, thus there is no true offline access.
  2. Bandwidth is wasted every time an app starts up by re-transmitting all previous data.

Since the snapshot data is sitting in memory as a Javascript object, it should be quite trivial to serialize it as JSON and save it to localStorage, so the exact application state can be loaded next time the app is started, online or not. But as the firebase.js code is minified and cryptic I have no idea where to look.

PouchDB handles this very well on a CouchDB backend. (But it lacks the quick response time and simplicity of Firebase.)

So my questions are:

1. What data would I need to serialize to save a snapshot to localStorage? How can I then load this back into Firebase when the app starts?

2. Where can I download the original non-minified dev source code for firebase.js?

(By the way, two features that would help Firebase blow the competition out of the water: offline caching and map reduce.)

Was it helpful?

Solution

Offline caching and map reduce-like functionality are both in development. The firebase.js source is available here for dev and debugging.

You can serialize a snapshot locally using exportVal to preserve all priority data. If you aren't using priorities, a simple value will do:

var fb = new Firebase(URL);
fb.once('value', function(snapshot) {
   console.log('values with priorities', snapshot.exportVal());

   console.log('values without priorities', snapshot.val());
});

Later, if Firebase is offline (use .info/connected to help determine this) when your app is loaded, you can call .set() to put that data back into the local Firebase. When/if Firebase comes online, it will be synced.

However, this is truly only suitable for static data that only one person will access and change. Consider, for example, the fallout if I download the data, keep it locally for a week, and it's modified by several other users during that time, then I load my app offline, make one minor change, and then come online. My stale changes would blow away all the work done in between.

There are lots of ways to deal with this--conflict resolution, using security rules and update counters/timestamps to detect stale data and prevent regressions--but this isn't a simple affair and needs deep consideration before you head down this route.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top