Что такое микрофронты
Представим, что вы пришли на новое место работы и не понимаете, есть ли здесь микрофронты или нет. В браузере это будет, скорее, отдельное приложение, которое встраивается и работает обособленно. Оно может быть из другого CDN или может получать ассеты по другим URL.
В сервере, который обрабатывает часть фронтенда на клиенте, это будет другое железо. Основной продукт у вас запускается на одной машинке, а, например, шапка сайта обрабатывается на второй машинке и не нагружает основной продукт. При этом вы можете сегодня показывать эту шапку на главном сайте, а завтра — на лендинге, который сверстали на другой технологии.
В кодовой базе микрофронты тоже могут выглядеть по-разному в зависимости от того, чего вы придерживаетесь с точки зрения использования системы контроля версий. Это могут быть отдельные репозитории, сабмодули, отдельная сборка и отдельный пакет, если мы говорим об артефактных зависимостях.
Аргументы за использование микрофронтов
Позволяют делать независимые релизы
Микрофонты — независимые релизные процессы. Хотя могут быть и зависимые, но, главное, вы можете релизить их независимо. У вас отдельный набор машин, отдельная история статики, отдельная сборка. И если вы хотите чаще выкатывать шапку на сервисе, то можете выделить её в отдельный микрофонт.
Представим, что у нас в вебпаке есть какая-то сборка, в ней есть entry. Мы собрали один сабсет, запушили другой сабсет и постранично их зарелизили. Можем ли мы так делать, когда у нас монолит?
Да, но это вопрос труднодостижимости. Это реально, если вы хорошо понимаете, что хотите, и можете управлять абсолютно всей инфраструктурой. Под всей инфраструктурой мы имеем в виду три вещи: как ваши сервисы устроены, как вы деплоите и как собираете.
Мотивируют делать error-boundary-архитектуру
Если что-то отвалилось, вы можете написать и применить определённую логику деградации. Благодаря этому вы потеряете только 10% контента, а не 100%.
С монолитными технологиями часто об этом забывают, и, когда на клиенте появляется какая-то ошибка, мы видим полностью белый экран. А правильная разбивка на разные кусочки мотивирует у каждого из них реализовать логику error-boundary. И чем меньше будут эти кусочки, тем меньше контента вы будете терять.
Я как-то решил в своём микрофронте написать имплементацию бинарного поиска через while. Один кусочек не отработал — и всё, теперь у меня вечный цикл. В этом случае никакой error-boundary уже не поможет.
Проще масштабировать
Микрофронты пошли от микросервисной архитектуры — когда у тебя есть маленькие кусочки, которые можно масштабировать. Если возникла повышенная нагрузка на какой-то конкретный кусочек, ты взял и масштабировался.
Аргументы против использования микрофронтов
Сложно устроить межкомпонентное взаимодействие
Когда говорят о микрофронтах, часто упоминают их независимость. Один микрофонт можно сделать на React, второй — на Vue, а третий вообще на Angular.
Это возможно и в рамках монолита. Другой вопрос — зачем это нужно? Пользователь платит за лишние килобайты, а разработчики усложняют взаимодействие между компонентами. И если создавать такой продукт с нуля, то довольно легко ошибиться.
Создавать дизайн с нуля с микрофронтами сложно. Но есть фреймворки, которые ограничивают и направляют тебя в правильную сторону, когда нужно устроить взаимодействие в клиентских рантаймах. Например, Single-spa и Jazz.
Один микрофронт может поломать другой
Прародители микрофронтов — это микросервисы, которые не зависят друг от друга. Микросервисы обычно запускаются и ранятся в изолированных железках. И если в одном микросервисе случилась проблема, то на другой она никак влиять не должна.
Но на сегодняшней стадии развития микрофронтов нельзя сказать, что они полностью изолированы. Если возникнет проблема в одном микрофронте, это может повлиять на другой.
Тяжело обеспечить консистентность
При использовании одной библиотеки можно оказаться в ситуации, когда на момент раскатки микрофронтов получаются библиотеки разных версий. В случае с монолитными технологиями так не произойдёт: как монолитно всё поехало, так монолитно и отъехало в случае какой-то проблемы.
С микрофронтами вы можете использовать монорепозиторий, чтобы сохранять консистентность. В этом монорепозитории можно зафиксировать общую версию для всех пакетов и определить особые случаи, когда она будет действовать, — например, при обновлении версии библиотеки.
Выводы и рекомендации
Прежде чем решить, нужны вам микрофронты или нет, подумайте, как они повлияют на стандартные метрики разработки любого технологического продукта:
- Скорость
- Качество
- Стоимость
Кроме метрик, посмотрите на сам продукт. И не только на ту часть, что работает, но и на ту, которой вы владеете. Микрофронтовая архитектура будет влиять на всё: на работу серверного и клиентского рантайма, на устройство кодовой базы, на релизные процессы и процессы тестирования.