Комментарии 17
Не могу понять, чем описанные подходы отличаются от модуля, плагина, библиотеки? Как по мне, ничем. Аналог микросервисов на фронте — это iframe. Пиши на любом фремворке или библиотеке. Текущие движения микрофронтенда создание нового хайпа, попытка назвать колбасу нечто новым и красивым именем)
<сарказм>Это слишком сложно, так надо архитектуру продумывать, тесты писать, зачем, если можно на каждую страничку или блок по проекту сделать и каждый будет по разному написан, со своим code style
</сарказм>
Давайте посмотрим на классическую схему, шаг за шагом:
- Команда/Проект
- Разработка
- Тестирование
- Публикация в NPM (NPM приватный)
- Оповещение других команд или обновление других проектов на новую версию
Как видно из списка, есть проблема в последнем пункте. Т/е как только мы опубликуем изменения, это не значит, что они будут доступны для использования. Т/е вам еще надо будет разослать уведомления командам, о том, вы опубликовали измения/багфиксы. И дождаться, когда другие команды обновят зависимости. Из реальной жизни пример — обновление на новые версии иногда занимает день-два. Это очень долго, поверьте мне.
Следующая проблема. Надо срочно откатиться на предыдущую версию. Бывают случаи, когда баг таки просочился на прод. Как быстро откатиться? Проблема.
Нет, такая схема с публикацией модуля/либы в NPM, прекрасно работает, когда у вас два-три тима. Но когда их уже за 10-к. Постоянно возникают задержки.
Вот один из путей решения — микрофронтенд. Где команда выкладывает JS билд (что-то типа myspa.com/app/component1.js), а приложение уже по необходимости, загружает отдельно файл в браузер.
Такой подход решает проблему публикации и отката версий, так как код сразу становися доступен после публикации.
По поводу IFrame. Да они тоже могут использоваться, но как решить проблему глобального стейта? Как красиво позволить компонентам обмениваться данными, реагировать на изменения? Не, не спорю — можно. Но будет ли это изящно — не факт :)
SPA проекты пробовали делить на dll(angular тема). Тоже попа). В итоге пришли снова на монолит). Единственное, что части проекта планируем выносить в отдельные репы и npm пакеты, чтобы разделить зону ответственности и снизить нагрузку при сборке основного проекта. Не стоит забывать и про фишки сборки, которые оптимизируют общий финальный код. По поводу мгновенной заливки изменения части общего проекта я против, пахнет отсутствием контроля и рисками грубых ошибок, сложно контролировать объемы кода. А так можно и эту часть автоматизировать.
По поводу IFrame. Да они тоже могут использоваться, но как решить проблему глобального стейта? Как красиво позволить компонентам обмениваться данными, реагировать на изменения? Не, не спорю — можно. Но будет ли это изящно — не факт :)
postMessage(), завернутый в "красивую обертку" с нужными интерфейсами?
Вспоминается проект из нескольких ифреймов по вынужденной причине, т.к. контент располагался на разных доменах и не мог работать с одного. В этом кроссфреймовом протоколе пришлось делать массу методов — для контроля отображения (мобильный, десктопный, версии для определенных устройств, тема), локализации, синхронизации событий (клики по управляющим элементам в верхнеуровневых фреймах передавать в дочерние и наоборот, т.е. двусторонний эвент-биндинг), синхронизации роутинга и состояния… Все это требовало значительного количества времени на поддержку, в десятки раз большего, чем в монолите с единым состоянием. Еще и с пробросом куки проблемы, с безопасностью (каждый метод нужно подписывать и строго определять, чтобы сторонние ресурсы не могли встроить себе и вызывать все что угодно, а это было критично для проекта — платежная система).
Я к тому, что можно, если нужно — но лучше не связываться.
Аналог микросервисов на фронте — это iframe.
С одной стороны, вы правы. Это аналог. Только, к сожалению, он не работает так, как хотелось бы с точки зрения пользовательского опыта и ускорения разработки. Iframe дает больше проблем, нежели использование обычных html-тегов как точек привязки.
Iframe больше помогает в безопасности, когда вы не доверяете сайту в iframe, этакая песочница, нежели удобный микросервис.
есть сервис который занимаеться раскидыванием запросов прокси на .net (у каждой части приложение свой publicPath), каждый кусок приложения это собранный webpack-ом проект с праметром library,
все общие куски выносим в npm пакеты.
В результате имеем на странице множестов webpack-рантаймов, все зависимости имеют свой namespace, есть центральное shell приложение которое при необходимости загружает нужные ему куски приложения (модули записываю свой роутинг в глобальную переменную).
При необходимости можно не включать общие зависимости в сборку модулей (webpack параметр externals).
В общем iframe — не лучший вариант :)
Ждем аналог докера для фронтенда и кубернтейтс-веб для управления всем этим зоопарком, а то слишком легко без этого
А также Mosaic уже не разрабатывается на сколько я знаю.
НО есть много плюсов:
— например для различных устройств вы можете отдавать различные микросервисы чтобы ваш микросервис работал максимально производительно и максимально удобно для данного устройства.
— можете легко сменить фреймворк
— программист погружается в работу только конкретного микросервиса
и много других плюсов.
Фронтенд-либы и общий код для разных страниц с микроприложениями доступны по общему пути (и кэшируются в браузере). Код, специфический для каждого микроприложения имеет свои папки.
Из плюсов — быстрый билд, простота отладки, модульность, отсутствие необходимости использования тяжелых frontend-first фреймворков там, где приоритетом является безопасность, гарантируемая логикой на сервере, но при этом нужен современный UX без перезагрузки страницы.
Из минусов — большая связность с бэкендом, роутинг не только на фронтенде (хотя это может быть единственным вариантом для лучшего SEO, если server-side rendering использовать нельзя из-за того, что бэкенд не на NodeJS).
11 инструментов для разработки микрофронтендов, о которых стоит знать