Ale*_*cun 2 php architecture frontend laravel vue.js
假设有一个用 Laravel 制作的 CMS。我们将为不同的客户端提供相同的 CMS，在我们创建的每个版本上升级他们的 CMS，但有一个配置文件来定义每个客户端可用的功能。整个后台（管理面板等）将大部分是静态的，并且只会将 Vue 用于某些动态元素。当涉及到后端时，此解决方案适合我们的需求。
但是，我们计划为每个客户端部署不同的最终用户前端。解耦这些听起来很简单（创建一个完全独立的前端项目并使用 API 端点来动态获取和呈现所有内容）但是如果我们要完全解耦前端和后端，我们将失去使用 Laravel Blade 呈现静态页面的能力，我们需要由于渲染速度、加载时间、搜索引擎优化等，某些页面的该功能。
主要问题是：如何将每个客户端的前端与后端解耦，同时又不失去使用 Laravel 和 Blade 渲染页面的能力，同时保持开发和测试的简单性？
我想到的解决方案之一是创建一个构建后步骤，我们将特定于客户端的前端文件“合并”到 CMS 中，但这会使开发过程变得非常困难，甚至几乎不可能开发和测试。
我想到的第二个解决方案是：
这个解决方案似乎可行，并且允许我们使用 Laravel Mix 和服务器端渲染，但它很容易出现人为错误，并且一段时间后我们很难跟踪这些分支。我读过的其他潜在解决方案之一是使用 Git 子模块，但我很难理解它是如何工作的，而且它似乎不像在这个用例中那样灵活。
对我们来说，什么才是最好的建筑解决方案？
我会将您的 CMS 视为一个包，并将您的不同前端部分视为独立的项目，每个项目都依赖于您的 CMS。例如，我将 Backpack for Laravel 用于许多项目：https : //github.com/Laravel-Backpack/CRUD，我认为它与您所描述的类似 - 一组通用的核心功能，但没有意见前端。
Laravel 包可以注册路由、发布视图和资产、引入迁移等——实际上你可以在 Laravel 应用程序中做的任何事情都可以通过 composer 包完成。
因此，您将采用在构建之间重复的功能，并将其提取到可通过 Composer 需要的“核心”包中。然后前端的东西可以在只需要你的核心代码库的项目中构建。当您更新主核心包时，您可以进入每个前端构建并通过 composer 拉入新版本的核心。这将使您有机会将新的核心版本一一推出到每个项目，确保您可以单独解决问题或适应这些项目的重大更改。
您的核心包还可以包含通常在您的客户端项目中重复使用的任何前端组件，因此理想情况下，您无需在前端项目之间重新编写任何代码。
使核心代码足够模块化以成为独立包可能具有挑战性，但我认为根据我对您的项目的了解，这是最有意义的。希望能帮助到你。