Комментарии 17
удалил (не туда написал)
Можно сделать отдельное приложение, которое будет предоставлять хранилище, и раздать его всем удалённым приложениям. На мой взгляд, это лишняя связность, которой следует избегать.
Предлагаю передавать такие данные в удалённые компоненты в виде props, а в функции — в параметрах. В итоге мы получим для удалённых модулей независимость от глобального store.
На фронте все хранилища - реактивные. С пропсами вся реактивность потеряется.
Добрый день. Спасибо за комментарий.
Возможно плохо проработал этот момент. Я с Вами полностью согласен. Имелось ввиду, что стор в host приложении хранит данные, которые нужны многим remote компонентам. И эти данные прокидывать в компоненты в виде пропсов.
В этом случае мы можем потерять немного в оптимизации, но минимизируем сложность поддержки хранилища в виде отдельного remote приложения.
Возможно не так понял комментарий
Допустим вы держите в host параметры isAuthenticated и user
Вы не можете их прокинуть как пропсы, которые просто передадутся по значению, потому что микрофронтенды должны сразу знать, когда их состояние изменится. Поэтому нужно что-то типа pub-sub подписки на события и возможность самим обновлять общие данные
Согласен с Вами. Если возьмем к примеру React, то насколько я знаю, компонент перерендерится, если поменяются пропсы. А если мы их забираем из store, то и компонент внутри которого расположен remote компонент тоже перерендерится.
Что касается чистого js, html, то да. Нужен механизм подписки. Цель этой статьи - показать что такое микрофронты, с чего начать и как настроить самые базовые вещи.
Организация store тянет на отдельную статью с обзором всех возможных вариантов.
Спасибо за контент, просто понятно, для чайников ыы :3
Спасибо за туториал!
Вы написали про отдельное приложение, которое будет предоставлять хранилище - не лучше ли сделать глобальный стор, например для авторизации, частью хост-приложения?
Если вы отдаёте хосту код, который инициализирует remote react-/vue-приложение, то в параметры ф-ции (условно bootstrapApplication) можно прокинуть экземпляр стора. В том же vue есть замечательный DI.
Само хранилище может быть спроектировано с использованием паттерна CQRS.
Добрый день. Спасибо за комментарий.
Возможно плохо проработал этот момент.
Я как раз предлагаю делать глобальный стор внутри host приложения.
Отличие лишь в том, что прокидывать экземпляр хранилища в remote приложения не очень хорошая идея, потому что мы диктуем remote какую библиотеку и архитектуру для хранилища использовать. А в статье, я хотел поставить упор на независимости remote приложений от host.
Вообще шаринг стора между host и remote довольно сложная штука. Надеюсь, что сообществом будет выработан удобный и самый оптимальный подход для этого
Пробежался по началу статьи и не понял сути. Ок, про фреймы понятно. Далее, непонятно.
Есть виджеты. Есть компоненты. В чём отличие микрофронта от этого?
YandexGo приложением пользовались? Там внутри одного приложения можно запустить другое как часть его - например Яндекс.Еда. Так вот это оно.
Добрый день. Спасибо за комментарий.
Смысл микрофронтов в том, чтобы разделить большой монолит на несколько маленьких приложений со своей бизнес-логикой. Микро-приложения могут быть написаны на разных фреймворках, с разными библиотеками.
Другой вариант, это несколько приложений запускаются в рамках одного.
Iframe частично решают ту же проблему, но у них есть множество ограничений и проблемы с производительностью. Подробнее можете прочитать в статье по ссылке
Меня интересует терминалогия.
Если обобщить, то мы говорим о модульность.
Есть старые понятия.
Виджет, то что встраивается в нечто другое и является полноценной штукой. К ним, например, всякие гугл карты, ютуб плеер, чаты поддержки, прогнозы погоды и другие сервисы можно отнести. Здесь больше смысловая часть.
Есть понятие компонента - создание какого то модуля, который будет использоваться системой в целом. В каждом фреймворке оно может быть своё или веб-компоненты. Здесь больше техническая часть.
То что тут описали:
YandexGo приложением пользовались? Там внутри одного приложения можно запустить другое как часть его - например Яндекс.Еда. Так вот это оно.
Смысл микрофронтов в том, чтобы разделить большой монолит на несколько маленьких приложений со своей бизнес-логикой. Микро-приложения могут быть написаны на разных фреймворках, с разными библиотеками.
Другой вариант, это несколько приложений запускаются в рамках одного.
Терминами "виджет" и "компонент" можно описать.
Почему понадобился ещё один термин "микрофронт" и в чём его отличие от двух первых? Может я слишком долго спал и сейчас уже по другому говорят?
В догонку, чем это от микросервисов отличается?
Карты, плеер и чаты встраиваются посредством iframe, являются сторонними приложениями и, зачастую, не требуют взаимодействия с основным приложением. Только карту приходится перезагружать, если координаты поменялись.
Микрофронты - это аналог микросеовисов на бэке. То есть мы разделяем наш монолит на несколько независимых кусков со своей логикой. Каждый кусок предлставляется полностью или в виде отдельных компонентов основному приложению. Можно и в виде фреймов это сделать, но получим просадку по производительности, если их будет много на странице.
Микрофронты - уже достаточно устоявшийся термин)
Сделать в том, чтобы общие библиотеки и модули иметь. У вас куча "виджетов", которые хочется собирать отлаживать и выкладывать независимо, но при этом сохранить общие зависимости и возможность удобного доступа к общим данным, функциям и там. Сей золотой костыль решает именно эту проблему. В целом штука в некоторых случаях очень интересная.
Спасибо за понятную и интересную статью)
Микрофронтенд для самых маленьких