So I'm working on restructuring 3 separate applications that share a lot of data. I want to consolidate the data in a single mysql database, but not all of it is shared. I also want to limit duplicated code in the codebase.
A couple things we are currently considering:
The shared information consists of a few database tables (i.e. Locations, Divisions, customers, enrollments, courses, and sections).
Because the tables are shared, currently the code (not live yet) is duplicating the models from one app to another. This is not ideal.
There is some information that is unique to each app (i.e. users)(although there are admin users across all apps)
What's the best way to structure these apps?
Is it better to try to strong arm them into one codebase? Or is it better to have 3 separate codebases with shared db and put the models in a shared repo? Or something else? Any help is appreciated!
I know this isn't much of an answer but it's better than nothing. The thing you need to look into is multi-tenacy and here's a post that provides some links about the situation.
I have been struggling with the exact same question. Finally I've decided to develop the (in my case two) separate apps both with its own database. The data that will be shared will be transferred trough a restful api (since Laravel makes this very easy). This way I don't need to replicate the models in both apps. Because when you really think of it, that can be disastrous when you need to make changes over time.
I don't know If this is the best option. So I will be following this treat along...
@toltech I think one of your option could be to create a API for shared data. This way, you could have multiple application connected to same data without having to duplicate your code.
After that, you could create a API SDK share between application used to connect to your API. Again, you will only have to maintain one base code to connect to your API.
Even if you don't want to share all data between each application, you can put all your data in the same place and restrict access to some application. You can use Oauth2 authentication for that.
The major problem i can see is, if your user come from different database, it's difficult to check if the user has authorization to a ressource. You have to find a way to put all authorization in the same place.
@stefr - I definitely like the idea of not having to duplicate the models. Could you give a little more detail on what you meant by, "The data that will be shared will be transferred trough a restful api (since Laravel makes this very easy)." I'm not familiar with how that is done in a way that would remove the need to duplicate the models in both applications.
@maximebeaudoin - I'm not familiar with the term "API SDK" - would an API SDK essentially share the model code (or code used to access the data) between applications? As far as users, authenticating them wouldn't be hard, but like you point out, resource level restrictions would be difficult to manage. Might have to have a permissions table that handled that or something? Any ideas on solutions on that end?
So, I'm assuming you had to create a third app that stored the models for the shared data that creates and "broadcasts" restful api that the other apps access? Which really isn't that much extra work... That would also answer the question of where migrations should live for the shared data (i.e. in the Restful Api app).
Hi Toltech,
In my case I didn't create a third app to push the data around. Due to the nature of my apps it was clear which app contained which model. But I can see why you want to create the third app.
In my opinion you're on the right track. Hope someone else will give his/hers opinion also. I'm curious how other developers would handle this.