DasSaffe DasSaffe - 15 days ago 5
reST (reStructuredText) Question

Offline capabilities when using REST (Firebase)

So I found this here in the Docs:


Every client sharing a Firebase maintains its own internal version of any active data. When data is updated or saved, it is written to this local version of the Firebase. The Firebase client then synchronizes that data with the Firebase servers and with other clients on a 'best-effort' basis.

As a result, all writes to Firebase will trigger local events immediately, before any data has even been written to the server. This means the app will remain responsive regardless of network latency or Internet connectivity.

Once connectivity is reestablished, we'll receive the appropriate set of events so that the client "catches up" with the current server state, without having to write any custom code.


Yeah, I got that going for me, but to be more specific (and I wasn't able to find an answer to that):

I am using the
REST
-API in a
c++
-program, which executes a
curl
-request. Everything is working so far. For the insertion, this is not a big deal. In case of an error, I can easily store the data via
redis
or something and update them later, but how does reading work?

To give you a scenario:

I made a scanner, which recognizes an ID. After this process, it is inserted (as explained above) into the Firebase. People can also register on a regarding homepage (and insert their ID manually). This will be saved in the Firebase as well. Same node obviously.

Firebase is designed to provide the data from one endpoint to another by accessing the db, which is fine. The user registered on the site and is inserted in the DB. Suddenly, my internet connection went away.

Is there any way to get the last "stack" or "full dataset", which was used, before my connection went away? Is there a way to replicate the DB and queue jobs, which will sync after the connection is re-established?

Answer

Disclaimer: I work for Firebase.

The passage you're quoting above specifically refers to the client libraries that we maintain (currently in Objective-C, Java, and JavaScript) - which are pieces of code that we've written that you would run in your app.

In this case, you're specifically not using a client library - you're just hitting our regular REST endpoint, so you won't get any of the benefits. To implement your own client would be a significant undertaking; it's the client code that maintains the internal view of the data, compensates when it's offline, triggers local events, etc.

Comments