0

Software A is a Node/Express application using a MongoDB database. It is accessed mostly via RESTful endpoint by a mobile app built in RN and an admin dashboard via React web app. It also has a graphql endpoint beginning to be built to replace specific REST endpoints.

Software B is the acquired software solution built via React web app using Firebase (Firestore DB) solution. It uses other convenience features like Google and Facebook OAuth. Software B has not officially entered the market yet.

Software A has features that software B does not have. Software B has features that A does not. However, the goal is to create a “seamless user experience bringing together features of both Software A and B”.

My big question is around the following:

  • Do you keep these backend solutions separate or merge them into one backend (I.e. take Firestore logic and re-create on API and Mongo)?
  • What are the trade offs of each? (I.e. which is more manageable long term?)

Merge into one collective database and API: Pros:

  • Advanced data queries become easier for related data
  • More manageable long term to have one database solution rather than several.
  • Firestore will likely need to be migrated off of in the future anyway
  • Easier to optimize one solution rather than two separate databases. Example give me all data from A and then merge that with data from B then send to Frontend

Cons:

  • More development time to now move data structure and logic of B onto A backend.

Conclusion: My belief is that it would be worth the short term cost of moving over software B logic to software A backend because the data will be easier to access in a unified way. It also will be easier to migrate off Firebase now rather than a future where many users are using it (our business case is pretty solid that there will be many users).

I’m happy to supply additional information if it gives a more concise picture. (feel free to correct me if I am mistaken in any of my above points). This is the first time I’m involved in the integration of two different softwares so am learning this as I go.

8
  • In the era of micro services, why bother merging these at all? Feb 12 '21 at 0:46
  • Not to say it’s not a possibility. I guess my thought would be if the data from A is related to B and commonly going to be pulled together it would make sense to have it related on one database for performance reasons. Again I could be wrong in this assumption.
    – SKeney
    Feb 12 '21 at 3:32
  • 1
    "Software A has features that software B does not have. Software B has features that A does not." Does this imply that A and B have overlapping features as well? Whose implementation wins out in your proposed merge? Always A? Always B? Selectively? A and B both allowed at the same time, one failing over for the other? ...
    – Flater
    Feb 12 '21 at 13:07
  • "More manageable long term to have one database solution rather than several." Can you back this claim up? More often than not, the precise opposite is observed, whereby monoliths are inherently considered to be less maintainable, not more.
    – Flater
    Feb 12 '21 at 13:09
  • "Advanced data queries become easier for related data" Does this imply that you're moving towards having features that strongly depend on a combination of both A-only and B-only features? Because if that's the case, then you have a new set of C features who can only depend on the concurrent existence of A and B - this is not the same as having a bundles set of A features and B features.
    – Flater
    Feb 12 '21 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.