We have 3 apps. They all currently have their own database, but there is a lot of duplication between them. For example, the User lives in all three apps.
My team is proposing that we use only one database and have all three apps directly connect to that database (not using an API, but pointing directly to the heroku instance of that database.) Assuming that the tables are reconciled, is this a good approach?
I think it’s horrible personally. I think that the “main” app database should be accessed by the smaller apps through an API. Am I wrong? Am I right? If so why? I need to present findings to my team but I really don’t have a clue as to how to present it.
I’ve seen people do this a lot, and I’ve never seen it go well.
By using a shared database, you’re making your database the API for communicating between applications. This only works if the majority of the business logic is implemented in the database layer and your data is heavily normalized; most Rails applications keep the database pretty dumb, and implement most of the logic, including persistence logic, in the models. Even if you move a lot of logic into the database, it requires a good amount of wiggling to coordinate deploys and updates between applications, because any change to the schema affects every application using it.
If you need to share data between applications, I’d strongly consider encapsulating that data behind a simple REST service. If performance or reliability becomes an issue, you can use caching and fast a communication protocol like AMQP to beef things up.
If a service seems really awkward or not worth the effort, consider merging your applications. For smaller applications, a monolithic approach may actually be best. You could also try merging in the applications as isolated engines. This simplifies deployment and allows applications to communicate with each other using a model layer, instead of requiring a service or data sharing.
Update: I was victorious! I managed to save my team from themselves thanks to @jferris’s arguments. We’re merging two of the three apps and the one remaining is remaining using the API approach. That was pretty close to what I originally wanted. Thanks @jferris!
Of course now I have the fun task of merging two apps. But that’s far better than the nonsense of having all apps write directly to one shared database.