Спасибо за статью. Очееь интересно было почитать про применение Proxy (не работал с ним).
Судя по комментариям, многие смешивают понятия.
Если правильно понял, то в статье описывается, как можно не писать многочисленные функции запроса на сервер, а генерировать их из иньерфеса. Обработка входных данных и результата происходит уже в сервисном слое...а никак не в api.
Карты, плеер и чаты встраиваются посредством iframe, являются сторонними приложениями и, зачастую, не требуют взаимодействия с основным приложением. Только карту приходится перезагружать, если координаты поменялись.
Микрофронты - это аналог микросеовисов на бэке. То есть мы разделяем наш монолит на несколько независимых кусков со своей логикой. Каждый кусок предлставляется полностью или в виде отдельных компонентов основному приложению. Можно и в виде фреймов это сделать, но получим просадку по производительности, если их будет много на странице.
Согласен с Вами. Если возьмем к примеру React, то насколько я знаю, компонент перерендерится, если поменяются пропсы. А если мы их забираем из store, то и компонент внутри которого расположен remote компонент тоже перерендерится.
Что касается чистого js, html, то да. Нужен механизм подписки. Цель этой статьи - показать что такое микрофронты, с чего начать и как настроить самые базовые вещи. Организация store тянет на отдельную статью с обзором всех возможных вариантов.
Добрый день. Спасибо за комментарий. Смысл микрофронтов в том, чтобы разделить большой монолит на несколько маленьких приложений со своей бизнес-логикой. Микро-приложения могут быть написаны на разных фреймворках, с разными библиотеками. Другой вариант, это несколько приложений запускаются в рамках одного.
Iframe частично решают ту же проблему, но у них есть множество ограничений и проблемы с производительностью. Подробнее можете прочитать в статье по ссылке
Я как раз предлагаю делать глобальный стор внутри host приложения.
Отличие лишь в том, что прокидывать экземпляр хранилища в remote приложения не очень хорошая идея, потому что мы диктуем remote какую библиотеку и архитектуру для хранилища использовать. А в статье, я хотел поставить упор на независимости remote приложений от host.
Вообще шаринг стора между host и remote довольно сложная штука. Надеюсь, что сообществом будет выработан удобный и самый оптимальный подход для этого
Возможно плохо проработал этот момент. Я с Вами полностью согласен. Имелось ввиду, что стор в host приложении хранит данные, которые нужны многим remote компонентам. И эти данные прокидывать в компоненты в виде пропсов.
В этом случае мы можем потерять немного в оптимизации, но минимизируем сложность поддержки хранилища в виде отдельного remote приложения.
Спасибо за статью. Очееь интересно было почитать про применение Proxy (не работал с ним).
Судя по комментариям, многие смешивают понятия.
Если правильно понял, то в статье описывается, как можно не писать многочисленные функции запроса на сервер, а генерировать их из иньерфеса. Обработка входных данных и результата происходит уже в сервисном слое...а никак не в api.
Спасибо
Карты, плеер и чаты встраиваются посредством iframe, являются сторонними приложениями и, зачастую, не требуют взаимодействия с основным приложением. Только карту приходится перезагружать, если координаты поменялись.
Микрофронты - это аналог микросеовисов на бэке. То есть мы разделяем наш монолит на несколько независимых кусков со своей логикой. Каждый кусок предлставляется полностью или в виде отдельных компонентов основному приложению. Можно и в виде фреймов это сделать, но получим просадку по производительности, если их будет много на странице.
Микрофронты - уже достаточно устоявшийся термин)
Согласен с Вами. Если возьмем к примеру React, то насколько я знаю, компонент перерендерится, если поменяются пропсы. А если мы их забираем из store, то и компонент внутри которого расположен remote компонент тоже перерендерится.
Что касается чистого js, html, то да. Нужен механизм подписки. Цель этой статьи - показать что такое микрофронты, с чего начать и как настроить самые базовые вещи.
Организация store тянет на отдельную статью с обзором всех возможных вариантов.
Добрый день. Спасибо за комментарий.
Смысл микрофронтов в том, чтобы разделить большой монолит на несколько маленьких приложений со своей бизнес-логикой. Микро-приложения могут быть написаны на разных фреймворках, с разными библиотеками.
Другой вариант, это несколько приложений запускаются в рамках одного.
Iframe частично решают ту же проблему, но у них есть множество ограничений и проблемы с производительностью. Подробнее можете прочитать в статье по ссылке
Спасибо за комментарий)
Добрый день. Спасибо за комментарий.
Возможно плохо проработал этот момент.
Я как раз предлагаю делать глобальный стор внутри host приложения.
Отличие лишь в том, что прокидывать экземпляр хранилища в remote приложения не очень хорошая идея, потому что мы диктуем remote какую библиотеку и архитектуру для хранилища использовать. А в статье, я хотел поставить упор на независимости remote приложений от host.
Вообще шаринг стора между host и remote довольно сложная штука. Надеюсь, что сообществом будет выработан удобный и самый оптимальный подход для этого
Добрый день. Спасибо за комментарий.
Возможно плохо проработал этот момент. Я с Вами полностью согласен. Имелось ввиду, что стор в host приложении хранит данные, которые нужны многим remote компонентам. И эти данные прокидывать в компоненты в виде пропсов.
В этом случае мы можем потерять немного в оптимизации, но минимизируем сложность поддержки хранилища в виде отдельного remote приложения.
Возможно не так понял комментарий