Offline first Mobile App with firebase

Hi,

I want to develop an application which will run offline (No internet Connection Required) primarily. But I also want to give an option in which user logs in and can save his/her data online. For online database I want to use firebase
Can firebase be used for this kind of functionality in which user saves his data in localstorage and can optionally log in to push data to server and sync on various devices. If no then what data storage options can I use to provide this kind functionality in my mobile app. Also the log in feature is optional so is it feasible to use a Database as a Service solution or should I write custom mix of a online datastore and local data storage.

Thanks in Advance

I saw that Firebase has “offline” capabilities but for now it’s only in the “native” SDKs (Android and iOS), it’s not in the Javascript SDK yet:

Apparently offline support for the Javascript SDK is “in the pipeline” but no ETA yet:

https://groups.google.com/forum/#!topic/firebase-talk/GzV6itqYTRw

So for now you would have to manage the offline part yourself (I think Firebase gives you the hooks/tools to allow you to manage the local storage yourself using e.g. SQLite or PouchDB but managing the local storage would be up to you).

I’m also using Firebase but since my app is pretty useless without a network connection I’m not really bothering with adding “offline” support. However if it’s important to you there are a few alternatives, e.g. PouchDB/CouchDB and Angular-Meteor:

1 Like

Thanks @leob for your insight. This pretty much clarifies for now I have to manage local storage. I have worked with firebase and I am really impressed with its capabilities. Really looking forward for full offline support.

2 Likes

And after a year, of writing this, there’s still no support for offline for Javascript SDK.

Firebase is moving too slow!

Google seems to be pushing Firebase pretty hard, but apparently not this functionality.

Anyway I’ve largely lost my interest in Firebase, too much technology/vendor lock-in.

I prefer to host my own backend now, there are many (open source) solutions which give you the same functionality as Firebase does, look at this for instance:

1 Like

And they push Progressive Web Apps everywhere, yet can’t someone within their team ask them,

“How are people we’re forcing PWA down their throat supposed to build Offline-First apps, when our own Firebase for Web don’t support it, and we don’t have any ETA?”

:unamused:

Yes good point I suppose :slight_smile:

Hey guys, I made an offline wrapper for AngularFire2 so that read-only Firebase data is available offline. It works with Ionic 2 and Angular 2. Feel free to contribute!

1 Like

Hi Leob, looking into an alternative for Firebase, offline first in js. Are you still using feathers.js, how’d it go ? Do you use the socket.io implementation ?
My main app is using ionic V1.
Thanks !

Well actually I didn’t do much with Feathers, however I still think it’s a very interesting technology which has the potential to create elegant application solutions. The idea is a little bit like Meteor but more lightweight and flexible, it does not dominate your application architecture as much as Meteor does.

There’s a group of very smart people behind the framework who are investing a lot in it and keep improving it:

They also have an “offline first” solution now:
https://docs.feathersjs.com/guides/offline-first/readme.html

I think that Feathers is interesting if you want to build a full backend yourself, with business logic/processing and so on, so not just the data storage and authentication that Firebase provides.

If you are looking for a simpler solution (Feathers does have a learning curve and requires you to embrace their approach to application architecture) then have a look at this thread:

This is quite a brilliant post. The essence of it is: build a centralized component that mediates between your app and Firebase.

So instead of scattering Firebase calls all over your application code, mixing your business logic with Firebase specific code, you have your application code (business logic) communicate only with this centralized component, which then communicates with Firebase.

This centralized component can then also take care of “offline” (caching), as the author of the post explains. This makes the whole process transparent, and if ever you want to replace Firebase with something else you can do so relatively easily, if you’ve done it right - you would only need to rewrite your “mediator” component, not the rest of your app, because the mediator component isolates your app from Firebase specifics.

Some other comments on this same thread pointed out that standard solutions for this problem exist already. So instead of writing this “mediator” component yourself you can use these standard solutions, the most well-known is called “ngRX” which is based on “RxJS”.

In general, I am more a fan of this type of application-level solution (either Feathers or ngRx or a home-grown mediator component) than a “black box auto-magic” solution at the database level (for instance with Couchbase remote/local or Pouchbase).

These database level solutions sound easy, but you don’t have any control over what’s going on - way too much “magic” (which is fine as long as there are no problems but becomes a liability when it doesn’t work).

I’m learning it :heart:.
Many thanks, sir!