Микрофронтенды: прихоть разработчиков или реальная польза для бизнеса

**Как наша команда ускорила релизы и снизила затраты: опыт внедрения микрофронтендов** В этой статье мы расскажем о том, как нашей команде удалось оптимизировать процесс разработки, сократить расходы и создать масштабируемую архитектуру без хаоса. Мы поделимся опытом внедрения микрофронтендов и объясним, кому они могут быть полезны. **Что такое микрофронтенды и зачем они нужны?** Микрофронтенды — это подход к архитектуре фронтенда, при котором большое приложение делится на независимые модули. Каждый модуль разрабатывается отдельно и имеет свой собственный цикл выпуска. Микрофронтенды могут находиться в одном репозитории, но чаще всего они размещены в отдельных. Основная цель микрофронтендов — разделить зоны ответственности, ускорить вывод продукта на рынок и позволить разным командам работать и выпускать обновления параллельно. Иногда микрофронтенды сравнивают с микросервисами для фронтенда, но это разные вещи. Микрофронтенды запускаются в одной вкладке браузера, имеют общий глобальный контекст и используют один рантайм. **Наш опыт внедрения микрофронтендов** Мы внедрили микрофронтенды в приложении RUN, которое является внутренним инструментом для работы различных департаментов в рамках брокерского бизнеса. Приложение включает в себя такие функции, как бэк-офис, CRM, мониторинг, управление ролями и разрешениями, отчётами, брендинг-сервис и многое другое. Также мы предоставляем приложение RUN внешним заказчикам для управления их брокерским бизнесом с возможностью настройки под их потребности. **Почему мы выбрали микрофронтендную архитектуру?** Изначально у нас был целый набор внутренних проектов для разных департаментов, написанных на разных технологиях — Angular, jQuery, Vue.js, а также десктопные приложения и Django-админки. Этот «зоопарк» проектов имел несколько проблем: * Разнообразие технологий требовало отдельной инфраструктуры и разработчиков разных стеков, что увеличивало стоимость поддержки проектов. * Отсутствие единой ответственности приводило к тому, что каждая команда отвечала только за свой продукт, не было общих решений и видения проекта в целом. * Из-за отсутствия общей дизайн-системы интерфейсы выглядели разрозненно. * Каждая программа требовала отдельной авторизации. Все эти факторы увеличивали стоимость разработки и поддержки. Поэтому бизнесу понадобилось новое приложение с единой точкой входа в виде однократной авторизации. Кроме того, оно должно было быть коробочным, поскольку наша компания продаёт такие решения под ключ.