Managing front-end and backend via separate Github repositories

@jlrdw it's a website with an admin back-end.

The website will be replicated 3 times but the back-end will be identical for each.

Essentially there will be a whole bunch of stuff shared between the three websites, and a bunch of stuff unique to each one. The unique stuff would be mostly views, view composers and CSS, however I can imagine in the future there might be different front-end controllers between the three projects.

I've considered creating separate repos and using symbolic links for the shared code, but I'd need a lot of them.

Other solutions I've looked at seem overly complicated.

The other option is to have them as three repos and make future changes and amendments three times over, which I'd rather not do.

@Garet one site should work, just have authorization or RBAC to determine who can do what.

@martinbean When I say split into frontend and backend, what I mean is I have separate controllers and routes for the front and back. From example /app/Http/Controllers/Frontend/HomeController.php and app/Http/Controllers/Admin/DashboardController.php

Both the frontend and the backend live in the same project. I guess I should have said, "I have organised my frontend and backend into separate directories" rather than I've split the project.

The issue now is that I want 3 repositories for 3 separate websites which will certainly have different frontend views, and possibly different or additional frontend routes and controllers in the future. But, if I change one of the models, one of the admin controllers or one of the admin views, I don't want to have to replicate that change across all 3 sites.

@Garet Why do you have separate repositories for separate websites, if they all use the same models, admin controllers, etc?

@martinbean I don't, yet. At the moment I have a single project and would ordinarily submit the whole thing to one repo.

What I'm saying is, in the not too distant future I will have a further two projects that will utilise exactly the same admin area but they'll have different views for the front-end and possibly different or additional front-end controllers.

So I need to try and find a way of managing changes and updates across the three sites. For example, if I change an admin function, I don't want to have to make that change three times as it would apply to all three websites.

However, I might want to add a new front-end controller and route that's only required on one website, or I will certainly have different front-end views and CSS (because the front-end for each site will be completely different) so I can't store those all in the same project.

I looked into turning my admin area into a package so then I could have 3 independent websites that utilise the admin area as a package, and I would store the package in its own separate repo. But I am not sure if that's the route I should go down.

@Garet nothing to stop you splitting the files into different folders, eg

App/http/controllers/site1/DashboardController

App/http/controllers/site2/DashboardController

App/http/controllers/site3/DashboardController

@Garet You seem to be talking about multi-tenancy. I’ve worked on multiple multi-tenancy apps where there are different “sites” and any site-specific modifications you add then become a burden you have to maintain forever more.

Use feature flags to determine which controllers are available for which websites. For example, I have a multi-tenant CMS. Some websites have a shop, some don’t. So I use feature flags as middleware in the controller registrations:

Route::middleware('features:shop')->group(function () {
    // Shop-related routes...
});

In the feature definition, I just determine whether the shop feature should be enabled for a given website or not:

Feature::define('shop', function (Website $website) {
    return $website->hasConnectedPaymentGateway();
});

For styling, all websites have the same Blade views, but I can tweak things like colours and fonts using CSS custom properties (variables) in the website’s admin panel, as I primarily use Bootstrap which makes heavy use of CSS variables. So I can change a website’s “primary” colour by overriding the property like this:

@vite('resources/sass/website.scss')
<style>
:root {
  --bs-primary: #6610f2;
}
</style>

This will update the “primary” colour from blue to indigo for that particular site.

You don’t want to start making website-specific views and stylesheets because, any time you want to update a component, you have to then apply changes to all of the websites you’ve made customisations for. I say this from experience where I’ve maintained “custom” views and styles for multiple websites, and making one change becomes an absolute pain in the ass as you have to ensure you’ve accounted for those changes in all websites before deploying it.