Микрофронтенды как решение проблем кратного роста команды • Дмитрий Кузнецов (Tinkoff)

• Приветствие участников и проверка звука и видео.  

• Представление Димы Кузнецова, фронт-архитектора из Тинькофф.  

• Обсуждение технических проблем с Zoom и Slack.  

• Дима рассказывает о своем опыте работы в крупных компаниях, таких как Яндекс и Тинькофф.  

• Основная тема доклада: микрофронтенды и их успешное применение в Тинькофф.  

• Обсуждение монорепы и её преимуществ, но также и проблем, таких как вендеринг и сложность дебаггинга.  

• Переход к отдельным репозиториям для решения проблем монорепы, но это привело к новым сложностям.  

• Создание CMS для управления контентом, но проблемы с контрактами и сложностью для контент-менеджеров.  

• Необходимость обратной связи и простоты использования для контент-менеджеров.  

• Усложнение процесса разработки и необходимость написания и поддержки тестов.  

• Рефакторинг и создание архитектурной команды, но демотивация и проблемы с планированием.  

• Проблемы с рефакторингом и необходимость восстановления логики кода.  

• Важность горизонта планирования и взаимодействия между командами для успешного рефакторинга.  

• Архитектурная команда сделала модерн сборку для хрома, что привело к проблемам с агентами на 52-м хроме.  

• Рефакторинг эффективен при наличии тестового покрытия и быстрой обратной связи.  

• В больших проектах с брошенной логикой лучше писать все с нуля.  

• Микрофронтенды — это архитектурный подход, наследуемый от микросервисной архитектуры.  

• Они имеют собственный релизный цикл и могут общаться между собой и с приложением.  

• Микрофронтенды живут в одном рантайме и имеют независимые релизные циклы.  

• Фрейм — это микрофронтент, так как его можно релизить независимо.  

• Микросервисы агрегируют данные и рендеринг в одну страницу.  

• Микромодули — это статические сборки, которые загружаются и исполняются.  

• На Тинькофф.ру более 250 микрофронтендов, которые ежедневно релизятся.  

• Разрабатывается около 50 разработчиками в 20 приложениях.  

• Микрофронтенды захватили несколько доменов компании.  

• Успех объясняется правильностью решений в ключевых аспектах.  

• В докладе будут рассмотрены семь аспектов, включая связанность.  

• Связанность может быть каулингом или кохэшином.  

• Каулинг — это взаимодействие систем, кохэшн — это сплоченность элементов.  

• Микрофронтенды на странице требуют кохэшина.  

• Свобода нарезки страницы требует описания и поддержки контрактов.  

• Временное окно независимых релизов ограничено изменением контрактов.  

• Проблемы возникают, когда контракты меняются редко или не меняются вообще.  

• Важно прорабатывать связи между системами заранее.  

• Ответственность за связи должна лежать на архитекторе или менеджере.  

• Связи между микрофронтендами и внешним миром требуют разных подходов.  

• В докладе будет семь слайдов, посвященных балансу в связях.  

• Две крайности: сильная связанность и свобода нарезки или стабильность контрактов и ограничения.  

• Время обновления самого медленного приложения составляет полгода.  

• Баланс: контракты между микрофронтендами и приложениями меняются реже, чем раз в полгода.  

• Две крайности: собирать все внутрь для воспроизводимых сборок или не включать зависимости для оптимизации трафика.  

• Проблемы: дублирование зависимостей и проблемы с синглтонами.  

• Баланс: почти все собираем внутрь, но с разрешенными библиотеками и реакциями.  

• Две крайности: поддерживать все контракты или только один.  

• Проблемы: перерасход ресурсов тестирования и необходимость релизного цикла на каждое изменение контракта.  

• Баланс: поддерживаем один контракт, но с запасом тестирования.  

• Два подхода: прокси-инстанс и интеграция внутрь приложения.  

• Проблемы: усложнение сетевой топологии и тестирование.  

• Баланс: интеграция внутрь приложения, но с типовым фреймворком.  

• Две крайности: ручное тестирование и полная автоматизация.  

• Проблемы: дороговизна написания тестов и их поддержка.  

• Баланс: макированные тесты и контракты, но с ручным тестированием сложных кейсов.  

• Две крайности: моментальные релизы и стабильные релизы через каждое приложение.  

• Проблемы: риск серьезных последствий и перерасход тестирования.  

• Баланс: процесс "незнайка" с добавлением суток к релизному циклу.  

• Другие команды начали использовать микрофронтенды, что привело к риску для нескольких приложений.  

• Попытка использовать монорепозиторий не удалась из-за высоких требований к ревью и тестам.  

• Решение: локальный мапинг, который позволяет релизить компоненты только в рамках одного приложения.  

• Глобальный мапинг определяет, какие сборки микрофронтендов использовать.  

• Локальный мапинг релизится вместе с приложением и тестируется в его рамках.  

• Сквозные компоненты релизятся в монорепозитории с высокими требованиями качества.  

• Связь микрофронтенда с приложением меняется редко, что увеличивает время жизни контракта.  

• Увеличен трафик пользователей на 3%, что привело к воспроизводимым сборкам.  

• Валидация из контрактов убрана, что увеличило время жизни контракта, но требует больше тестирования.  

• Ручное тестирование оставлено, но автоматизация ограничена.  

• Кастомные компоненты релизятся внутри приложения без слежения за качеством.  

• Микрофронтенды — это подход, который нужно реализовывать самостоятельно.  

• Микрофронтенды не могут публиковаться как отдельное приложение, так как это часть приложения.  

• Тестирование микрофронтендов происходит изолированно, что позволяет избежать ошибок в реальных приложениях.  

• Контракт на компонент должен меняться реже, чем раз в полгода.  

• Если контракт меняется чаще, это усложняет процесс релизов.  

• В среднем приложение релизится раз в неделю, что сокращает время между релизами.  

• Были случаи, когда микрофронтенды приводили к деградации функционала.  

• Примеры инцидентов: исчезновение элементов и проблемы с версткой.  

• Большинство инцидентов были незначительными и не касались продакшна.  

• Обсуждение стабильности использования сервисов Тинькофф и других.  

• Вопрос о перерисовке микрофронтендов при переходе по ссылке.  

• Объяснение, что при полном переходе перезагружаются все микрофронтенды, а при спа-переходе загружаются недостающие.  

• Использование самописного решения для обвязки микрофронтендов.  

• Описание процесса инициализации и экспорта компонентов.  

• Объяснение, что клиентская сборка использует модуль экспорт для работы с микрофронтендами.  

• Уточнение, что микрофронтенды могут быть как простыми, так и сложными реакт-компонентами.  

• Объяснение, что компоненты собираются в один файл для серверного и клиентского JavaScript.  

• Призыв задавать вопросы в чат и приглашение на следующий доклад.  

• Благодарность докладчику и прощание с аудиторией.