ChatGPT на русском языке, бесплатноНовости и обновления в Telegram
На sponsr есть решения ваших задач
Полезные видео о фронтенде. Подпишись на Rutube
5 причин перехода к микрофронтенд архитектуре
2 года назад·4 мин. на чтение
Микрофронтенды — это применение микросервисной архитектуры к фронтенд приложениям. Преобразование приложения монолита из одного большого приложения в приложение, объединяющее несколько небольших UI приложений.
Независимые команды разработки
Если вы работаете в нескольких командах, организационные накладные расходы становятся значительными. Общение должно происходить хотя бы ежедневно. Согласование, необходимое для управления разработкой и развертыванием, становится невозможным. Благодаря микрофронтендам управление масштабируемостью с точки зрения ресурсов разработки становится намного проще. Как правило, каждая функция может быть разработана независимой командой. Каждая команда может автономно публиковать свой функционал без какого-либо согласования. Некоторые подходы к микрофронтендам требуют, по крайней мере, общей системы сборки или общего уровня (например, reverse proxy). Хотя такие вещи все еще можно решить заранее, они делают все решение более сложным, чтобы его можно было правильно настроить на начальном этапе. Поэтому рекомендуется искать решения, которые уже работают после первоначальной настройки.Более быстрое время выхода на рынок (TTM, Time To Market)
Независимая природа микрофронтендов также влияет на время выхода отдельных функций на рынок. Пока монолит будет развиваться все медленнее и медленнее, микрофронтенд будет идти в ногу со временем. Естественно, здесь тоже потребуется рефакторинг и улучшение базовой технологии, однако темпы цикла, описанного ниже, для каждой новой фичи будут быстрее.- начать новый проект
- разработать MVP
- зарелизить MVP
- пройтись по MVP (доработать и зарелизить)
- перейти в режим обслуживания
Фича флаги (Feature Flags)
Замечательно иметь отдельные микрофронтенды, составляющие вместе одно приложение. Но довольно часто владельцы продуктов хотят выйти за рамки технической композиции: они хотят использовать модульность также и для бизнес-целей. Случалось ли вам когда-нибудь, что определенная функциональность должна быть доступна только определенным пользователям? Функции администратора должны быть доступны только администраторам. Хотя UI не следует использовать в качестве уровня защиты (эти проверки осуществляются на бэкэнде), мы также не хотим показывать вещи, которые нельзя (или не следует) использовать. Следовательно, мы добавим в наш код такие вещи, как:if (hasFeature('foo')) { // ... }
foo
верно для всех? Что делать, если функция деактивирована для всех? Что, если завтра появится новое условие, изменяющее некоторые части, чтобы также оценить, включена ли переменная bar
?
Поскольку у нас уже есть надлежащая модульность, довольно просто добавить фича флаги. Все, что нам нужно сделать, это ввести условный рендеринг модуля (или его загрузки) с помощью флагов. Никаких изменений кода на функциональном уровне модуля.
Хотя подобные вещи могут работать и в классических монолитах, они требуют дополнительных усилий по реализации. С микрофронтендами архитектура уже полностью к этому готова.
Единая ответственность
Несмотря на то, что микросервисы не являются решением для всего, они преподносятся как таковые. Да, они, безусловно, являются хорошим решением во многих (или даже в большинстве) случаях, но очень часто монолит или другая форма сервис-ориентированной архитектуры может оказаться не менее хорошим решением. Тем не менее, наличие выделенного сервиса (с ответственной за него командой) в бэкенде — хорошее начало. Замена монолита различными микрофронтендами — это отличное продолжение, поскольку можно ввести дополнительное измерение для разделения команд.Свобода технологий
За последние два года фронтенд-технология в значительной степени стабилизировалась. Хотя и появляются новые подходы, например Svelte, которые бросают вызов таким библиотекам как React, но все же серьезных преимуществ они не предлагают. Часто существует несколько подходов и не существует универсального решения. В микрофронтенд приложениях все разные приложения могут работать вместе. Страница, написанная с помощью Angular, может использовать компонент из микрофронтенда React и наоборот. Модальное диалоговое окно для сохранения пользовательских данных может быть написано на Vue, а компонент под ним — на Svelte.- Мы разделяем только CSS?
- Как насчет поведения?
- Являются ли веб-компоненты решением для этого?
Итоги
Микрофронтенды — это не панацея. Они могут помочь и обеспечить ценность, когда обстоятельства благоприятны. Если ни одна из вышеперечисленных причин не имеет для вас никакого значения, велика вероятность, что вам не нужно внедрять микрофронтенд архитектуру.Подробное руководство по микрофронтенд архитектуре
год назад·2 мин. на чтение
Микрофронтенд становится популярной архитектурой, компании растут, появляется необходимость масштабировать команды.
Микрофронтенд - это архитектура, которая позволяет масштабироваться, делать команды независимыми и больше ориентироваться на бизнес потребности.
Мы начинаем большую и подробную серию видео о микрофронтенд архитектуре на Boosty с ранним доступом. Некоторые темы будут эксклюзивно доступны только на Boosty по подписке. Мы будем читать и обсуждать книгу “Building Micro-Frontends. Scaling Teams and Projects, Empowering Developers”. Книга не переведена на русский язык. В этих видео мы будем обсуждать самую суть книги, без воды. Также я буду давать свои комментарии, основываясь на своем опыте внедрения микрофронтендов в большом проекте.
В этих видео будет дано большое количество полезной информации по всем аспектам распиливания монолита на микрофронтенды. Мы рассмотрим большое количество вариантов внедрения микрофронтенд архитектуры, рассмотрим все достоинства и недостатки вариантов, сложности перехода на микрофронтенд архитектуру и что стоит учесть заранее. Также коснемся принципов Domain Driven Design (DDD) и как эти принципы связаны с микрофронтендами.
Рассмотрим следующие темы:
- Как распилить монолит на микрофронтенды
- Архитектуры фронтенд приложений - SPA, Изоморфные, Статичные, JAMstack
- Что такое микрофронтенд и каковы его принципы
- Что учитывать при переходе на микрофронтенд
- Краткий обзор видов разделения на микрофронтенды
- Вертикальное разделение на микрофронтенды
- Горизонтальное разделение на микрофронтенды
- Микрофронтенд на основе Module Federation
- Микрофронтенд на основе iframes
- Микрофронтенд на основе веб-компонентов
- Server Side микрофронтенды
- Edge Side микрофронтенды
- Проект с Webpack Module Federation
- Эволюция проекта с Webpack Module Federation
- Как деплоить микрофронтенды
- Как версионировать микрофронтенды
- CI/CD микрофронтендов
- Стратегии деплоя микрофронтендов
- Пример автоматизации пайплайна для микрофронтенда
- Общение микрофронтендов с бекендом
- Пример распиливания монолита на микрофронтенды. О приложении
- Пример распиливания монолита на микрофронтенды. Детали реализации
- Как презентовать микрофронтенд архитектуру команде