Всем привет, меня зовут Иван и я фронтенд-разработчик из компании DexSys.

На моём комментарии про микрофронтенды набралось целых три лайка, поэтому я решил написать статью с описанием всех шишек, что наш стрим набил и набивает в результате внедрения микрофронтендов.

Начнём с того, что ребята с Хабра (@artemu78, @dfuse, @Katsuba) уже писали про Module Federation, так что, моя статья - это не что-то уникальное и прорывное. Скорее, это шишки, костыли и велосипеды, которые полезно знать тем, кто собирается использовать данную технологию.

Привет, меня зовут Ваня, недавно я выступил на CodeFest 11, где рассказал про путь Тинькофф Бизнеса на фронтенде от одного приложения к сотне. Но, так как в ИT очень быстро все меняется, а ждать запись еще долго, сейчас я тезисно расскажу о нашем шестилетнем путешествии в дивный мир микрофронтенда!

Привет, Хабр! В Netcracker мы уже давно используем микрофронтендную архитектуру, и с 2017 года начали разрабатывать собственный платформенный инструмент построения микрофронтендов.

Недавно на митапе мы показывали, как делать сложные приложения, разрабатываемые разными командами в разных релизных циклах и даже технологиях. В режиме live coding соединили Angular, React и Vue в одном SPA. Было много вопросов про Webpack Module federation. Поскольку мы уже переходим на этот фреймворк, здесь мы поделимся наработками, как сделать Angular host application + React/Angular/Vue microfrontends с возможностью независимого версионирования зависимостей.

Каждый месяц новый митап! 

Готовьтесь к RamblerMeetup&Frontend. 29 июля эксперты в области frontend-разработки поделятся своим опытом и ответят на ваши вопросы.

Митап пройдет в онлайн-формате, начало в 19:00. Обязательна предварительная регистрация на Timepad.

Мы в KTS делаем проект для Пятерочки – новый личный кабинет сотрудника. Продукт объединяет уже существующие сервисы и автоматизирует бизнес-процессы, которые раньше выполнялись вручную.

Над личным кабинетом работает много команд, поэтому нужен удобный механизм параллельной разработки модулей-микрофронтендов. Мы попробовали три способа встраивания: iframe, NPM-пакеты и Webpack Module Federation. В статье анализируем преимущества и недостатки каждого из них и рассказываем, почему переходили от одной технологии к другой.

По мотивам вопросов из предыдущей статьи мы решили написать вторую часть и рассказать, что удалось сделать еще.

На повестке дня:

• Роутинг хостового приложения (React/Vue Routing внутри Angular)

• Полноценные адаптеры для работы удаленных плагинов

• Использование сервисных модулей в рантайме

Все говорят про webpack-module-federation - микрофронты тут, микрофронты там.
— "А мы уже внедрили", "а мы уже построили микрофронтовую-архитектуру", "мы релизим независимо".

Но начинаешь расспрашивать, "а что сделали", "а как связали" - выходит что за всеми этими броскими фасадами скрывалось добавление вызова ModuleFederationPlugin(...) на уровне рядового потребителя, в лучшем случае с подстройкой конфигурации под локальный и продуктовый стенды. А независимые релизы - обычный авто деплой trunk'а.

На этом фоне доклады, повествующие о динамическом развертывании k8s pod'ов с версиями микрофронтов, указанных в заголовках браузера (на базе argo-cd) производят вау-эффект. Но даже все эти истории имеют один общий недостаток.

На вопрос:
— А как вы реализовали SSR?

Следует ответ:
— Мы не стали этого делать, у нас админка / дэшборд / MVP / *.

Привет! Недавно у нас в компании завершилось RnD по микрофронтендам, мы посмотрели подходы, протестировали некоторые идеи, и хотим поделиться с вами результатами. Если вы сейчас выбираете подход для использования микросервисов на фронтенде, этот пост может вам пригодиться как сводное сравнение особенностей, плюсов и минусов четырёх основных подходов.

Когда мы пытались понять потребности и присматривались к тому, какие решения в этой области есть у других, мы прошлись по компаниям, посмотрели, какие подходы в сфере микрофронтенда они используют. Несколько компаний приходили к нам и презентовали нам свои решения. Но так как большинство из этих решений были самописными, мы решили отказаться от рассмотрения данных концепций и посмотреть стандартные подходы.

И вот к чему мы пришли.

Мы выделили три основных потребности разработки на микрофронтенде.

1. разделить большие команды разработки фронтендов на несколько;

2. разрабатывать большие портальные приложения;

3. сократить порог входа в разработку для фронтенд‑разработчиков.

Подходов, которые мы рассмотрели, было четыре:

1. Single SPA,

2. Module Federation,

3. NPM modules,

4. Git Submodules.

Привет! С вами снова Максим. Во второй части будет о том, что мы придумали.

Когда мы решили пилиться после сбоя, про который я рассказал в первой части, начали с личного кабинета. Его попилить на микрофронтенды легко, потому что мы разделили весь код по модулям, замкнув бизнес-логику в конкретном модуле, и вынесли общие части в общие библиотеки. Осталось достать пилу и отпиливать модули — делать их отдельными приложениями.

Привет! Меня зовут Алексей. Я занимаюсь проектированием фронтенд-составляющей ИТ-систем в архитектурном комитете SimbirSoft. Последние два-три года во фронтенд-сообществе активно обсуждается и используется термин «микрофронтенд» (далее МФ). Разные компании делятся своими подходами к организации подобного архитектурного решения, но до сих пор в Сети мало описания проблематики, которую призваны решить МФ-ы, критерии их применимости и ограничения в использовании. В этой статье постарался сравнить разные способы организации МФ-ов, а также сформировать рекомендации, где какой подход использовать.

Материал может быть полезен как аналитикам и командам разработки при проектировании архитектуры на проекте и закладки процессов, так и владельцам продуктов, поскольку внедрение МФ-ов может дать более управляемую разработку.

Привет! Меня зовут Максим, я фронтенд-разработчик компании Тинькофф, лид команды фронтендов, которые пилят международные проекты. Я работал как фронтом, так и бэкером — это дало мне релевантный опыт и в микрофронтендах в том числе.

Статья будет о фронтендах, но сначала предлагаю немного обсудить монолиты. Они бывают разные.

Коллективу Альфа-Банка и корпоративным коммуникациям больше 30 лет. За нашу историю накопилось огромное количество систем, которые внедрялись разными командами. Отпуска мы планируем в SAP HCM, командировку оформляем в SAP АХД, кандидатов ведём в E-Staff, обучение проходим в WebTutor — список внушительный. Что это значит для сотрудника? У каждой системы свой интерфейс, и нужно разбираться, где что находится. Неудобно.

Неудобства проявлялись не так явно, когда команда собиралась в офисе. В нём проще выдать доступы, бэйджи, распечатать заявления, отнести на подпись, забрать. Но весной 2020-го, когда все ушли на удалёнку, появились пробелы в коммуникациях и процессах. При этом в пандемию мы также должны были нанимать, но без визита в HR и вовлекать в корпоративную жизнь сотрудников, работающих из дома. В статье расскажем, как мы решили эти проблемы, создав единую площадку, где можно оформить документы, начислить премию или забронировать место в коворкинге.

Материал будет больше полезен HR и руководителям.

Module Federation — это подход, при котором можно разделить приложение на небольшие отдельные модули и в рантайме объединять в единое приложение. Это одно из немногих рабочих решений для разработки микрофронтендов. Почему оно лучше, чем остальные, какие еще решения для микрофронтендов существуют, что вообще такое микрофронтенды и зачем они нам нужны, расскажу в статье. В конце поделюсь полезными ссылками на статьи, видео и документацию, которые помогут углубиться в тематику Module Federation.

Так же будет немного практики. Настоятельно рекомендую самостоятельно опробовать технологию чтобы материал хорошо закрепился в памяти. Практика наше все!

Всем привет. Меня зовут Михаил, я - фронтенд-разработчик в Лиге Цифровой Экономики.

В последнее время я пробую себя в должности руководителя направления фронтенд-разработки, однако я хочу с вами поделиться опытом разработки приложения с применением Webpack Module Federation, о том, какие задачи приходилось решать и проблемы, которые возникли на этом пути. Не буду вдаваться в теорию о микрофронтах и module federation, об этом уже много написано и предполагается, что вы знакомы с базовой настройкой. Мы же поговорим о самом «вкусном», некоторые моменты будут опущены в целях сосредоточения на деталях.

Всем привет! Меня зовут Евгений, я работаю frontend-разработчиком в платформенной команде. Моя задача — помогать другим frontend-разработчикам выполнять их задачи эффективнее. Мы в Delivery Club больше года назад внедрили подход с микрофронтендами, о чём писали здесь. Вы можете найти и много других статей с описанием этого подхода.

После выхода стабильной версии Webpack 5 мы решили использовать плагин Module Federation в качестве основного способа загрузки микрофронтендов. В этой статье расскажу, с какой проблемой столкнулся при загрузке динамических модулей и как её решил. Описывать будут на примере плагина Module Federation во всех деталях. Если вы слышите про этот инструмент впервые, то советую предварительно ознакомиться.

Фронтенд-разработка может жить без независимого деплоя, пока у нее не больше 7 микрофронтендов. Но, чем выше число, тем сильнее страдают процессы. Наша команда в Mindbox прошла через это с Octopus, когда деплоила в Yandex Cloud S3. Причем на все обновления был один свободный бакет. Заливаешь код в мастер, а в это время то же самое делают еще пять разработчиков. Скапливается очередь, код еле ползет, а через час деплой вообще обваливается — Octopus не справился с нагрузкой. Пока чинишь это, оказывается, что твои обновления уже попали в продакшен заодно с чужими. 

Когда число проектов возросло до 14, все это повторялось с каждым разработчиком по несколько раз в день. Поэтому мы решили вслед за коллегами-бэкендерами перейти на независимый деплой в Kubernetes.

В этой статье собран опыт платформы автоматизации маркетинга Mindbox по реформированию фронтенда:

Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев

Автоматизированный вывод метаданных: экономим ресурсы разработки

Постепенный переход: меняем деплой без вреда для пользователей

Хот-тестинг: ускоряем обновление фронтенда

Советы: как улучшить деплой без микрофронтендов и Kubernetes

Привет, Хабр! Этот пост подготовили два разработчика Росбанка — Максим из команды развития фронт-офисных систем и Никита из команды интернет-банка. Речь пойдет о том, как мы делаем микрофронтенды. Сначала расскажем про опыт интеграции в существующий проект, а потом про внедрение с нуля.

Всем привет! На связи Максим Смирнов, архитектор по фронтенду в Тинькофф. В серии статей будет история о том, как мы переписывали один из монолитных сервисов на Federation.

Расскажу о том монолите, который переписали, и как дошли до момента, что надо распилиться. Еще покажу, какие фишки мы накрутили в Module Federation, потому что из коробки многих фич нет, надо докручивать самим. Добро пожаловать под кат!

В последнее время только ленивый не говорил про такую технологию, как module federation, было сделано огромное количество докладов, и наша команда, наслушавшись и насмотревшись, как это прекрасно, тоже решила затащить MF к себе в проект.

Однако, почти все доклады на эту тему не показывают серьезность проблем, с которыми можно столкнуться на пути.

В этой статье будет рассказано вкратце, для тех, кто ещё не знает, что такое module federation, в каких ситуациях его стоит использовать, как настроить продакшен сборку, а не только локальную, ну и какие проблемы вас могут ждать.

Начнем!

Microfrontend as it supposed to be: Single Page Application, Server-side rendering and Independent deployments.

Example that proves it's possible using React 18 + Suspense on server and Webpack Module Federation