Database I should go for with a simple CRM app


#1

Hello everyone!

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.

Thanks a lot guys!


#2

Peehaps this service for databese, there is a free plan

With this for hosting also with a free plan

Coud be a good starting point


#3

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

Commonly referred to as “multi-tenancy”:


#4

See: https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

“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.”


#5

Ah ok. You want to share data between the sub databeses. I don’t get this from your first post. Sorry.


#6

Firestore and or firebase can do this easily as well. Just fix your security rules and data model to refelect tightness/segrgation in databases.

Just be aware that this way you have a centralised auth system, so if one salesman works for two businessmen, you need a selector in the ui

This also increases your options on scaleabulity etc

So if you have faith in google and its firestore beta, then consider that one


#7

Thanks! I think I will go with Firebase.
Can anyone else confirm that Firebase would allow me to do pretty much everything I need based on my first post project description?

Thank you!


#8

I can confirm. Though, I would go with Firestore. Your description ( sub-databases ) would fit very well with Firestore’s “collections” structure.


#9

But wouldn’t be risky to build an app with Firestore since it’s still in Beta?


#10

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