Эта статья также доступна на испанском языке здесь: https://www.infoxicator.com/es/la-historia-de-micro-frontends
Знакомый сценарий
Пятница, 17:30, и вы должны развернуть очень важное исправление во внешнем интерфейсе вашего приложения; вы запускаете процесс развертывания и ждете запуска 50K модульных и интеграционных тестов. Непосредственно перед завершением тестов вы получаете сообщение от другой команды, в котором сообщается, что фиксация, которую они нажали на прошлой неделе для включения «Темного режима», еще не утверждена, и поскольку она связана с вашим исправлением, вы должны остановить все развертывание. процесс. В этот момент вы просто хотите вернуться домой и даже подумать о смене карьеры.
Звучит знакомо? Если вы были в такой ситуации, вы могли бы извлечь выгоду из «переключателя парадигмы».
Войдите в архитектуру внешнего интерфейса следующего поколения: микросервисы для внешнего интерфейса!
Но сначала немного истории…
Не так давно наши веб-приложения были построены как огромный монолит; бэкенд и фронтенд объединены вместе; но по мере того, как приложения начали расти, мы решили «разделить» серверную часть и внешний интерфейс, и мы увидели рост одностраничных приложений, которые взаимодействуют через API. Бэкэнд-команды претерпели эволюцию, а также «разделили» свои приложения на микросервисы. В сфере внешнего интерфейса понятие «компоненты» было представлено популярными библиотеками, такими как React, которые обеспечивали композицию и возможность повторного использования наших кодовых баз. Теперь, почему интерфейс остановился на этом? здесь представлена новая концепция Микрофронтенды как следующий шаг в эволюции веб-разработки.
Что такое микрофронтенды?
Архитектура микрофронтенда — это новая парадигма, позволяющая разделить «фронтенд-монолит» на небольшие, повторно используемые и независимые пользовательские интерфейсы.
Эти возможности имеют свои собственные репозитории, собственный конвейер CI/CD и могут быть развернуты и протестированы независимо друг от друга.
Преимущества
Независимые развертывания 🚀
- Сниженный риск: вы развертываете только то, что изменилось, а не все приложение. "Если это не сломано, не чините это"
- Быстрые исправления в рабочей среде. Отсутствие зависимости от других команд или кода позволяет быстрее выпускать критически важные исправления.
- Упрощенное тестирование.Выполняйте тесты для отдельных интерфейсов с определенными границами и гарантируйте их функциональность, следуя принципу единой ответственности.
Независимые команды 👨🏫
- Полное владение: к структуре команды можно применить вертикальное разделение, чтобы предоставлять функции от начала до конца, владея всем техническим стеком.
- Избегайте зависимостей.автономия команды помогает уменьшить потребность в координации и помогает избежать помех/препятствий.
- Ускорение выхода на рынок. Повышенная скорость и автономность для более быстрого внедрения новых функций.
Разделенные кодовые базы ✍️
- Опыт разработчика: повышение производительности и сосредоточенности.
- Уменьшенный объем. Помогает разработчикам лучше понять код и не перегружается огромной кодовой базой.
- Избегайте случайного связывания.Разработчики взаимодействуют только с определенными частями кода при разработке новых функций, а поскольку существуют установленные границы, это устраняет необходимость связывания компонентов, которые не должны знать друг о друге.
Возможность повторного использования 🗃
- Инкапсулированный опыт. Функции, созданные как независимые пользовательские интерфейсы, можно легко повторно использовать во всем приложении.
- Композиция: аналогичный повторному использованию компонентов, достигаемый композицией, этот подход также можно применять к микроинтерфейсам.
- Повторное использование другими приложениями.Поскольку микроинтерфейсы имеют собственный конвейер CI/CD, их можно развертывать в разных приложениях и даже совместно использовать в качестве готовых решений, содержащих всю бизнес-логику и представление пользовательского интерфейса. требуется для выполнения нескольких вариантов использования.
Компромиссы 😞
- Один разработчик?
- Маленькая команда?
- Маленькое приложение?
Архитектура микроинтерфейса может не подойти, и она лучше подходит для средних и крупных приложений с несколькими командами, которым необходимо работать независимо.
Как и в случае с микросервисами, в шаблоне микроинтерфейса вы обнаружите, что количество движущихся частей, которыми необходимо управлять и настраивать, увеличивается, что увеличивает общую сложность приложения. Эти проблемы, однако, не являются прямым следствием этого шаблона, а являются унаследованным побочным эффектом, возникающим при масштабировании и при работе с большими приложениями и несколькими командами. Также может потребоваться некоторое обучение и потребность в новых инструментах, которые помогут организовать все части и связать их вместе.
Заключение
По мере того, как ваши приложения начинают масштабироваться, вы начинаете добавлять в проект больше разработчиков и создавать новые команды, возможно, настало подходящее время разрушить «монолит внешнего интерфейса» и предоставить вашим командам автономию, необходимую им для более быстрого предоставления функций вашим пользователям. .
