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.
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:
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.
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:
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).