Run multiple Laravel apps that run off the same database

To me, it really sounds like a single app with different user roles where the various roles allowed/disallowed you from accessing different things. Is there a reason for thinking they should be separate "apps"?

Yeah, I need separate login areas and pages. So like, it wouldn't make sense for admins to login through the regular login. They'll log in at http://admin.mysite.com.

From a resource perspective, I don't need admins on the same server, so I could always separate out an admin server and then put a copy of the app there.

You're right... this could still be a single app, using subdomain routing... but I don't know how that all comes together on the infrastructure side. So if I had one app that had some routes at mysite.com, and then more routes at admin.mysite.com, but I wanted to push the admin users to a separate server... what's the best way to do that? (maybe this makes the migrations issue go away?)

To me, the biggest issue that really determines how this would go is the "separate server" thing (not separate domains, which could still be the same physical server and still share a single common codebase). If they are truly on separate servers, they would be separate apps with each having it's own codebase, which is where the "migrations" issue comes into play. I guess one way around that would be to only have one "app" be responsible for the migrations, since you're wanting them to all share a common db.

Yeah, I need separate login areas and pages. So like, it wouldn't make sense for admins to login through the regular login

You can still do that using a single codebase. As you eluded to, you'd just use subdomain routing for admin.site.com and have it's own login view.

From a resource perspective, I don't need admins on the same server, so I could always separate out an admin server and then put a copy of the app there.

Could, yes, but would also make the infrastructure more complex since you'd have 2 separate codebases that couldn't share common models and such. I'd opt for not doing this. I doubt you'd have that many admin using very many server resources to justify putting it on it's own server, but maybe...

I think in this use case, it would be possible to let all these meta users (admin, sponsors, etc.) just run off the same codebase and use subdomain routing... but what does that look like for load balancers, multiple servers, etc.

I guess that's the part that I am missing. Is there a Laracasts lesson for that? Like, what if I have enough of a general userbase that I need 4 app servers and 2 database servers... how do you keep that all connected? or is that less a Laravel issue and more just a vanilla AWS issue?

Load balancers aren't a problem, but you have to do a few things. Instead of each server storing data on the server it's hosted on, everything needs to be stored externally. A common place that all servers would use.

For instance, with a single site on a single server, it's no big deal to have the database on the same server, file uploads stored on that server, sessions generated on that server, etc. But when you are behind a load balancer, these things all need to be in common. Like you can't upload an image on one server and have it show up on the other servers (well, you can with some extra work, but you wouldn't want to do that anyway). Instead, you'd upload to a S3 bucket or something external, and have all servers using that bucket to store/retrieve images. The same for the database. It needs to be on a separate server, with all servers using it. The same for sessions. Use redis or something for sessions. So if you log into one server on the first request, and the 2nd request puts you on a different server - it won't matter.

Once this system is in place, it's just a matter of adding a new server behind the balancer, deploy the app to it and make the balancer aware of the server. Really, almost a 2 minute thing and mostly automated.

None of this is specific to laravel. It's how anything behind a load balancer needs to work.

Here's a good article: https://serversforhackers.com/c/so-you-got-yourself-a-loadbalancer

This is exactly it. Thanks for helping me realize what I was really asking about here is how to solve the common resources problem. I'll check out that link and continue to research.

If you're trying to spread traffic and load across multiple servers, you would need to setup load balancers in front of your web servers.

It all depends on what you're doing. You mentioned two database servers. If you go that route, you need to make one your primary and one your slave. Any writes should only be done on the primary DB server, which should then by synced to the slave server. If your primary server ever goes down, you can pickup with the slave. Now if you had functions (such as report generating) that are read intensive but don't do any writing, you could point those to your slave server.

If you do decide to make separate apps for your users and admins, you can run them off the same database, but you will need to only run your migrations from one or the other. At that point, you're just setting your config file to point to the remote database, rather than a local one. Same applies for any files too. Just setup an S3 bucket and set both apps to point to the same bucket.

That being said, you should really consider what you're trying to accomplish. You mention potentially "needing a number of 'portals' like this for different user groups". You can also accomplish this with Roles and Permissions and even more so with subdomain routing. If they're all connecting to the same front-end web app, you will find yourself repeating a lot of code unnecessarily. While this may seem like a good idea now, it will quickly become a disaster to maintain and scale in the long-run.

Thanks for the reply. Given your and Cronix's answers, it seems like the best thing to do is just to use subdomain routing and then application logic to put up walls. The portals I mentioned are necessary, unfortunately, because we do have to cut off some functionality to those different user types.

99designs is a good example in the wild - you log in and are either a designer or a contest-runner, but you can't be both in the same account as it would be confusing, and then the disaster to maintain becomes this mutant UI that is some times one thing, some times the other, and sometimes both! :)

Thanks! -Matt