WedX - журнал о программировании и компьютерных науках

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

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

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

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

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

Второе решение, которое приходит мне на ум, это:

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

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

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


Ответы:


1

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

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

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

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

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

05.07.2018

2

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

Давайте назовем ваш основной продукт 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": "[email protected]:your-company/cms-front.git" } ], "config": { "github-oauth": { "github.com": "******" } } }

  • Добавьте зависимость yourcompany/cms-front@dev-$version в файл composer.

composer require yourcompany/cms-front@dev-chocolate

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

{ "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 в свои зависимости композитора.

  • Переключайтесь между темами, когда захотите.

06.07.2018
Новые материалы

Как создать диаграмму градиентной кисти с помощью D3.js
Резюме: Из этого туториала Вы узнаете, как добавить градиентную кисть к диаграмме с областями в D3.js. Мы добавим градиент к значениям SVG и применим градиент в качестве заливки к диаграмме с..

Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что это выглядит сложно…
Просто начните и учитесь самостоятельно Я хотел выучить язык программирования MVC4, но не мог выучить его раньше, потому что он кажется мне сложным, и я бросил его. Это в основном инструмент..

Лицензии с открытым исходным кодом: руководство для разработчиков и создателей
В динамичном мире разработки программного обеспечения открытый исходный код стал мощной парадигмой, способствующей сотрудничеству, инновациям и прогрессу, движимому сообществом. В основе..

Объяснение документов 02: BERT
BERT представил двухступенчатую структуру обучения: предварительное обучение и тонкая настройка. Во время предварительного обучения модель обучается на неразмеченных данных с помощью..

Как проанализировать работу вашего классификатора?
Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..

Работа с цепями Маркова, часть 4 (Машинное обучение)
Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..

Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..


Для любых предложений по сайту: [email protected]