I was wondering if Firebase would be a good choice for a simple CRM app.
The app would have a login page, a dashboard, a calendar page where the user can add events, a contact list page where the user can add clients in there, and a “route” page where you can create your route for the day using Google Maps API (select your day, put in your starting point, then the places you must go during the day, and the end point).
This app will be for businesses with salesmen.
So each businesses will have their own “sub-database”, with multiple users. But ultimately, we need 1 main database that I should have access to, but only I, as the admin and owner of this app/business that I will sell accesses to businesses.
Again, 1 database, with multiple sub-databases for each “clients” that will have multiple users in it, and share data between all users from that sub-database.
Also, I will have to access this data to create a web admin panel. So data must be accessible via the App, and via Web.
“In this post, we’ll see that Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred. The former is (as far as I know) a new result which runs contrary to all of Mongo’s consistency documentation. The latter has been a documented issue in Mongo for some time. We’ll also touch on a result from the previous Jepsen post: almost all write concern levels allow data loss.”
Not at this point. Firestore is obviously going to be the core product as opposed to firebase based on the public’s general reaction (as far as I can tell). I would say there’s more risk in building an app based on firebase database, as it’ll be a thing of the past sooner rather than later.
Even in its’ beta phase, I think Firestore is a better product than firebase. That being said, one can only expect the product to get better as it moves out of “beta”.