Сейчас понятие «микрофронтенды» встречается довольно часто, но что это такое и какие задачи они решают? Зачем нам микрофронтенды, если есть микросервисы или монолит? И стоит ли тащить микрофронтенды в свой проект только потому, что это модно? Расскажу об этом, а также о трёх способах организации микрофронтендов: Podium, Single-SPA и Module Federation. Какой среди них лучший и нашли ли разработчики в нём панацею? Об этом читайте под катом.

Перед тем как начать, буквально пару слов о себе. Меня зовут Зар Захаров, я ведущий разработчик ВКонтакте. Занимаюсь разработкой с 2006 года, когда ещё выходили статьи с заголовками «Блочная вёрстка: миф или реальность».

С тех пор я работал в стартапах, крупных enterprise-проектах, на фрилансе и в аутсорсе. За это время накопил большой опыт, который позволяет сравнить разные способы разработки приложений и рассказать об их плюсах и минусах.

 

Что будет в статье

Архитектуры приложений

Мы разрабатываем сайты, но уже привыкли называть их приложениями. В архитектуре любого приложения чаще всего есть три главные части:

• множество библиотек и, как следствие, большое количество зависимостей;
• один общий store, который помогает нам обмениваться между компонентами, страницами и т. д., а также хранить информацию из базы данных;
• разные компоненты, которые необходимо собрать вместе, чтобы сделать из них приложение.

Собрать все эти части можно несколькими способами. Остановлюсь на каждом подробно.

Монолит

Когда мы только начинаем разрабатывать приложение, есть несколько вариантов, как его собрать. Один из них — монолит. Представим, что мы сделали MainPage — главную страницу.

У MainPage есть внутренний роутинг, но пока всё равно это одна страница. А что, если сделать вторую, например AboutPage? Тогда все компоненты, библиотеки и хранилище придётся расширять.

То же самое будет, если мы добавим ещё кучу страниц. Это и называется монолитом. 

У монолитной архитектуры есть свои плюсы:

• её легче реализовать;
• доступны E2E-тесты;
• её легко развёртывать и масштабировать;
• можно использовать единый фреймворк.

Но у монолита есть и недостатки:

• он часто перерождается в «большой шарик грязи» — становится так много всего, что непонятно, как со всем этим работать;
• его компоненты растут и меняются вместе с ним — когда мы поменяли что-то одно в архитектуре, надо менять и другие части;
• масштабирование может быть проблематичным: чем больше проект, тем сложнее с ним взаимодействовать;
• в монолите практически нет изоляции, и все части сильно зависят друг от друга — если что-то произойдёт с одной частью, то и другие тоже встанут.

Неповоротливость монолита в какой-то момент стала утомлять, и тогда появились микросервисы.

Микросервисы

При микросервисном подходе разработчики разворачивают отдельно независимые страницы, которые существуют в единой системе. Важно понимать — хоть они и разделены в архитектуре, но всё равно тесно взаимосвязаны. Допустим, мы заходим в приложение, а внутри открываем ещё какое-то мини-приложение.

В этом случае у приложения могут быть свои компоненты, база данных и библиотека, а у мини-приложения — свои.

Так и работают микросервисы и в этом их главное преимущество перед монолитом — со страницами можно работать по отдельности, у них могут быть разные команды, которые уже гораздо меньше влияют друг на друга.

Микросервисы — это очень удобно, но есть одна проблема. Представим компонент, который используется и на одной, и на другой странице. 

Можно просто скопировать его из MainPage в AboutPage, но тогда при каждом обновлении компонента на первой странице придётся вручную обновлять его и на второй. А мы хотим, чтобы это происходило автоматически. Как это сделать? Есть несколько способов: NPM, ESI и MFE.

Самый первый и простой вариант — вынести общие компоненты в NPM-пакет, то есть в библиотеку компонентов. А затем открыть доступ к нему разным страницам и поставить в приложение как зависимость.

Такое решение работает, но есть несколько проблем: 

• во-первых, NPM-пакеты нужно обновлять. На первой странице команда может, например, поменять дизайн, и тогда ей придётся договариваться с другой командой об изменении компонента в NPM-пакете;
• во-вторых, при обновлении версии лишь одной страницы могут возникать breaking change — серьёзные изменения, которые могут повлиять на работоспособность других частей приложения. В таком случае компонент в NPM-пакете тоже необходимо обновлять.

В целом с этим можно жить, но могут возникать проблемы из-за разных версионных зависимостей приложений. А когда команд очень много, сложно поддерживать нормальную работу.

Менее известный способ — Edge Side Includes (ESI). Принцип его использования напоминает iFrame — компоненты встраиваются в код. Мы передаём HTML-элементы и получаем их в HTML-коде.

Минус ESI в том, что он работает не в runtime, а в момент генерации страницы. Такой вариант не очень удобен, потому что, например, библиотека React, фреймворки Angular и Vue обновляются в runtime.

Есть ещё один классный подход для решения проблемы — микрофронтенды (MFE). 

MFE позволяет передавать доступный для всех компонент, который будет обновляться одновременно со всеми. На этом подходе остановимся подробнее.

Что такое микрофронтенды

Представьте несколько абсолютно разных страниц, которые написаны на разных фреймворках, но объединены в одно приложение. Это и есть MFE, или микрофронтенды.

Основная идея технологии хорошо описана в книге Майкла Гирса Micro Frontends in action: «…думать о веб-сайте или веб-приложении как о совокупности функций, которые принадлежат независимым командам».

Какие задачи решают микрофронтенды

Микрофронтенд удобен для проектов, которые выстраивают у себя Single Page Application (SPA) и в которых разные команды пытаются экспериментировать с подходами. Например, YouTube использует микрофронтенд. 

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

Эта панель часто меняется — в ней постоянно что-то переписывают. Центральная часть с роликами — это тоже отдельное приложение.

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

Отличие микрофронтенда от микросервисов в том, что на одной странице можно увидеть сразу много разных сервисов. Они не зависят друг от друга и могут обновляться самостоятельно.

Подходы к реализации микрофронтендов

Расскажу о трёх решениях, как можно реализовать MFE: Podium, Single-SPA и Module Federation — от самого малоизвестного до самого популярного. 

Первый подход — это Podium, фреймворк для создания микрофронтендов на стороне сервера. Он реализован на JavaScript и работает на Node.js, а также входит в коробку фреймворка hapi.

Это интересный подход, но с ним есть некоторые сложности. Podium подходит только для фулстек-разработчиков, так как необходимо писать не только фронтенд, но и бэкенд на Node.js.

Код с использованием Podium выглядит вот так.

https://www.youtube.com/watch?v=ZQClCNPq7AI\u0026pp=ygVT0JzQuNC60YDQvtGE0YDQvtC90YLQtdC90LQ6INGH0YLQviDRjdGC0L4g0YLQsNC60L7QtSDQuCDQt9Cw0YfQtdC8INC-0L0g0L3Rg9C20LXQvT8%3D

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

Второй подход самый популярный — это фреймворк Single—SPA. О нём сейчас очень много говорят и пишут, а на его официальном сайте есть обучающие видео для новичков и профессионалов.

Этот фреймворк объединяет несколько JavaScript-микрофронтендов в одно фронтенд-приложение. Он позволяет использовать на одной странице несколько фреймворков: например, AngularJS, Angular, Ember.js или другие.

И разворачивать их независимо друг от друга.

Single-SPA действительно удобен в использовании, потому что не надо ничего переписывать, чтобы им пользоваться. Однажды я работал над проектом, который был написан на AngularJS, и бизнес захотел перевести все новые функции на React. Тогда-то нас и спас Single-SPA. Нужно было лишь «воткнуть» его в старое приложение, сделать общую шапку или навигацию — и всё готово. Выглядело это вот так.

В нашем случае шапка была элементом, который не имел связи с приложением внутри контента, поэтому Single-SPA нам подходил. Но и здесь возникла проблема — нужно было передавать данные из одного приложения в другое. 

Можно придумать много идей, как это сделать, например, с помощью local или global storage. Я встречал подход, когда использовали глобальный объект window, что тоже не лишено смысла, хотя и небезопасно. Подходы разные, но проблема всё равно остаётся. Чтобы найти решение, придётся потратить немало времени и придумать свои костыли. 

Третий подход — Module Federation, в последнее время о нём всё чаще говорят. Его активно развивают, он даже вошёл в пятый webpack как плагин. Остановлюсь на этом подходенемного подробнее.

Module Federation

Module Federation позволяет приложению экспортировать один или несколько модулей в отдельные js-файлы. Это отличный способ строить микрофронтенд-приложение. При этом можно импортироваться в сторонние модули — работу с зависимостями webpack берёт на себя. Также, в отличие от NPM, Module Federation работает в runtime. 

Как работает Module Federation

Допустим, нам нужно, чтобы один и тот же компонент, который есть в MainPage, отобразился в AboutPage. А потом мы хотим сделать то же самое, но наоборот — отобразить компонент из AboutPage в MainPage.

Вот как это выглядит в коде.

Сначала чуть-чуть настраивается webpack.config. На скриншоте есть имя — это ключ, по которому мы ориентируемся. Есть файл, который будет генерироваться после того, как соберётся плагин webpack.

Также указано, что именно и под каким именем подключать, в какую папку смотреть и что нужно импортировать. Ещё есть shared, в котором мы прописываем, что в нескольких приложениях используются одинаковые библиотеки, чтобы лишний раз не собирать бандл.

Для этого плагин подключает разные файлы на разные хосты.

В коде указываем, что файлы подключены по ключу home, а также прописываем контейнер, который мы хотим смотреть.

А дальше просто используем это в своём приложении с помощью обращения к компоненту через home/ProductCarousel.

Так довольно легко получить доступ к другому компоненту. Это может быть приложение, store или вообще любой js-файл.

Пример использования MF из практики

Я работал с приложением, которое было целиком и полностью написано на Node.js. Это было серверное приложение с клиентом, где всё генерировалось через handlebars.

Его код было очень сложно читать — можно было месяцами разбираться со взаимосвязями. Из-за этого долго происходил онбординг новых людей в команду — им надо было очень много всего объяснять. Мы хотели переехать на новую систему. Но бизнесу это было невыгодно — останавливать разработку на полгода или год было бы потерей денег.

Мы рассматривали разные варианты того, что можно было сделать. Single-SPA не подходил — всё равно онбординг оставался бы сложным. В итоге мы использовали Module Federation и решили собирать приложение отдельными компонентами, не затрагивая центральную часть Canvas, которая была написана неплохо. Шапку мы создали как отдельный проект, боковое меню — тоже. 

Чтобы приложения между собой взаимодействовали, мы создали общий storage. Он мог подключаться ко всем приложениям. Если требовалось обновить, например, шапку, то нам не нужно было больше обновлять вообще всё.

Выводы

Микрофронтенд имеет смысл, когда недостатки монолита начинают преобладать над преимуществами. Например, когда вы сталкиваетесь с такими проблемами:

• есть несколько команд, которые делают одно дело и постоянно спотыкаются друг об друга, конфликтуют;
• доставка до продакшена стала очень долгая и фичи реализуются с задержкой;
• преимущества монолита становятся его недостатками.

Во всех этих ситуациях стоит задуматься о микрофронтендах. А вот выбор подхода к реализации зависит от проекта и задач. Теперь вы знаете как минимум три разных подхода.

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

Микрофронтенды — это просто один из подходов к разработке, у каждого из них есть преимущества и подводные камни.

Перед тем как переходить на него, стоит задуматься, а не усложнит ли он вам жизнь? Мы ВКонтакте пока остаёмся в монолите, но постоянно посматриваем в сторону микросервисов и микрофронтендов и думаем, как можно их использовать у нас. 

Эта статья написана по мотивам доклада на FrontendConf 2022, где, кстати, у VK была крутая зона для фана в перерывах между докладами.

А следующая наша масштабная конференция по фронтенду состоится в октябре, и мы уже вовсю составляем программу. Изучайте темы и подавайте заявки до 10 мая.

И подписывайтесь на мой телеграм-канал — в нём я рассказываю много интересного о мире фронтенд-разработки и вообще о технологиях.

Микрофронтенды — а почему бы и нет?

Фронтенд-разработка всегда занимала положение младшего ребенка в семействе веб-приложений. И пока фронтенд-разработчики расхаживали в своих модненьких шапочках, с аккуратными усиками, MacBook и дорогим кофе, создавая впечатляющие и стильные веб-сайты с помощью новейшихJavaScript-фреймворков, их коллеги из бэкенда не могли не испытывать к ним ничего, кроме жалости, воспринимая их как наивных детей, ничего не смыслящих в веб-разработке.

Бэкенд-разработчики чем-то напоминают сериал “Симпсоны”  —  как бы вы к нему ни относились, но “Симпсоны” всегда всех опережают. Несколько лет назад в React появился серверный рендеринг.

Ну и что такого? К тому моменту он применялся в Java уже, по крайней мере, лет 15. Переиспользуемые компоненты? Старо как мир  —  для бэкенда это давно пройденный этап.

Как насчет реактивного программирования? Бинго! Бэкенд давно его освоил.

Одной из проблем, докучавших фронтенд-разработчикам, стала архитектура монолитного приложения. Как вы могли догадаться, некоторое время назад бэкенд нашел решение через внедрение микросервисной архитектуры, которая применяется уже около 15 лет. Но оказалось, что эта техника совсем бесполезна для фронтенда. Однако так ли это на самом деле? Представляем вам микрофронтенды!

Глядишь, так фронтенд-разработчики и шаблоны проектирования начнут использовать! 

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

Не самое лучшее изображение макета на основе микрофронтенда 

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

Вариант портального приложения 

При этом представляется целесообразным объединить эти два подхода и интегрировать в качестве микрофронтендов не только представления, но и элементы макета. Конечно, что бы мы ни рассматривали в связи с заявленной темой, все зависит от бизнес-задач.

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

Конечно же, это не золотое правило, и каждый случай необходимо рассматривать отдельно, взвешивая все “за” и “против”. 

Микрофронтенды, так же как и микросервисы, не без недостатков. Перечислим самые существенные из них:

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

А что же мы получаем взамен? Как уже упоминалось, итоговый результат может быть каким угодно, но в общем предположить можно следующее:

• Как бы вы ни решили разделить приложение, у вас всегда будет возможность разделить ответственность за базу кода, создав небольшие команды для работы над полноценными приложениями отдельного домена, т. е. состоящими из микрофронтенда одного домена и микросервиса, или убедившись, что у каждой значимой части UI приложения есть команда разработчиков, ответственная за весь его функционал. Или предпочесть промежуточный вариант!
• До тех пор, пока не нарушается интеграция между обернутыми микрофронтендами и приложением-оберткой, вы можете выполнять независимые развертывания.  
• В приложении можно смешивать и сопоставлять различные технологии  —  использовать какие-то части, созданные в новейшем Vue или React, другие  —  в Angular 1.2, а также устаревший код 15-летней давности, предоставляя при этом уверенный и последовательный пользовательский опыт!
• Микрофронтенды облегчают эксперименты с новшествами  —  как и в случае с микросервисами, вы можете стать полностью независимы от одной технологии. Шутки по поводу новых JS-фреймворков, появляющихся каждый день, весьма раздражают, но ведь “срок годности” архитектурных решений фронтенда намного короче. А с новым подходом микрофронтендов вы вольны разрабатывать новые возможности вашего приложения, используя совершенно иной набор инструментов при условии, что они лучше подходят для решения поставленной задачи, чем ваш предыдущий набор (при этом не стоит увлекаться и менять его каждые 15 минут!) 
• В зависимости от бизнес-задач вам будет довольно просто наладить работу приложения как в автономном режиме, так и в качестве части другого приложения!
• Микрофронтенды способствуют повторному использованию кода и композиции  —  с данным подходом становится намного проще и естественнее извлекать общий код, поскольку обычно повторяется код, связанный с общим доменом.

Для разработки частей приложения можно даже организовывать отдельные команды по доменам

С чего же начать реализацию микрофронтендов в проекте? Честно говоря, в вашем распоряжении удивительное разнообразие способов! Кроме того, реализацию можно осуществить на нескольких уровнях веб-приложения: на стороне сервера, клиента или на их границе. 

Начнем с включений на граничном уровне (ESI). Главным образом они осуществляются через специальный язык разметки XML, позволяющий граничному решению, которое является ничем иным как CDN, создавать представление с помощью ответов с разных URL. 

Как видно из примера, сама реализация довольно проста и не предполагает каких-либо сложностей с интеграцией различных стеков технологий, за исключением, возможно, решений, использующих для работы направленные на себя запросы POST, но данная проблема не зависит от выбранного решения и может быть исправлена с помощью простого iframe. 

Что касается недостатков, обозначим два самых главных из них. Прежде всего, данный подход требует дополнительного специального уровня в архитектуре приложения, а именно применения CDN для обработки ESI, и к тому же он не очень быстрый. 

Сервер является еще одной частью приложения, пригодной для интеграции, которая может выполняться в разных частях стека — либо на http-сервере (через включения на стороне сервера или SSI), либо на сервере приложения.

SSI по удобству и простоте довольно близок ESI, но при этом не требует создания дополнительного уровня, поскольку, например, Apache и Nginx поддерживают его по умолчанию. Достаточно будет лишь добавить несколько строк в файл конфигурации http-сервера, после чего можно вводить команды SSI в обрабатываемых HTML-файлах. Вот один из примеров:

Как мы видим, все происходит на HTTP-сервере, который необходим для работы приложения.

Интеграция на стороне сервера также осуществима на сервере приложения. Конечно, есть вариант написать ее с нуля, но можно рассмотреть уже готовые предложения, воспользовавшись библиотекой Podium. Суть ее концепции заключается в применении набора небольших серверов Node.

js, называемых в Podium ‘podlets’ или части страницы, по одному для каждого обертываемого приложения, и одного центрального сервера “layout”, объединяющего их для эффективной работы.

Помимо этого, Podium также предоставляет несколько полезных вспомогательных инструментов для передачи данных между приложениями, повторного использования ресурсов и т. д. 

Интеграцию можно выполнить и на стороне клиента. Вэтом случае, как вы уже догадались, она будет называться интеграцией на стороне клиента. Для реализации данного подхода лучшие решения предлагает библиотека Single-spa. Она позиционируется как JS-маршрутизатор для фронтенд-микросервисов, чем по факту и является.

Совместно с набором адаптеров эта библиотека позволяет собрать фронтенд-приложение (с помощью фреймворка или без него), которое вместо маршрутизации, ведущей к различным страницам, которые представляют одну кодовую базу и развертывание, будет вести к разным приложениям, разработка которых предполагает использование абсолютно разных фреймворков.

 

Один или более маршрутов вашего приложения могут соединяться с ультрасовременным приложением, использующим новейшую версию React; другие же приведут пользователя к устаревшему приложению Ember; третьи  —  к совсем древнему приложению на стороне сервера при условии, что вы загружаете его из приложения JS, например, через iframe, а вот четвертые  —  к эффектной новой странице, собранной при помощи Svelte. А почему бы и нет? Конечно, все эти субприложения могут и сами иметь внутреннюю маршрутизацию. Несмотря на то, что интеграция выполняется во время компиляции, все приложения загружаются в ленивом режиме, что позволяет избежать “раздувания” пакетов. И если в нескольких субприложениях у вас используются одинаковые версии пакетов, то фактически вам удастся уменьшить итоговый размер бандла, поскольку все приложения будут скомпилированы бандлером за один раз. 

Решение принимать вам! 

Итак, насколько целесообразно внедрять микрофронтенды? Как обычно, все зависит от ситуации. Если вы разрабатываете небольшой сайт компании, то, скорее всего, ответ  —  нет. Если же вы работаете над крупным приложением, включающим большое число отдельных элементов UI или представлений, охватывающих множество доменов (а может и то, и другое сразу), то, вероятно, стоит к ним прибегнуть. 

В случае какого-либо промежуточного варианта нужно будет принять решение на основе анализа конкретной ситуации. Я уже упоминал достоинства и недостатки данного подхода, и в зависимости от бизнес-задач, архитектуры, числа разработчиков, создающих приложение и многих других факторов результат будет либо положительным, либо отрицательным. Решение принимать вам! 

• Читайте нас в Telegram, VK и Яндекс.Дзен
• Перевод статьи Piotr Jaworski: Microfrontends — should I care?

Микрофронтенды: зачем нужны и как к ним прийти

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

https://www.youtube.com/watch?v=ZQClCNPq7AI\u0026pp=YAHIAQE%3D

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

В логике монолитного бэкенда разрабатывать свою часть без риска затронуть функциональность другой части приложения непросто.

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

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

Классический способ борьбы со сложностями — это разделение на составляющие. Если вести разработку всего приложения целиком сложно, нужно «распилить» его на части и разрабатывать отдельно.

Где подвох

Логика микросервисов наложилась на фронтенд-разработку. Программистам, работающим на «фронт», тоже хотелось приобрести гибкость и независимость команд, ту масштабируемость, которая характерна для микросервисной архитектуры.

Одно но: фронтенд всегда работает с единой средой, которая трудно отделима. Он выполняется на стороне браузера (клиента), поэтому в рамках одного приложения всегда есть только одна адресная строка, один глобальный объект localStorage, один DOM. Как бы мы ни делили приложение, некая общая часть всегда остается. Именно вокруг этой проблемы строятся основные ограничения микрофронтендов.

И главное разочарование: в рамках микрофронтенда не получится организовать такую же изолированность частей приложения, как при микросервисной разработке в бэкенде. Во всяком случае пока.

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

Если вы хотите перейти на микрофронтенд

В первую очередь, поймите, зачем это вам. Микрофронтенд нужен не всем. Да, это тренд, который сейчас активно обсуждается в комьюнити. Да, многие большие компании так или иначе придут к этой архитектуре. Но все это актуально в случае объемного приложения. Если сайт состоит из нескольких страниц, микрофронтенд теряет смысл.

Это уже оверхэд. Смысл в делении монолита есть, если у вас крупный проект, несколько команд разработки, которые, возможно, используют разные фреймворки. Это, к слову, еще один плюс микрофронтенда: разные команды могут писать код на разных стеках.

Кто-то пишет на React, кто-то — на Angular, но все объединяется в работе одного приложения.

Затем нужно понять, как именно можно поделить ваш монолит на относительно независимые для разработки блоки. Чаще всего отталкиваются от команд разработки. Обычно деление зон ответственности уже есть, просто оно не воплощено в архитектуре.

Например, в Selectel основной продукт разработки фронтендеров — это Панель управления, где клиенты могут приобретать и использовать наши услуги. При этом в самой панели также есть деление на продукты компании и, как правило, у каждого продукта, будь то выделенные серверы, «Облачная платформа Selectel», Managed Kubernetes и т.д.

, есть свои фронтенд-специалисты. То есть они уже развивают только определенную часть панели.

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

Например, такая библиотека, как single-spa, которая объединяет несколько javascript-приложений в одно.

Или спецификация Realms, которая позволит на уровне нативного javascript упростить разработку микроcервисов на фронтенде.

Современные фреймворки типа Vue и Angular также имеют некоторые возможности, позволяющие писать свое приложение так, чтобы в результате его проще было интегрировать в микрофронтенды.

Опыт компаний

В целом, большинство крупных компаний так или иначе перейдут на микрофронтенд-архитектуру для своих приложений. Известно, что в России так работают в «Додо-пицце», Avito, «Тинькофф банке».

Как использовать микросервисы в веб-разработке — возможные проблемы и их решения

Selectel тоже стремится к этому. К микрофронтендам мы подходим как к неизбежной необходимости.

В компании большой продуктовый портфель, включающий как базовые услуги дата-центров, так и современные PaaS. Как я уже писал, развитием продуктов занимаются, как правило, отдельные команды.

И уже сейчас мы отмечаем сложности в их синхронизации при разработке и релизах.

Наш путь к микрофронтендам начался во многом из-за переезда с AngularJS на Angular нашей Панели управления. Сейчас мы в процессе миграции и поддерживаем гибридную структуру фронтенда.

Как известно, есть несколько способов миграции из одного фреймворка в другой. Первый — более дорогой и долгий — подразумевает поддержание приложения на старом коде и параллельное его переписывание.

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

И старая, и новая версии работают одновременно. В процессе переписывания мы рефакторим код. А в течение рефакторинга выделяем части приложения, делаем их более изолированными, избавляясь от лишней связанности.

Таким образом, мы создаем подобие микрофронтенд-архитектуры.

Как решать проблему общих ресурсов

Хорошим шагом к организации микрофронтендов может стать создание монорепозитория. Это git-репозиторий, внутри которого содержатся ваши npm-пакеты, зависящие друг от друга. Монорепозиторий поможет решить проблему с конфликтом версий библиотек и ведением разработки разными командами — все в одном месте, не нужно бегать по разным репозиториям и линковать пакеты.

При разработке Панели управления Selectel мы как раз используем монорепозиторий. Раньше у нас каждая услуга была отдельным git-репозиторием.

В результате возникали сложности не только при локальной разработке, когда нужно было линковать пакеты, но и при обновлении библиотек и сборке в CI.

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

Упомяну и очевидные вещи: не стоит исключать лучшие практики разработки (в том числе DRY, KISS, YAGNI) и простую коммуникацию — обмен опытом между фронтенд-разработчиками компании.

Выделим ключевое

Микрофронтенды — это деление монолитного приложения на семантически изолированные части и их независимая разработка.

Микрофронтенды имеют смысл, если:

1. У вас большое приложение.
2. Несколько команд разработки.
3. Вы все чаще сталкиваетесь с проблемами при выкате обновлений приложения.
4. Преимущества монолита обернулись в минусы.

Для остальных проектов микрофронтенды будут избыточны.

Ограничения микрофронтендов:

1. Остается проблема общих ресурсов. Полноценная изоляция, как в случае с микросервисной архитектурой в бэкенде, пока невозможна.
2. Требуется прослойка для оркестрации приложения, которая может вносить свой оверхэд.

Что поможет справиться с ограничениями:

1. Создание монорепозитория.
2. Использование специальных библиотек и инструментов.
3. Хорошая команда специалистов.
4. Использование лучших практик разработки (например, DRY, KISS, YAGNI).

Микрофронтенд (Microfrontend): что это и как реализовать

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

Приходите на наш бесплатный вебинар по разработке без кода, чтобы задать вопросы, узнать больше про зерокодинг и попробовать себя в новой профессии!

Что такое микрофронтенд

Микрофронтенд – это подход к разработке веб-приложений, основанный на концепции микросервисов. Вместо традиционного монолитного подхода, когда весь фронтенд приложения находится в одной крупной кодовой базе, подход предлагает разделять веб-интерфейс на более мелкие и автономные компоненты.

Особенности и принципы

Разделение по функциональности: каждый компонент является независимым модулем с определенной функциональностью, который может быть разработан и развернут отдельно. Это позволяет командам разрабатывать и обслуживать каждый модуль независимо друг от друга.

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

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

Инкрементное внедрение: позволяет постепенно переходить от монолитной архитектуры к микросервисной, добавляя новые микрофронтенды. Это упрощает процесс миграции и снижает риски для проекта.

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

Зачем использовать

• Улучшенная командная работа: позволяет разбить сложные проекты на более мелкие и понятные задачи, что способствует лучшей организации работы и повышает производительность команды разработчиков.
• Быстрая разработка и развертывание: За счет независимости, разработка и внедрение новых функций становится эффективной.
• Легкость обновлений: в случае необходимости обновления одного из компонентов, это можно сделать без остановки всего приложения или влияния на остальные его компоненты.
• Улучшенное масштабирование: они легко масштабируются при увеличении нагрузки, что позволяет легко справляться с растущим числом пользователей.

Как использовать

Шаг 1. Разделение функциональности: определите функциональные области вашего приложения, которые можно разделить на отдельные микрофронтенды. Это может быть, например, панель администратора, страница каталога, корзина и т.д.

Шаг 2. Выбор технологий: можно использовать свой собственный стек технологий. Подберите инструменты для каждого модуля, учитывая его особенности и требования.

Шаг 3. Определение интерфейсов: определите интерфейсы и способы взаимодействия между компонентами. Для обмена данными можно использовать API или событийную модель.

Шаг 4. Разработка и развертывание: он разрабатывается и развертывается независимо. После этого их можно интегрировать в основное приложение.

Шаг 5: Тестирование и мониторинг: протестируйте каждый компонент на соответствие требованиям и взаимодействию с другими компонентами. Обеспечьте мониторинг производительности и стабильности всего приложения.

Пример использования

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

Вы разделяете функциональность приложения на несколько микрофронтендов:

1. Каталог товаров: отвечает за отображение списка товаров, фильтрацию и сортировку.
2. Корзина: обрабатывает добавление товаров в корзину и оформление заказа.
3. Профили пользователей: Отображает персональную информацию и историю заказов.
4. Система оплаты: обрабатывает оплату заказов.

Заключение

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