Разделение внешнего интерфейса Laravel + Vue с помощью дополнительного рендеринга на стороне сервера

Question

Допустим, есть CMS, созданная с помощью Laravel. Мы будем предоставлять различным клиентам ту же CMS, обновлять их CMS при каждом выпуске, который мы создаем, но у нас есть файл конфигурации, который будет определять, какие функции доступны для каждого клиента. Весь бэк-офис (панель администратора и т. Д.) Будет в основном статичным и будет использовать Vue только для определенных динамических элементов. Это решение удовлетворяет наши потребности, когда дело доходит до серверной части.

Однако мы планируем развертывать различные интерфейсы конечных пользователей для каждого из этих клиентов. Разъединить эти звуки очень просто (создайте совершенно отдельный проект внешнего интерфейса и используйте конечные точки API для динамического извлечения и рендеринга всего), но если бы мы полностью отделили внешний интерфейс и внутренний интерфейс, мы потеряли бы возможность рендеринга статических страниц с помощью Laravel Blade, и нам нужно эта функция для определенных страниц из-за скорости рендеринга, времени загрузки, SEO и т. д.

Основной вопрос: как отделить интерфейс от бэкэнда для каждого клиента, не теряя возможности отображать страницы с помощью Laravel и Blade, сохраняя при этом простоту разработки и тестирования?

Одним из решений, которое приходит мне в голову, является создание шага после сборки, в котором мы «объединяем» файлы клиентского интерфейса в CMS, но это усложнит процесс разработки или даже сделает все это практически невозможно разработать и испытать.

Второе решение, которое приходит мне в голову:

1. Храните все в одном Git-хранилище.
2. Разрабатывайте CMS в собственной ветке и разрабатывайте только бэкэнд и бэк-офис для этой ветки и ее дочерних элементов.
3. Создание отдельных веток ( Какова лучшая практика для помещения нескольких проектов в репозиторий git? Возможно, некоторые из представленных здесь решений?) Для различных интерфейсов конечного пользователя и разработка только интерфейса конечного пользователя на эти ветви.
4. Слияние ветки CMS с ветками клиента при каждом выпуске.

Это решение кажется жизнеспособным и позволит нам использовать Laravel Mix и рендеринг на стороне сервера, но оно очень подвержено человеческим ошибкам и очень усложнит отслеживание этих ветвей через некоторое время. Одно из других потенциальных решений, о которых я читал, - это использование подмодулей Git, но мне просто трудно понять, как это работает, и кажется, что это не так гибко, как должно быть в этом случае использования.

Что было бы для нас лучшим архитектурным решением?

Answer 1

Когда вы отсоединяете свою систему, я настоятельно рекомендую не выбирать самое простое решение без предварительной гарантии того, что оно может масштабироваться и (как одна из ваших проблем) легко тестируется.

Давайте назовем ваш основной продукт CMS vanilla, он работает как положено и задумано. Теперь у вас есть CMS Chocolate, который немного отличается от внешнего интерфейса, вот что я сделал:

• Храните тему пользовательского интерфейса (файлы шаблонов, изображения, js, css и т. Д.) В одном репозитории (например, yourcompany / cms-front) и каждую версию в отдельной ветке (v-vanilla, v-chocolate, v-strawberry )
• В вашей теме пользовательского интерфейса вам нужно будет включить простой файл composer.json для описания проекта
• В вашем проекте CMS присвойте каждой версии собственную ветку, а имя принудительной версии соответствует имени соответствующего макета.
• Ссылка на ваш передний репозиторий в вашем cms composer.json, я предполагаю, что мы говорим здесь о частном репозитории, иначе следующие строки не будут необходимы.

{ "repositories": [ { "type": "vcs", "url": "git@github.com:your-company/cms-front.git" } ], "config": { "github-oauth": { "github.com": "******" } } }

• Добавьте зависимости вашегокомпании / cms-front @ dev- $ version в ваш композитор.

composer require yourcompany/cms-front@dev-chocolate

• Вам потребуется шаг после сборки, чтобы скопировать версию vendor / your-company / cms- $ в ваш проект, но это просто

{ "scripts": { "sync-theme": [ "cp -r vendor/your-company/cms-front/resources app/resources", "cp -r vendor/your-company/cms-front/public app/public", ], "post-install-cmd": [ "@sync-theme" ], "post-update-cmd": [ "@sync-theme" ] } }

• Добавьте yourcompany / cms-front @ dev- $ version в зависимости вашего композитора.

• Переключайтесь между темами в любое время.

Answer 2

Я бы подумал о вашей CMS как о пакете и о ваших различных интерфейсных компонентах как об отдельных проектах, каждый из которых зависит от вашей CMS. Например, я использую Backpack for Laravel для ряда проектов: https://github.com/Laravel-Backpack/CRUD, который, как мне кажется, похож на то, что вы описываете - общий набор основных функций с непродуманным внешним интерфейсом.

Пакеты Laravel могут регистрировать маршруты, публиковать представления и ресурсы, выполнять миграцию и т. Д. И т. Д. - на самом деле все, что вы можете сделать в приложении Laravel, можно сделать с помощью пакета композитора.

Таким образом, вы берете функциональность, которая повторяется между вашими сборками, и извлекаете ее в «базовый» пакет, который может потребоваться через composer. Затем интерфейсные компоненты могут быть встроены в проекты, которые просто требуют вашего базового кода. Когда вы обновляете свой основной пакет ядра, вы можете перейти к каждой внешней сборке и загрузить новую версию ядра через композитор. Это дало бы вам возможность поочередно развертывать новую базовую версию для каждого проекта, гарантируя, что вы сможете решать проблемы или приспосабливаться к критическим изменениям в этих проектах по отдельности.

Ваш базовый пакет может также включать любые внешние компоненты, которые обычно повторно используются в ваших клиентских проектах, поэтому в идеале вы не должны переписывать код между внешними проектами.

Может быть сложно сделать этот базовый код достаточно модульным, чтобы он представлял собой отдельный пакет, но я думаю, что это имеет смысл, исходя из того, что я понимаю о вашем проекте. Надеюсь, это поможет.