Итак, что я хотел бы здесь сделать, это объяснить потребности нашего приложения и описать реализацию, которую я придумал до сих пор. Нужны советы по улучшению реализации, где это возможно.
У нас есть White Label или основной продукт / приложение. Затем у нас есть несколько клиентов, которые используют приложение, но со своими темами и конфигурацией.
В новой версии, которую мы разрабатываем, мы хотим создать то, что я называю Configuration Manager . Configuration Manager будет содержать много подробностей о клиенте, в том числе:
- Клиентская конфигурация (включение / выключение разделов и т. Д.)
- Строки перевода (изменение текста в приложении для клиента)
- Тематическая настройка (возможность изменения цвета сайта, настройка SASS)
- Конфигурация контента (подключается к внешней безголовой CMS для статей / меню / и т. Д.)
Следует иметь в виду, что для каждого клиента у нас есть несколько сред, в том числе dev, staging, UAT и production.
В идеале, Configuration Manager - это место, где мы можем управлять всеми конфигурациями для клиента и даже синхронизировать эти конфигурации в разных средах. Вот пример того, что может произойти:
- Клиент ABC хочет включить новый раздел приложения
- Dev может перейти в свою версию менеджера конфигурации и включить этот новый раздел и, возможно, просто быстро убедиться, что раздел работает должным образом и цвета правильные
- Затем мы хотели бы применить то же изменение к промежуточному серверу, чтобы позволить QA выполнить некоторые тесты
- Кроме того, примените то же самое изменение к серверу UAT, чтобы позволить клиенту проверить изменение
- Наконец, примените изменение к производству
Когда речь заходит о Configuration Manager, мой первый настоящий вопрос здесь заключается в том, знает ли кто-нибудь об инструменте, который можно использовать для этих целей. По сути, необходимо хранить данные JSON в БД.
Следующий реальный вопрос - как Основное приложение получит эти данные? Очевидный способ заключается в том, чтобы подключить конечную точку от основного приложения к диспетчеру конфигурации, чтобы получить конфиги сайта, переводы, контент (статьи и меню) и т. Д. В этом случае мы, очевидно, хотели бы реализовать какое-либо кэширование, поскольку существует нет причин захватывать меню при каждой загрузке страницы, особенно учитывая, что меню не будет часто меняться (как и другие конфигурации).
Тем не менее, я думаю, что было бы лучше, если бы основное приложение имело процесс сборки, который учитывал все конфигурации (из диспетчера конфигурации) при создании сборки. Мы используем gulp в нашем процессе сборки, поэтому мы можем использовать те же конечные точки в Configuration Manager, чтобы получить все те конфигурации, которые нам нужны для создания основного приложения.
Есть и другие части приложения, но я не слишком беспокоюсь о том, как эти части будут работать. Они включают:
- Подключение к API из основного приложения для данных
- Каждый экземпляр основного приложения имеет прилагаемое приложение системы проектирования
Я также скажу, что в настоящее время мы планируем построить Основное приложение, используя next.js, и Configuration Manager в nuxt.js.