Микро-интерфейсное приложение
У меня есть 1 проект, который разделен на несколько SPA, у меня 5 SPA, написанных на 2 на Angular, 2 на реакции и 1 на vue js. Теперь у меня есть интегрированный сервер, который будет обслуживать разные файлы в соответствии с маршрутизацией. Мне нужно передавать данные из одного приложения в другое с минимальным взаимодействием с базой данных. Это сценарий микро-интерфейсов. Надеюсь, это решит мою проблему.
Любая помощь будет оценена по достоинству.
Где этот mobx хранит данные, в локальном хранилище, файлах cookie или где-то еще? Как он обменивается данными между разными приложениями? это самый важный вопрос перед внедрением в проект.
Ответы 3
Есть три способа обмена данными:
- URL: параметры запроса / параметры пути (только для небольших данных, таких как идентификатор, фильтры и т. д.)
- Хранилище сеансов: используйте это, только если вы не переходите к другой вкладке / окну.
- Локальное хранилище: самый удобный и предпочтительный способ
Конечно, если вы сохраняете состояние в локальном хранилище, вам придется самостоятельно обрабатывать сброс состояния, когда пользователь выходит из системы.
Это немного болезненный процесс. Вам нужно будет написать код для управления сериализацией и десериализацией JSON в локальное хранилище. Чтобы упростить это, лучше, если у вас будет одно и то же решение для управления состоянием для всех микроприложений. Я рекомендую для этого использовать Redux / MobX. Но если вы используете Redux для React, Ng-Rx для Angular и Vuex для Vue, то готового решения у вас не будет.
Кроме того, когда вы сохраняете состояние в локальное хранилище, либо откажитесь от него, либо сделайте это лениво с небольшой задержкой по соображениям производительности.
Мы используем микро-интерфейсы в течение последних двух лет, и мы используем сочетание локального и сеансового хранилища для работы. К счастью, для всех приложений мы используем Redux, даже с Vue, и это позволяет нам использовать redux-localstorage.
Вы также можете использовать файлы cookie, но, как правило, их лучше избегать.
Данные, которые будут сохранены в localstorage, могут быть токеном jwt. Я думаю, что хранить токен и другие важные вещи на локальном хранилище - не лучшая идея. я могу сделать некоторые манипуляции, но есть ли способ, который не выставляет токен на стороне клиента?
@Amit, это JWT значит зашифровано. Никто не может прочитать его без ключа дешифрования. Так что вам не о чем беспокоиться. Кроме того, в тот момент, когда токен отправляется клиенту, храните вы его или нет, токен в любом случае будет открыт.
Я понимаю, что JWT зашифрован и может быть расшифрован с помощью ключа дешифрования, но он уязвим для XSS-атаки, потому что конфиденциальные данные открыты, что означает, что их можно копировать и делать запросы к нашим веб-сайтам, о которых мы, возможно, не знаем. Сторонняя библиотека JS может быть способом. Я не поддерживаю хранение JWT, или любые подобные данные не должны храниться в локальном хранилище. Любая другая вещь, которая может заменить локальное хранилище, решит мою проблему. Если я ошибаюсь, скажите, пожалуйста. И предложите, пожалуйста, любой другой вариант.
Да @ Амит, согласен. Если вы пользуетесь сторонним сервисом, то вы открыты для XSS. В этом случае вы просто не можете использовать что-либо, кроме файлов cookie. И ваши файлы cookie должны быть httpOnly cookie. Вам придется жить без JWT на стороне клиента. Нет другого пути без участия сервера в картине.
Да, я все еще ищу лучший подход. В любом случае спасибо.
@IoneWolf Храните свои токены в файлах cookie с помощью httpOnly. Таким образом, они не подвержены XSS-атакам и прозрачно устанавливаются браузером, то есть в течение одного сеанса они будут доступны для всех ваших различных SPA.
Не понимал, как привязка токена с файлами cookie не будет подвержена XSS. Если как злоумышленник, я могу внедрить свой JS. Я могу разговаривать с любыми ресурсами с сервером, и браузер с радостью прикрепит Cookie (токен). В любом случае у меня есть доступ к Токену прямо или косвенно.
@prabhatojha Используйте безопасный файл cookie вместе с флагом httpOnly. Это предотвращает чтение со стороны клиента. Кроме того, механизм CORS + CSRF предотвратит проблемы с перекрестными доменами.
Другой вариант - использовать шину событий внешнего интерфейса, например EEV. Оболочка вашего приложения будет отвечать за создание общего прослушивателя событий. Тогда каждый микро-интерфейс может отправлять события на этом общем канале.
Вы также можете использовать RxJS Subject в качестве шины сообщений в вашей оболочке приложения и подписаться на нее в приложениях Micro Frontend. Вот пример
Надеюсь, это даст вам пару дополнительных идей.
Я столкнулся с тем же сценарием, когда мне нужно передать данные из одного микроприложения в другое. и после большого количества исследований и разработок я обнаружил, что коммуникация на основе событий является лучшей, когда я передаю данные в форме на объектах событий. вот пример: Для отправки данных:
var event = new CustomEvent('userData', { "detail": { "id": id, ...rec } });
window.dispatchEvent(event);
а для получения данных в другом приложении:
window.addEventListener("userData", function (e: CustomEvent) {
this.id = e.detail.id;
this.country = e.detail.country;
this.contact = e.detail.contact;
this.company = e.detail.company;
this.changeDetectorRef.detectChanges();
}.bind(this));
Этот подход не требует связи с БД.
Надеюсь, это решит ваш вопрос !!!
Вы можете разделить общий магазин между ними. например: mobx совместим со всеми из них