Unifying databases and what to do with the userbase

Hi there Meteor community!

I’m working for a local enterprise and I’ve been developing two applications for them both using Meteor.

First is a formerly simple website for showcasing products.
Second is an internal application for the enterprise to manage a lot of its internal processes (sending stuff to workshops, creating delivery routes, checking merchandise stock, creating documents, etc).

Before me coming onboard, all this was managed through a single 3rd party application with an Oracle db. So, even now when there are two applications, there is a lot of “common data” in that external DB (which I don’t manage but from where I get all the information I need).

Now the necessity has come to share information between web & application. For example: A web client submits a new cart request, they want to see notifications in their internal app. An employee marks a cart request as ready to pickup, they want to showcase a notification to the client. And many other things.

Since the enterprise products are a common ground for both applications, and so is the information of clients/users/documents and so on, I thought unifying the mongo db was the best thing to do and the easiest way to share information between the apps.

However, it feels unsecure regarding the user side of things. I’d be at ease if the db used to authenticate users would still be independent, and there would be no possibility at all that a web user could sign in into the app and vice-versa. But I’m not sure on how to achieve that (first implementation is a pre-login valildation method). What would you recommend in this regard?

And what are your general opinions/recommendations on having two applications with a single db ?

Your input will be most valuable.

Best regards!

Hi. It seems to me that these applications do 2 different things and serves 2 different types of users - which indicates to me that you might really want to keep them as separate things. There are a couple of things to take into account. For example:

  • How much load does one app have compared to the other?
  • How does each piece of data relate to the other?
  • Could in the near future users in app A also use the same account as the users in app B?

How does 1 app work compared to the other? Should one be real-time? Is the other just better off with a request / response type of load?

There is not really 1 good answer, but my advice would be:

  • Visualize (for example using draw.io) how collections and data relate.
  • Highlight where the overlap is
  • You might want to create a separate app / service for every thing that overlaps.

For example. If you really want users to have just 1 account for both apps, consider either to use an identity provider like Auth0 or connect the sessions of both Meteor apps.

Its very hard for me to give proper advice on this. It all boils down to how your app is used, if there are special requirements like realtime synchronization and how each entity in your system relates.

Can you share a bit more about this?

@cloudspider thank you for your insightful comment and please forgive my lack of answer. I did see your comment and thought much about it but didn’t comply to provide an answer that was up to yours. I’m really sorry. I was a bit overwhelmed with work.

So, coming into details.
In the last months data has overlapped “a lot”.

I’ve basically started to create common components that both app use. For example: a page to review all of a client’s documents (a request for merchandise, a receipt, a document detailing a return or change of product, and many others). Both applications (web, for clients, and app for employees) use the same component (and the same db) and depending on the type of user accessing the data, more or less data is shown, as well as different actions (a client can cancel a wrong order, an employee may want to notify a client such order can not be fulfilled because her account lacks of credit, etc ).

Real time is not crucial but desirable, as if some order is suddenly moved to “ready” by an employee, a client would see its update right away in his dashboard, alongside details on delivery, etc.

So I don’t know exactly how deep to go here, but I think the idea is settled: Products, its’ prices, documents regarding commercial operations, actions from either side (placing an order (client), approving it (employee), notifying its readiness (employee), paying for it (client), adding credit to a client account (employee), modifying product details (employee), ask for a returning (client)) all relate to the same chunk of data. This, I think, is a BIG overlap. Yet the application/enterprise side has, of course, much more.

I’m considering using an authentication provider, as you suggested, to feel better about it all.

Regarding the load of the applications, both are very little. The enterprise has around 50 employees using the app for either administrative or logistics, and the web page receives around 200 visits and around 10-20 orders per day).

Anyways, thank you very much again.

I hope this generates some more discussion on the topic.