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