Микрофронтенды: мой опыт и взгляд на архитектуру будущего фронтенда

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

Обычно я создаю MVP (minimum viable product), чтобы как можно быстрее собрать данные непосредственно от пользователей. Мне нужно разработать архитектуру и выбрать базу данных, SQL или NoSQL, в зависимости от потребностей продукта. Возможно, я затем создам монолит для уровня API, чтобы минимизировать накладные расходы на несколько конвейеров CI/CD, и настрою рекомендуемые инструменты observability. Я сосредоточусь на бизнес-логике приложения и, что не менее важно, создам приложение на стороне клиента, возможно, используя хорошо известный фреймворк, такой как Vue, Angular или React. Если мне повезет, через несколько месяцев у меня будет готовый продукт и много пользователей, подписавшихся на сервис.

Допустим, этот проект действительно успешный, и компания решает инвестировать в него и дальше. Чтобы поддержать эту работу, мне придется нанять больше людей. Внезапно я обнаруживаю, что у меня гораздо больше разработчиков, чем было вначале. Глядя на dashboard, я также понимаю, что некоторые API используются совершенно иначе, чем я планировал изначально. Некоторые из них хорошо кэшируются, поэтому CDN принимает на себя основной удар; другие напрямую обращаются к моему бэкэнду тысячи раз в секунду.

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

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

Для многих проектов интерфейс остается неизменным: одностраничное приложение (SPA) и/или server side rendering приложение, которое просто растет и растет с каждой новой фичей, добавляемой к платформе. В этом сценарии распределенные команды, вероятно, работают над одной и той же кодовой базой, наследуя решения, принятые горсткой людей, начавших проект в совершенно другом контексте. Но фронтенд команды сталкиваются с теми же проблемами организации и масштабируемости, что и бэкенд команды. Разве у них или у меня - есть другие варианты?

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

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

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

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

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

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

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

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