Multiple apps using the same models?

@tykus Thanks for the reply. It's good to see that it's more than just a concept and is actually being used somewhere. All of the posts I read just suggested it as a solution, none actually stated they had implemented or worked with a structure like this.

Yeh we are the same. All applications will be using the same version of the models and anything else we need to throw in there such as seeders/factories to be used between both application tests.

What do you mean when you say you handled the database schema and migration changes manually? As in directly altered the table through a database client? If so, how did you run the tests between applications? They wouldn't be able to start from an empty database then would they?

@Tray2 Thanks for the reply! What do you mean by add an authorisation layer to the existing application? Do you mean implementing a pseudo multi tenant application or something?

@Savlon No. They mean just use the standard authorisation features that Laravel comes with out of the box: https://laravel.com/docs/authorization

@Savlon It will not be multi-tenant but rather an admin layer to your application.

An administration dashboard if you will, just like @martinbean says.

@Tray2 Ah yeh I see. I've replied to @martinbean below for reasons why I would like to avoid doing that.

@martinbean trust me, I have thought about that and even started to implement it. The problem with that is I would need to duplicate the project on separate servers and restrict one to admin and the other to customers. I would prefer if they were on separate servers for several reasons.

1. Keep customer access and admin access separate.
2. Allow resource intensive processes to run on either server without affecting the other.
3. Reduce the size of the overall application. My customer front end is in vuejs so I would prefer not to have admin components for just about every component I have... and I don't want to convert my components into if else :is monsters which retrieve a component dependant on the user role.

This is a very large project and I want to keep it as clean as possible without adding code that could be added elsewhere.

@Savlon Ok, this is my take on it

1. f*** that, a user is a user and with the correct roles and authorizations it's not a problem. You can use admin prefixes on your routes to make it even more clear.
2. That will not help you att all since you are using the same database and it's the database that does the heavy lifting, You can schedule jobs that uses a lot of resouces to run at times when the app isn't used or at least less used.
3. Having two repositories to handle that, most likely with duplicate code is a worse option in my opinion. You don't need to have two versions of each component, just use the authorization to show and hide stuff on the components.

@Tray2 you’re probably right but my inner ocd tells me to keep it separate lol!

The database will be mirrored with separate read/write streams so they’d be using the same database but different databases if that makes sense.

Yeh that is what I worry about. It would actually be 3 repos to manage because admin app, customer app and then any shared code app.

How do other companies handle this though? Surely a Facebook administrator doesn’t log into the same area a normal user does? Like I know I’m no where near their size and probably won’t ever be but to me it just seems wrong to allow an admin to log into the same application as a customer. I don’t know… I guess I have some thinking to do. Cheers

The database will be mirrored with separate read/write streams so they’d be using the same database but different databases if that makes sense.

That sounds dangerous! Race conditions and deadlocks are bad enough in a single database – if you want to have users and admins working on out-of-sync mirror copies of the same database (and they will by definition be out of sync), you’ll just be adding to the potential pitfalls. What happens if a user does something that updates a row in a table, but at the same time an admin does something that deletes that row? You’ll need to handle that gracefully. The pitfalls are legion.

Surely a Facebook administrator doesn’t log into the same area a normal user does?

Why not? Facebook administrators are just regular Facebook users that have administrative rights over certain pages/groups/things. Or do you mean the people who work for Facebook and do behind-the-scenes administrative stuff? They probably have a separate admin panel-ish thing for that, yes, but there’s no reason it shouldn’t be part of the same overall application structure. For Facebook, of course, neither the databases nor the app itself is hosted on a single server, so they do need to handle all the pitfalls that come with that – but that’s because they need to serve billions of users every day.

Unless you know that a single server will not be able to cope with the number of users/traffic/resource usage you’re expecting, deliberately dividing your app into pieces spread across multiple servers generally has more downsides than advantages.

@Savlon I agree with @kokoshneta that database mirroring isn't a good idea here, it should be used to keep two or ore databases in sync in case the main database (which handles all the io) fails, and then be switched to another one. You never update records in two places and expect it to work with out fucking up the database.

I suggest using KISS instead of overthinking it like you are doing now.

@kokoshneta ok you and @tray2 have convinced me. I will need to organise my application incredibly well.

Thanks for the advice boys