Как микрофронтенды помогают нам создавать надежные интерфейсы сложных приложений

Термин «микрофронтенды» появился в конце 2016 года на технологическом радаре ThoughtWorks (про техрадары у нас есть отдельная статья). Этот подход распространяет концепцию микросервисов на мир интерфейсов. Многие веб-ресурсы представляют собой фронтенд-монолит – многофункциональное одностраничное приложение, которое находится поверх архитектуры микросервисов. Со временем внешний слой, часто разрабатываемый отдельной командой, разрастается, и его становится сложнее поддерживать.

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

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

Плюсы и минусы микрофронтендов

Как микрофронтенды выглядят на практике

1. Самое простое – iframe'ы. Легко собираются в единое целое, но возникают сложности с передачей данных в и из отдельных приложений. К тому же, есл нужно оптимизировать сайт для поисковиков, айфреймы сразу отпадают. Они считаются содержимым другого сайта, и контент из отдельных микрофронтендов нельзя будет проиндексировать для общей страницы.

2. Web-компоненты. Фронтенду позволили реализовывать кастомные элементы, т.е. по сути оборачивать в HTML-тег фрагмент кода верстки, стилей и скриптов. Недостаток такого подхода в производительности – обилие JavaScript-кода замедляет отклик браузера.

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

3. Относительно новая возможность Webpack 5 – Module federation. Создается несколько приложений, одно помечается как хост, остальные объявляют об экспорте кода в externals. Далее хост может по запросу к «донорскому» приложению подтянуть эти данные. Angular, с которым работаем мы, позволяет загружать из удаленного приложения целые модули. Есть свои механизмы обработки общих зависимостей – поскольку микрофронтенды представляют собой отдельные бандлы, код зависимостей между ними будет дублироваться. Возможность с нии работать средствами фреймворка сильно упрощает задачи команды.

Последний вариант и представляется нам оптимальным. В одном из новых проектов сейчас мы выстраиваем эту логику на базе Angular Module Federation. В этом случае external помечаются отдельные модули, которые потом можно загрузить из shell-приложения в качестве lazyload. Angular Universal вполне справляется с рендерингом по отдельным раутам.

Что нам потребуется:

Микрофронтенды на Angular
Shell-приложение с описанным роутингом и подгрузкой микрофронтендов в виде lazyload-модулей
Бэк, использующий Angular Universal для пререндера по любому запрошенному роуту страницы.

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

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