Please enable JavaScript.
Coggle requires JavaScript to display documents.
шаги к новой архитектуре (сборка админки и витрины из одних исходников
…
шаги к новой архитектуре
-
хранение конфигов
в админке
[Риск 1]
на бэке делаем апи-обертку над ecwid rest api,
которое позволяет с бэкенда сохранять/получать данные из ecwid app storage
-
-
-
в нашей админке
показываем конфиги из ecwid app storage, забирая их по rest api
сборка админки и витрины из одних исходников
(после перехода на js админку - см. связь) #
-
-
-
настроить деплои, чтобы админочная часть тоже грузилась на сервер
в рельсе добавить внешнюю ссылку на соответствующий артефакт.
к этому моменту разобраться с кэшированием [Риск 2]
трекать версию скриптов в sentry, чтобы сразу заметить проблему с кэшированием, если она возникнет
-
-
simcase-js-sdk
общие компоненты и логика для приложений. как для админки, так и для витрины
-
собирается в npm пакет, версионируется
[под попросом] так же хостится на cdn, если всё же есть необходимость подключать отдельно в админку/витрину
-
-
все js/css артефакты лежат на cdn.
бэкенд живет без статики (js/css) приложений, без сложной сборки js кода приложений внутри себя
см [Риск 2]
бэкенд
получает первый запрос с payload, сохраняет токен создает приложение, конфигурирует очереди
-
предоставляет api, если админке приложения нужно общаться с бэкендом в процессе работы
по api/configs/store_id возвращает конфиг приложения, который берется из ecwid application storage или из нашей базы
[Риск 1]
- внедряет в html store_id/token
- дает серверное api-обертку для ecwid application storage
админка
-
-
инициализируется (получает store_id, token)
-
[Риск 1]
из самого html, куда бэкенд предварительно внедрил эти данные
-
-
витрина
-
-
в процессе работы обращается к нашему бэкенд api, если необходимо
работа с окружениями
подмена урлов (катомным или, возможно, даже, готовым расширением)
-
user feature
помимо стандартного конфига приложения, который видит и настраивает пользователь, также у приложения есть скрытый конфиг, который настраиваем мы
такой подход позволяет очень удобно делать кастомы, включать фичи в тестовом режиме, делать А/Б тестирования, разрабатывать и быстро доставлять новые фичи в продакшен, даже если они еще не готовы к официальному релизу (можно проверить совместимость)
В данный момент ecwid js sdk дает не полную функциональность в серверной схеме интеграции. т.к. в серверной схеме нет хэша, из которого извлекается store_id и токен на фронте
как вариант, можно самим генерить такой хэш у себя. алгоритм шифрования на фронте у эквида симметричный, открытый и без секрета
-
если в html, который выдает бэкенд, просто отадавать ссылку на dashboard.js, а не dashboard-12r1t1ur3.js с хэшом, то есть риск выстрелить себе в ногу настройками кэша. нужно обратить на это внимание
если же идти по пути с хэшом, то надо чтобы базовый html генерировался рядом со скриптами, а бэкенд как-то должен на него редиректить после первого запроса с payload.
также не до конца понятно, как в такой схеме передавать store_id/token если [Риск 1] реализуется
в общем, вариант без хэша с прямой ссылкой выглядит сильно более привлекательно