УДК 004.43 ББК 32.973.26-018.1 М55 Меццалира Л. М55 Создание микрофронтендов: Пер. с англ. — Астана: Фолиант, 2023. — 320 с.: ил. ISBN 978-601-271-949-9 Книга подробно рассказывает о методах разработки и масштабирования фронтендов веб-приложений с использованием архитектуры, схожей по идеологии с микросервисами. Освещены все аспекты внедрения микрофронтендов, начиная с этапа проектирования и заканчивая организацией команд для миграции существующих или новых проектов на микрофронтенды. Приводятся примеры внедрения микрофронтендов на практике, показаны доступные архитектуры, стратегии автоматизации, описаны шаблоны для интеграции архитектур микрофронтендов с использованием микросервисов или монолитного API. Для системных архитекторов, разработчиков и руководителей ИТ-проектов УДК 004.43 ББК 32.973.26-018.1 Научный редактор: Архитектор решений "Яндекс Маркет" Дмитрий Бардин © 2023 Foliant Publishing House LLP Authorized Russian translation of the English edition of Building Micro-Frontends, ISBN 9781492082996 © 2022 Luca Mezzalira. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. Авторизованный перевод с английского языка на русский издания Building Micro-Frontends, ISBN 9781492082996 © 2022 Luca Mezzalira. Перевод опубликован и продается с разрешения компании-правообладателя O’Reilly Media, Inc. Подписано в печать 03.10.23. Формат 70×1001 /16. Печать офсетная. Усл. печ. л. 25,8. Тираж 1500 экз. Заказ № ТОО «Издательство «Фолиант». Республика Казахстан, 010000, г. Астана, ул. Ш. Айманова, 13. Отпечатано с готового оригинал-макета ООО "Принт-М", 142300, М.О., г. Чехов, ул. Полиграфистов, д. 1 ISBN 978-1-492-08299-6 (англ.) ISBN 978-601-271-949-9 (каз.) © Luca Mezzalira, 2022 © Издание на русском языке. ТОО «Издательство «Фолиант», 2023
Содержание ОБ АВТОРЕ ....................................................................................................................... 11 ПРЕДИСЛОВИЕ ................................................................................................................ 13 ВВЕДЕНИЕ........................................................................................................................ 15 Почему я написал эту книгу........................................................................................... 15 Для кого эта книга........................................................................................................... 16 Как устроена книга ......................................................................................................... 16 Условные обозначения и соглашения ........................................................................... 18 Благодарности ................................................................................................................. 18 ГЛАВА 1. Виды фронтендов ....................................................................................... 21 Микрофронтенд-приложения ........................................................................................ 21 Одностраничные приложения........................................................................................ 23 Изоморфные приложения............................................................................................... 25 Статические сайты .......................................................................................................... 27 Jamstack ............................................................................................................................ 27 Резюме.............................................................................................................................. 28 ГЛАВА 2. Принципы микрофронтендов.................................................................. 29 От монолита к микросервисам....................................................................................... 30 Переход на микросервисы....................................................................................... 32 Введение в микрофронтенды.................................................................................. 33 Принципы работы микросервисов ................................................................................ 35 Разделение на домены ............................................................................................. 36 Культура автоматизации ......................................................................................... 36 Скрытые детали реализации ................................................................................... 36 Децентрализованное управление ........................................................................... 36 Независимое развертывание ................................................................................... 36 Изоляция сбоев......................................................................................................... 37 Хорошая наблюдаемость......................................................................................... 37 Применение принципов к микрофронтендам............................................................... 37 Разделение на домены ............................................................................................. 37 Культура автоматизации ......................................................................................... 38 Сокрытие деталей реализации................................................................................ 38
6 | Содержание Децентрализованное управление ........................................................................... 38 Независимое развертывание ................................................................................... 38 Изоляция сбоев......................................................................................................... 39 Хорошая наблюдаемость......................................................................................... 39 Микрофронтенды не универсальное решение ............................................................. 39 Резюме.............................................................................................................................. 40 ГЛАВА 3. Микрофронтенд-архитектуры и связанные с ними трудности......... 41 Структура принятия решений........................................................................................ 41 Определение микрофронтендов ............................................................................. 42 Предметно-ориентированный подход к микрофронтендам ................................ 43 Как определить ограниченный контекст ............................................................... 45 Композиция микрофронтендов .............................................................................. 46 Маршрутизация для микрофронтендов ................................................................. 48 Взаимодействие между микрофронтендами ......................................................... 50 Микрофронтенды на практике....................................................................................... 53 Zalando ...................................................................................................................... 53 HelloFresh.................................................................................................................. 53 Allegro Tech .............................................................................................................. 53 Spotify........................................................................................................................ 54 SAP ............................................................................................................................ 55 OpenTable.................................................................................................................. 55 DAZN ........................................................................................................................ 55 Резюме.............................................................................................................................. 56 ГЛАВА 4. Типы микрофронтенд-архитектуры....................................................... 57 Структура принятия решений в действии .................................................................... 57 Вертикальное разделение........................................................................................ 58 Горизонтальное разделение .................................................................................... 59 Анализ архитектуры ....................................................................................................... 61 Архитектура и компромиссы.................................................................................. 62 Архитектуры с вертикальным разделением ................................................................. 63 Оболочка приложения............................................................................................. 63 Сложности ................................................................................................................ 65 Реализация системы проектирования .................................................................... 72 Простота и скорость разработки ............................................................................ 75 SEO-оптимизация .................................................................................................... 75 Производительность и микрофронтенды .............................................................. 76 Доступные фреймворки .......................................................................................... 79 Примеры применения.............................................................................................. 80 Характеристики архитектуры................................................................................. 81 Архитектуры с горизонтальным разделением ............................................................. 83 На стороне клиента.................................................................................................. 84 Сложности ................................................................................................................ 87
Содержание | 7 SEO-оптимизация .................................................................................................... 94 Простота и скорость разработки ............................................................................ 95 Примеры применения.............................................................................................. 96 Module Federation..................................................................................................... 97 Iframe....................................................................................................................... 103 Веб-компоненты..................................................................................................... 110 На стороне сервера ................................................................................................ 114 На границе сети...................................................................................................... 124 Резюме............................................................................................................................ 128 ГЛАВА 5. Техническая реализация микрофронтендов....................................... 129 Проект ............................................................................................................................ 129 Введение в Module Federation ...................................................................................... 132 Техническая реализация............................................................................................... 134 Структура проекта ................................................................................................. 134 Оболочка приложения........................................................................................... 136 Микрофронтенд аутентификации ........................................................................ 142 Микрофронтенд каталога...................................................................................... 144 Микрофронтенд управления аккаунтами ............................................................ 146 Развитие проекта ........................................................................................................... 150 Внедрение традиционного приложения .............................................................. 150 Разработка интерфейса оформления заказа......................................................... 152 Реализация динамических удаленных контейнеров........................................... 154 Зависимость от webpack ............................................................................................... 154 Резюме............................................................................................................................ 155 ГЛАВА 6. Создание и развертывание микрофронтендов ................................... 157 Принципы автоматизации ............................................................................................ 158 Быстрая обратная связь ......................................................................................... 159 Частые итерации .................................................................................................... 160 Поддержка команд................................................................................................. 161 Установка ограничений......................................................................................... 161 Разработка стратегии тестирования ..................................................................... 162 Простота и скорость разработки.................................................................................. 162 Горизонтальное и вертикальное разделение ....................................................... 163 Шаблоны микрофронтендов................................................................................. 164 Стратегия деления на среды ................................................................................. 165 Контроль версий............................................................................................................ 165 Монорепозиторий .................................................................................................. 165 Несколько репозиториев ....................................................................................... 169 Возможное будущее для системы контроля версий........................................... 172 Стратегии непрерывной интеграции........................................................................... 173 Тестирование микрофронтендов .......................................................................... 174
8 | Содержание Функции проверки соответствия.......................................................................... 178 Операции, специфические для микрофронтендов.............................................. 180 Стратегии развертывания............................................................................................. 181 Сине-зеленое развертывание и канареечные релизы ......................................... 181 Паттерн "душитель"............................................................................................... 184 Наблюдаемость ...................................................................................................... 186 Резюме............................................................................................................................ 187 ГЛАВА 7. Конвейер автоматизации для микрофронтендов: практический пример ................................................................................................ 189 Подготовка..................................................................................................................... 189 Контроль версий .................................................................................................... 191 Инициализация конвейера .................................................................................... 192 Проверка качества кода......................................................................................... 193 Сборка..................................................................................................................... 194 Проверка после сборки.......................................................................................... 195 Развертывание ........................................................................................................ 197 Итоги по стратегии автоматизации...................................................................... 197 Резюме............................................................................................................................ 198 ГЛАВА 8. Бэкенд-архитектуры, совместимые с микрофронтендами .............. 199 Интеграция API и микрофронтенды ........................................................................... 199 Работа со словарем сервисов ................................................................................ 201 Работа со шлюзом API........................................................................................... 208 Работа с паттерном BFF ........................................................................................ 213 Использование GraphQL с микрофронтендами .................................................. 218 Рекомендации......................................................................................................... 222 Резюме............................................................................................................................ 226 ГЛАВА 9. Миграция с монолита на микрофронтенды: практический пример ........................................................................................................................... 227 Контекст......................................................................................................................... 228 Стек технологий..................................................................................................... 228 Взаимодействие пользователя с платформой...................................................... 229 Технические цели................................................................................................... 232 Стратегия миграции...................................................................................................... 233 Структура принятия решений в действии ........................................................... 233 Разделение одностраничного приложения на несколько поддоменов ............. 237 Выбор технологий.................................................................................................. 240 Детали реализации ........................................................................................................ 244 Задачи оболочки приложения............................................................................... 244 Инициализация приложения................................................................................. 244 Связь для обмена данными ................................................................................... 245
Содержание | 9 Интеграция бэкенда ............................................................................................... 247 Интеграция аутентификации в микрофронтенды............................................... 247 Управление зависимостями .................................................................................. 250 Интеграция дизайна............................................................................................... 251 Общие компоненты ............................................................................................... 252 Реализация канареечных релизов......................................................................... 253 Локализация ........................................................................................................... 255 Резюме............................................................................................................................ 256 ГЛАВА 10. Внедрение микрофронтендов в организации.................................... 259 Зачем нам микрофронтенды?....................................................................................... 259 Связь между организациями и программной архитектурой..................................... 260 Как комитеты изобретают новое? ........................................................................ 261 Команды по функциям и команды по компонентам .......................................... 264 Реализация системы управления для потоков коммуникации ................................. 267 Запрос комментариев............................................................................................. 267 Реестр архитектурных решений ........................................................................... 268 Совершенствование потоков коммуникации ............................................................. 270 Работай, начиная с конца ...................................................................................... 270 Сообщество практиков и общие собрания .......................................................... 271 Управление внешними зависимостями................................................................ 272 Децентрализованная организация ............................................................................... 274 Децентрализация и микрофронтенды .................................................................. 276 Резюме............................................................................................................................ 278 ПРИЛОЖЕНИЕ. Что сами разработчики и архитекторы думают о микрофронтендах..................................................................................................... 279 ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ .......................................................................................... 317
10 | Содержание
Об авторе Лука Меццалира (Luca Mezzalira)1 — главный архитектор решений в AWS, спикер и писатель. В последние 18 лет он работал с разными архитектурами, от фронтенда до облака, всегда подбирая решение под конкретный контекст и проект. 1 См. https://www.linkedin.com/in/lucamezzalira.
Глава 1 | 12
Предисловие Архитектурные стили в информационных технологиях можно сравнить с художественными направлениями — их никто не планирует, и у них нет единого родоначальника, однако рано или поздно они становятся повсеместными. Например, импрессионизм возник во Франции в XIX в. не потому, что несколько художников собрались и договорилась создать его. Скорее, какие-то незримые силы в мире искусства в ответ на появление примитивной фотографии побудили художников передавать свои впечатления, а не повторять реальность. В мире информационных технологий (information technologies, IT) все происходит примерно так же. Что бы там ни думали некоторые разработчики, архитекторы не удаляются в башни из слоновой кости, чтобы выдумать очередную модную новинку. Просто смышленые ребята замечают новые возможности и способы использовать их для решения задач. Если говорить о микросервисах, они зародились в нескольких влиятельных организациях на благодатной почве DevOps, программного управления конфигурациями оборудования (которое привело к контейнеризации) и необходимости выпускать обновления и дополнения в сжатые сроки. Раньше архитектурные стили по несколько лет существовали без имени, прежде чем люди распознавали сам тренд и его отличительные характеристики, по которым его можно было назвать. С микросервисами все было иначе. Архитекторы научились быстро замечать появление новых тенденций и следить за их развитием. В марте 2014 г. Мартин Фаулер (Martin Fowler) и Джеймс Льюис (James Lewis) опубликовали на сайте Фаулера легендарную статью1 , описывающую новый архитектурный стиль под названием "микросервисы". Термин придумали не они, но они способствовали популярности нового течения. Думаю, авторы оказали отрасли большую услугу, четко описав характеристики микросервисов еще на заре их появления. Благодаря этому мы быстро определились, что входит в понятие микросервисов, а что — нет, и это сэкономило разработчикам долгие месяцы или даже годы проб и ошибок. Фаулер и Льюис описывали совершенно новое явление, поэтому они сделали несколько прогнозов в отношении того как микросервисы повлияют на проектирование пользовательского интерфейса: поскольку сервисы в этой архитектуре логиче- 1 См. https://oreil.ly/mZEYB.
14 | Предисловие ски отделены друг от друга, это должно было привести и к разделению пользовательских интерфейсов. К сожалению, в реальном мире этот прогноз все никак не сбывался... до недавнего времени. Оказывается, пользовательский интерфейс монолитен по своей природе: пользователи хотят взаимодействовать с приложением из одного места и ожидают единообразия и согласованности. Теоретически возможно создать раздельный интерфейс, но разработчикам не хватало подходящего фреймворка и инструментов. К счастью, такие инструменты, наконец, появились. Данная книга посвящена этому важному аспекту разработки микросервисов. Лука Меццалира четко описал проблему, а затем современные варианты ее решения. Сначала он рассказывает о проблемах, с которыми сталкиваются фронтендразработчики, а затем рассматривает различные аспекты микрофронтендов. В книге вы найдете не только техническую информацию, но и общий взгляд на экосистему: например, как разделить монолитный пользовательский интерфейс или как стандартные инженерные практики, вроде непрерывной интеграции, сочетаются с новой технологией. Эта книга будет полезна всем разработчикам, создающим микросервисы, даже если они не работают с пользовательским интерфейсом. — Нил Форд (Neal Ford), директор, программный архитектор и идейный вдохновитель Thoughtworks, Inc.
Введение В начале декабря 2016 г. я впервые отправился в Токио. Я пробыл там всего неделю, но в следующие месяцы мне довелось не раз туда вернуться. Четко помню, как садился в самолет в лондонском Хитроу и мысленно готовился к 12-часовому перелету. На тот момент я уже пару недель был в разъездах и летал на другой край света: на конференции в районе Сан-Франциско и на мероприятие в Лас-Вегасе. Тогда я работал над потрясающей платформой, как у Netflix, только на спортивную тематику, — на ней можно было смотреть трансляции и записи соревнований в разных странах более чем на 30 типах устройств (ноутбук, смартфон, игровая консоль, ТВ-приставка и Smart TV). Год подходил к концу, и как программный архитектор я должен был предложить новую архитектуру, с помощью которой сотни действующих и новых разработчиков в разных городах и странах могли бы работать над проектом без потери продуктивности, а лучше еще продуктивнее. Я занял свое место в салоне и постарался расслабиться. Я не до конца отдохнул от поездки в Лас-Вегас и не особо хотел провести в самолете еще 12 часов, но было любопытно увидеть Японию. Через несколько минут мне принесли первый бокал шампанского. Впервые в жизни я летел бизнес-классом в очень удобном кресле, где было достаточно места для работы. Через час я достал ноутбук из рюкзака и начал составлять генеральный план. Лететь оставалось больше 10 часов, так что я собирался начать работу над масштабным проектом, который порадует миллионы пользователей по всему миру. Я и не подозревал, что в следующие несколько часов мои представления об архитектуре кроссплатформенного фронтенд-приложения круто поменяются. В этой книге я расскажу о моем знакомстве с миром микрофронтендов, поделюсь советами по проектированию и запуску такой архитектуры и, наконец, опишу преимущества и недостатки этого подхода. Это поможет вам понять, подойдет ли микрофронтенд-архитектура для вашего следующего проекта. Итак, начнем. Почему я написал эту книгу Я начал задумываться о микрофронтендах в 2015 г., и в последующие годы у меня была возможность реализовать их в крупной организации с распределенными ко-
16 | Введение мандами и сотнями разработчиков, так что я изучил их плюсы и минусы. Я рассказывал о своем опыте на конференциях, вебинарах и встречах, где знакомился с разными специалистами в этой сфере, слушал их истории, отвечал на вопросы и работал с компаниями, которые иначе реализовывали эту парадигму. Практики, представленные в этой книге, я предлагал крупным организациям по всему миру, от Северной Америки до Австралии. На этапах проектирования и реализации я сталкивался с самыми разными трудностями. Все усвоенные уроки я тоже описываю на этих страницах. В этой книге собраны мои исследования и практический опыт за несколько лет работы. Я поделюсь примерами из реальной жизни, чтобы показать ключевые факторы успешного применения микрофронтендов. Здесь не будет километров кода, зато мы поговорим об архитектуре, ментальных моделях и методологиях, которые я изучил в ходе реализации микрофронтендов. Мне кажется, лучше рассмотреть не один подход в деталях, а несколько методов с их достоинствами и недостатками. Эта книга будет полезна всем, кто хочет понять, как использовать этот архитектурные стиль, даже если через несколько лет непременно появится что-то другое. Эти знания помогут вам реализовывать успешные проекты по созданию микрофронтендов. Для кого эта книга Эта книга предназначена для разработчиков, архитекторов и технических директоров, которые планируют развивать бизнес и фронтенд-приложения. Здесь вы найдете ментальные модели и основанные на опыте рекомендации по работе с микрофронтенд-архитектурой, а также принципы и решения для разных подходов. Эта книга поможет вам приступить к проекту по созданию микрофронтенда с правильным настроем и подготовиться к трудностям, с которыми вы можете столкнуться при реализации проекта. Здесь описываются технические архитектуры и реализации, а также все этапы реализации микрофронтендов, от проектирования до организации команд для миграции имеющихся или создания новых проектов на микрофронтендах. Как устроена книга Книга разделена на главы по темам, и читатель может спокойно начать с нужной главы, пропустив остальные, хотя лучше все же читать книгу по порядку. В работе книгу можно использовать как справочник, сразу переходя к нужному разделу. Вот темы книги. Глава 1. Виды фронтендов. Из этой главы вы узнаете, что привело к появлению микрофронтендов, а также какие еще архитектуры доступны для фронтендов.
Введение | 17 Глава 2. Принципы микрофронтендов. В этой главе мы проанализируем принципы микросервисов и их применимость в разработке фронтенда. В частности, мы рассмотрим концепции, на которые будем опираться при реализации. Глава 3. Микрофронтенд-архитектуры и связанные с ними трудности. Здесь приводится главная информация о микрофронтендах. Мы рассмотрим четыре ключевых компонента, необходимых для создания успешной микрофронтенд-архитектуры. Структура принятия решений помогает выбрать подход к определению, композиции, оркестрации и взаимодействию. Затем остается только спроектировать систему во всех аспектах, примеры — стратегия автоматизация, система проектирования и т. д. Глава 4. Типы микрофронтенд-архитектуры. В этой главе мы рассмотрим все варианты реализации микрофронтендархитектуры, включая их плюсы и минусы, а также сценарии применения для каждого варианта. Глава 5. Техническая реализация микрофронтендов. Опираясь на анализ архитектуры из главы 4, мы реализуем проект по разработке микрофронтенда. Для выбора архитектуры воспользуемся структурой принятия решений. Глава 6. Создание и развертывание микрофронтендов. В этой главе приводятся рекомендации по разработке успешных стратегий автоматизации для микрофронтендов. Например, мы рассмотрим различные стратегии работы с репозиториями, ключевые этапы конвейера непрерывной интеграции и развертывание микрофронтендов в среду эксплуатации. Глава 7. Конвейер автоматизации для микрофронтендов: практический пример. Изучив теорию в главе 6, мы рассмотрим пример стратегии автоматизации для микрофронтендов. Это будет пример из реальной жизни, который можно применить к действующим конвейерам автоматизации. Глава 8. Бэкенд-архитектуры, совместимые с микрофронтендами. В этой главе мы обсудим интеграцию микрофронтенд-архитектуры с монолитным уровнем API или микросервисами. Мы рассмотрим такие паттерны бэкендов, как Backend-for-Frontend (BFF), шлюзы API и словарь сервисов. Глава 9. Миграция с монолита на микрофронтенды: практический пример. В этой главе мы рассмотрим возможный сценарий по миграции с устаревшего фронтенда на микрофронтенды. Команды ACME Inc. начнут миграцию на распределенную фронтенд-архитектуру и будут принимать разные решения на пути к своим целям.
18 | Введение Глава 10. Внедрение микрофронтендов в организации. В последней главе книги мы сосредоточимся на вашей организации. Архитектура должна не только соответствовать техническим требованиям проекта, но и помогать сотрудникам продуктивно работать. Приложение. Что сами разработчики и архитекторы думают о микрофронтендах. Сообществу есть что сказать по этому поводу. Я собрал разные истории и рекомендации от людей, которые реализовывали микрофронтенды в своих организациях. Условные обозначения и соглашения В книге используются следующие типографские условные обозначения: курсивный шрифт обозначает новые термины, имена и расширения файлов, имена каталогов; жирный шрифт обозначает URL-адреса, адреса электронной почты, элементы интерфейса программ; моноширинный шрифт используется для листингов программ, а также внутри абзацев для ссылки на элементы программ, такие как переменные или имена функций, базы данных, типы данных, переменные среды, инструкции и ключевые слова; жирный моноширинный шрифт показывает команды либо другой текст, который должен быть набран пользователем, а также зарезервированные в языке программирования слова; моноширинный шрифт курсивом показывает текст, который должен быть заменен значениями, передаваемыми пользователем, либо значениями, определяемыми по контексту, а также комментарии в листингах программ. Данный элемент обозначает подсказку или совет. Данный элемент обозначает общее замечание. Благодарности В первую очередь я хочу поблагодарить свою семью, свою девушку Маэлу и своих дочерей за то, что они поддерживают меня и дают мне силы идти вперед. Спасибо всем, кто каждый день вдохновляет меня при самых разных обстоятельствах.
Введение | 19 Огромное спасибо DAZN за то, что позволили мне реализовать микрофронтендархитектуру и изучить все ее преимущества, а также за то, что верили моим идеям и суждениям. Спасибо издательству O’Reilly за возможность написать книгу о микрофронтендах. Отдельное спасибо Дженнифер Поллок и Анджеле Руфино за то, что поддерживали меня все эти месяцы, пока я писал книгу, и предоставляли полезную обратную связь. Спасибо Эрин Бреннер, моему потрясающему редактору, которая помогала мне формулировать мои мысли. За предисловие к этой книге спасибо моему виртуальному наставнику, Нилу Форду, которого я называю Архитектором с большой буквы. Наконец, спасибо всем, кто работал над рукописью и давал советы по улучшению книги. И спасибо всем участникам моих выступлений и семинаров за то, что делились своим опытом и дали мне материал для написания этой книги.
20 | Введение
Г Л А В А 1 Виды фронтендов Помню времена, когда веб-приложения назывались многофункциональными интернет-приложениями (rich internet applications, RIA), чтобы их можно было отличать от более статичных традиционных корпоративных сайтов. Сегодня мы используем самые разные веб-приложения для выполнения повседневных задач: мы можем заказывать пиццу или печать визиток, смотреть любимые фильмы и трансляции и управлять банковским счетом, не вставая с дивана. Начать проект можно с одностраничного или изоморфного приложения, код которого будет выполняться на сервере или на стороне клиента, или даже с набора статических страниц в облаке либо в локальной инфраструктуре. Вариантов множество, но все они подходят для конкретных вариантов применения, а универсального решения не существует. Выбирая архитектуру, технические директора, руководители, архитекторы или простые разработчики руководствуются конкретными требованиями проекта и задачами, которые нужно будет решать по ходу. Прежде чем перейти к главной теме этой книги, давайте рассмотрим, какие еще архитектуры доступны для фронтенда. Микрофронтенд-приложения Микрофронтенды — это новая архитектура в стиле микросервисов. В двух словах, мы разделяем монолитную кодовую базу на фрагменты, над которыми работают отдельные команды, в офисе или удаленно, без потери скорости разработки. Спроектировать API и внедрить логику в микросервис — это самая простая часть. Всю сложность микросервисной архитектуры мы поймем, когда увидим, сколько факторов нужно учесть и сколько задач нужно решить. Да, микросервисная архитектура повышает гибкость и автономность доменов1 , но при этом значительно усложняет наблюдаемость, автоматизацию и обнаруживаемость (discoverability) системы. 1 Домен — предметная область, в которой работает бизнес. Сюда входит все, с чем предприятие повседневно имеет дело, включая правила, процессы, идеи, специфичную для предприятия терминологию и все, что связано с его пространством решений, независимо от того, описано ли это на предприятии или нет.
22 | Глава 1 Например, мы создаем бизнес-логику сервиса, а затем пытаемся разобраться, как клиент будет обращаться к нашему API. Если это внутренний микросервис, который будет взаимодействовать только с другими микросервисами, нужно продумать модель обеспечения безопасности. Затем мы должны оценить трафик к микросервису и реализовать автомасштабирование, кэширование или другие тактики, чтобы решить вопрос с пиковыми нагрузками. Нужно также учесть возможные сбои микросервисов. Например, мы в состоянии отключать некоторые возможности, сохраняя общий функционал, чтобы пользователи могли продолжить работу, или обеспечить избыточность с помощью несколько зон или регионов доступности. Микросервисы упрощают бизнес-логику, но усложняют систему на многих других уровнях — сети, хранилище, протоколы коммуникации, безопасность и т. д. Это можно сказать и о микрофронтендах. В случае ощутимого упрощения бизнеслогики и уменьшения сложности кода увеличиваются издержки на автоматизацию, управление, наблюдаемость и коммуникации. Как и другие архитектуры, микрофронтенды подходят не для всех проектов. Более привычные паттерны, например рендеринг на стороне сайта или Jamstack, по-прежнему считаются хорошими вариантами. Микрофронтенды предлагают новый способ структурирования фронтенд-приложений, попутно решая некоторые технические и организационные проблемы с масштабированием. Я не раз видел архитектуры, которые прекрасно выглядели на бумаге, но реализовать их в том же виде в реальном мире не удавалось, потому что создатель не учитывал окружение и контекст (организационную структуру, корпоративную культуру, навыки разработчиков, сроки и т. д.). Закон Конвея в действии: "При проектировании систем (причем не только информационных), организации неизбежно создают проекты, копирующие их собственные коммуникационные структуры"2 . Правда, можно применить "обратный маневр Конвея" и выстраивать структуру команд и организаций по подобию желаемой архитектуры, а не наоборот. Мне кажется, стоит внимательно изучить разные архитектуры и принципы работы разных систем, чтобы с помощью этих знаний и инструментов побороть закон Конвея, решив технические и организационные проблемы. Микрофронтенды в сочетании с микросервисами и эффективной культурой разработки, в которой каждый отвечает за свой домен, помогут повысить гибкость организации и ускорить вывод продукта на рынок. Микрофронтенды можно использовать в комбинации с разными бэкенд-архитектурами, например монолитом или сервис-ориентированным подходом, но лучше всего они сочетаются с микросервисами, потому что мы можем разделять приложение на компоненты, которые развиваются вместе. 2 Melvin E. Conway "How Do Committees Invent?" (Мелвин Конвей "Как комитеты изобретают новое") Thompson Publications, Inc., 1968. Ссылка доступна на 4 октября 2021 г.: https://www.melconway.com/ Home/Committees_Paper.html.
Виды фронтендов | 23 Одностраничные приложения Одностраничные приложения (single-page application, SPA) состоят из одного или нескольких файлов JavaScript, которые включают все фронтенд-приложение, обычно загружаемое заранее. Когда веб-серверы и сети доставки контента (content delivery network, CDN) поставляют страницу index.html, одностраничное приложение загружает JavaScript, CSS и дополнительные файлы, чтобы отобразить нужную часть приложения. У одностраничных приложений много преимуществ. Например, клиент загружает код только один раз, в начале жизненного цикла, и вся логика приложения доступна на протяжении всего сеанса пользователя. Обычно одностраничные приложения взаимодействуют с API, обмениваясь данными с уровнем хранилища в бэкенде, который также называется стороной сервера. Нам не приходится лишний раз посылать к серверу запросы и ждать ответы для загрузки дополнительной логики приложения, и все представления отрисовываются сразу. Это позволяет улучшить пользовательский опыт, потому что пользователь сможет переходить из одной части приложения в другую почти без задержек, как если бы приложение было установлено на компьютере или мобильном устройстве. Кроме того, одностраничное приложение полностью управляет механизмом маршрутизации на стороне клиента. То есть, когда приложение меняет представление, оно соответствующим образом перезаписывает URL, и пользователь может поделиться ссылкой на страницу или добавить этот URL в закладки, чтобы начинать работу с определенной страницы. При создании одностраничных приложений мы сами решаем, как разделить логику приложения между сервером и клиентом. Например, это может быть "толстый" клиент и "тонкий" сервер, т. е. логика в основном будет храниться на стороне клиента, а сервер будет отвечать за хранение данных. Или это может быть "тонкий" клиент и "толстый" сервер, т. е. логика будет выполняться на бэкенде, а клиент будет просто реагировать на состояние, предоставляемое API. В последние десятилетия популярным становился то один, то другой подход. Споры не утихают, но я считаю, что у обоих вариантов есть свои достоинства и недостатки, и все зависит от типа создаваемого приложения. Например, я предпочитаю создавать "тонкого" клиента и "толстый" сервер для кроссплатформенных приложений, чтобы можно было спроектировать функцию один раз и научить всех клиентов на разных платформах реагировать на состояние приложения, хранимое на сервере. Если я создаю приложение для компьютера и для меня важно, чтобы данные хранились локально, я выбираю "толстого" клиента и "тонкий" сервер. В итоге логикой состояния можно управлять на клиенте, а не с обеих сторон, а сервер используется для синхронизации данных. Правда, одностраничные приложения подходят не для всех сценариев. Первая загрузка может занимать больше времени, чем при использовании других архитектур, потому что мы загружаем приложение целиком, а не только нужное представ-
24 | Глава 1 ление. Если приложение спроектировано некорректно, оно может загружаться слишком долго, особенно при нестабильном соединении на смартфонах и планшетах. Сейчас мы можем разными способами кэшировать контент прямо на клиенте, чтобы немного исправить ситуацию. Кроме самых популярных способов, таких как разделение кода или ленивая загрузка пакетов JavaScript, существуют и прогрессивные веб-приложения, которые предоставляют набор новых возможностей на основе Service Worker. Service Worker — это скрипт, который браузер выполняет в фоновом режиме отдельно от веб-страницы, чтобы предоставлять такие возможности, как push-уведомления или работа без подключения к сети. Благодаря этим скриптам мы можем создавать стратегию кэширования для вебприложения с нативными API в браузерах. При таком подходе мы сначала берем данные из кэша, а не с сервера, и сейчас это самая популярная стратегия поставки контента пользователю. Если ресурс кэширован и доступен без передачи по сети, мы сначала возвращаем его, не пытаясь ничего загружать с сервера. Если в кэше его нет, он загружается и кэшируется для дальнейшего использования. Это очень простая, но эффективная стратегия, которая улучшает пользовательский опыт, особенно при использовании веб-приложений на мобильных устройствах. Еще один недостаток проявляется в связи с SEO-оптимизацией (search engine optimization — оптимизация для поисковых систем). Когда краулер (поисковый робот, который перебирает веб-страницы и создает индекс данных) попытается понять, как проходить по приложению или сайту, ему будет сложно индексировать все содержимое одностраничного приложения, если мы не подготовим альтернативные способы его извлечения. Обычно, когда мы хотим улучшить индексирование для одностраничного приложения, мы создаем решение специально для краулера. Например, Netflix отключает геозонирование, когда обнаруживает, что к приложению обращается краулер, вместо того, чтобы поставлять контент, который пользователь увидел бы в зависимости от страны, указанной в URL. Это очень удобно, ведь движок краулера обычно находится в одном месте, из которого он индексирует сайт по всему миру. Загрузка всей логики приложения сразу может привести к утечкам памяти, когда пользователь переходит от одного представления к другому, если код плохо реализован и не может корректно удалять неиспользуемые объекты. Это было бы серьезной проблемой в крупных приложениях, так что пришлось бы потратить несколько дней или даже недель на рефакторинг и улучшение кода одностраничного приложения. Будет еще хуже, если пользователь попытается загрузить одностраничное приложение на не самое производительное устройство, например и Smart TV или ТВ-приставку. Обычное дело: приложение прекрасно работает на MacBook Pro с четырехъядерным процессором и очень тормозит на устройствах попроще. Наконец, у одностраничного приложения есть недостатки с организационной точки зрения. Если это большое приложение, управляемое командами, которые работают над одной кодовой базой в офисе или удаленно, приложение в конце концов превратится в нагромождение подходов и решений, в котором сложно разобраться.
Г Л А В А 2 Принципы микрофронтендов В начале своей карьеры я работал в небольших и средних командах, разрабатывавших монолитные приложения, где весь функционал платформы умещался в артефакте, который затем развертывался на веб-сервере. Создавая монолит, мы пишем много кода, все компоненты которого должны гармонично работать вместе. По моему опыту, в стремлении оптимизировать логику приложения легко можно перестараться. Выделяя части кода, которые можно использовать многократно, мы нередко только усложняем кодовую базу, и иногда усилия по обслуживанию сложной логики не окупаются в долгосрочной перспективе. Код, который выглядел очень простым в момент написания, через несколько месяцев, к сожалению, может стать совершенно нечитаемым. В последние десять лет набирают популярность публичные облака, вроде Amazon Web Services (AWS) или Google Cloud. Сегодня мы делегируем им все больше задач, чтобы сосредоточиться на том, что действительно важно для бизнеса: на услугах, которые мы предлагаем конечным пользователям. В облаке масштабировать проекты стало очень просто, но монолитные приложения требуют увеличения масштаба всей системы, а не только нужных частей, и это приводит ко множеству проблем, если система не разделена на модули и не написана в соответствии с высокими стандартами. Чем больше разрастается команда, работающая в офисе или удаленно, тем сложнее иметь дело с монолитной кодовой базой — из-за издержек на коммуникации и централизованного принятия решений, когда несколько человек решают за всех. Со временем работа над новыми функциями монолитного приложения все больше замедляется по сравнению с начальными этапами, когда все было проще и меньше, включая сложности и риски. Кодовую базу монолитных приложений приходится развертывать целиком при каждом изменении, а значит, повышаются риски нарушить работу API в производственной среде, внедрить новые баги и наделать лишних ошибок, особенно если кодовая база не отличается надежностью и не тестируется со всех сторон. Для того чтобы решить эти и многие другие проблемы, компании могут разделить монолитную кодовую базу на небольшие кодовые базы, ограниченные доменами, — микросервисы. Сегодня микросервисная аркатура хорошо известна и используется многими организациями по всему миру. Микросервисы делят кодовую базу на части с опреде-
30 | Глава 2 ленным функционалом, причем каждая часть существует независимо от других и полностью принадлежит одной команде, которая отвечает за ее развитие. Разработчики поддерживают такую бизнес-логику, потому что им проще воспринимать микросервис, решающий одну задачу, чем несколько тысяч строк кода. Когнитивная нагрузка на разработчиков при таком подходе гораздо ниже, чем при работе с монолитной кодовой базой. Еще одно серьезное преимущество такой архитектуры — возможность масштабировать приложение частями и выбирать подход для каждого конкретного микросервиса, а не для всего приложения. Конечно, работа с микросервисами не обходится без трудностей. Если мы хотим держать распределенную систему под контролем, нам придется инвестировать в автоматизацию, наблюдаемость и мониторинг. Кроме того, нужно правильно определить границы микросервиса. Например, если микросервис слишком мал, чтобы самостоятельно выполнять задачу, и полагается на другие микросервисы, они начинают зависеть друг от друга, и их придется развертывать вместе. Если таких сервисов несколько, все переплетется и перепутается, и развивать такую систему будет очень сложно. Микросервисы не панацея. В некоторых сценариях усилия по созданию сложной микросервисной архитектуры не окупаются. Существуют и другие варианты архитектуры для разработки программного обеспечения, и хотя использовать микросервисы сейчас очень модно, выбирайте их только тогда, когда они действительно отвечают вашим требованиям. Микрофронтенды — это новый подход к созданию интерфейса приложения с четким разделением на команды и домены. Эта стратегия заметно отличается от привычной монолитной архитектуры, но помните, что ни микросервисы, ни микрофронтенды нельзя считать универсальным средством для любых ситуаций. Давайте узнаем, как они работают и для каких ситуаций подходят. От монолита к микросервисам Начиная новый проект или новый бизнес, который предлагает онлайн-услуги, в первую очередь, мы должны оценить свои шансы на успех. Обычно сначала мы определяем стек технологий — список технических решений для создания и обслуживания будущего приложения, — с которым мы умеем работать. Отбросив все излишества и начав с минимума функций, мы создадим минимально жизнеспособный продукт (minimum viable product, MVP) и сможем быстро получить обратную связь о нашей бизнес-идее напрямую от пользователей. Обычно мы проектируем уровень API в виде монолита, чтобы создать один конвейер непрерывной интеграции и развертывания. Внедрить в монолитное приложение наблюдаемость очень легко — достаточно запустить по агенту на каждой виртуальной машине или в каждом контейнере, чтобы узнавать состояние работоспособности серверов приложения. Процесс развертывания очень прост, ведь нам достаточно одной стратегии автоматизации для всего уровня API и одной стратегии
Принципы микрофронтендов | 31 развертывания и выпуска, а когда трафик начинает расти, мы увеличиваем горизонтальный масштаб, запуская сколько угодно серверов приложений. Поэтому монолитные архитектуры считаются хорошим вариантом для новых проектов, ведь так мы сможем сразу заняться бизнес-логикой приложения, не думая об автоматизации и других аспектах. Где мы будем хранить наши данные? Какая база данных лучше всего соответствует потребностям проекта — графовая, NoSQL или SQL? Где мы разместим базу данных — в облаке или локально? Ответы зависят от нашего сценария. Например, если нам нужно создать четкое представление данных для заполнения пользовательского интерфейса, скорее всего, лучше выбрать базу данных NoSQL. При этом для сопоставления связей между пользователями, как в приложении социальных сетей, лучше всего подойдет графовая база данных. Наконец, нужно выбрать технологию для представления данных, например браузер или мобильное приложение. Мы можем выбрать знакомый фреймворк JavaScript или любимый язык программирования. Мы можем использовать рендеринг на стороне сервера или одностраничное приложение. Кроме того, мы определяем соглашения по написанию кода, линтинг и правила CSS. В итоге мы получим схему, как на рис. 2.1. Рис. 2.1. Монолит с одностраничным приложением
32 | Глава 2 Затем остается надеяться, что наши идеи и решения окажутся удачными, и у нашего сервиса или продукта будет много пользователей. Переход на микросервисы Допустим, наше приложение оказалось успешным, и компания решает расширить команду и нанять больше инженеров, специалистов службы поддержки, scrumмастеров и т. д. Анализируя журналы и панели мониторинга, мы понимаем, что не все наши API можно органично масштабировать. Некоторые из них хорошо кэшируются, а значит, сети доставки контента обслуживают большинство клиентов. Нагрузка на серверы серьезно возрастает, лишь когда API не кэшируются. К счастью, эта проблема затрагивает только небольшую часть наших API. На этом этапе уже есть смысл делить монолит, тем более что мы расширяем штат и лучше понимаем, как работает система. Рис. 2.2. Микросервисы с одностраничным приложением
Принципы микрофронтендов | 33 Если мы переходим на микросервисы, следует пересмотреть стратегию баз данных. Микросервисы не должны использовать общие базы данных. При необходимости можно частично реплицировать данные, чтобы микросервисы быстрее возвращали ответ. В результате мы создаем единообразную экосистему со множеством динамичных компонентов, где у нас будет больше свободы и меньше рисков. Каждая команда отвечает за свой набор микросервисов. Команды сами выбирают базы данных, структуры для схем, способы кэширования для быстрого ответа и язык программирования. По сути, мы создаем систему, в которой каждая команда может принимать решения и нести ответственность за свои сервисы в производственной среде, а общее решение для всей системы не требуется — за некоторыми исключениями, вроде журналирования и мониторинга. Такая система изображена на рис. 2.2. Чего-то по прежнему не хватает. Мы можем масштабировать уровень API и хранилище, используя хорошо определенные паттерны и подходы, но что если бизнес растет и нужно расширять еще и команды фронтенд-разработчиков? Введение в микрофронтенды Раньше у нас было мало вариантов масштабировать фронтенды, да и особой необходимости для этого до недавнего времени не было, ведь обычно у нас были "толстый" сервер со всей бизнес-логикой и "тонкий" клиент, который отображал результаты вычислений, предоставляемые сервером. За последние несколько лет многое изменилось. Ожидания пользователей растут, они хотят больше интерактивности и удобства при использовании веб-платформ. Появились компании, предлагающие сервисы по подписке, и эта модель нравится многим людям. Сейчас мы смотрим видео по запросу, не дожидаясь эфира, слушаем музыку в сервисе, не покупая альбом, и заказываем еду в мобильном приложении, не звоня в ресторан. От нас требуется улучшать пользовательский опыт и предоставлять пользователю простой способ удовлетворить потребности, при этом не забывая про качество контента или услуг. Раньше для этого пришлось бы выделить части приложения в общую библиотеку компонентов, абстрагируя некоторую бизнес-логику, чтобы ее можно было использовать повторно в разных частях приложения. Мы попытались бы использовать повторно как можно больше кода. Я не против решений, которые по-прежнему работают и хорошо подходят для многих проектов, но мы сталкиваемся со множеством трудностей при их реализации. Например, если команда разработчиков достаточно большая, обычно правила для кодовой базы определяются один раз, а затем мы придерживаемся их месяцами и даже годами, потому что иначе придется многое переделывать по всей кодовой базе, а это долго и дорого. Принимая решения, мы часто идем на компромисс и чемто жертвуем из-за нехватки времени, требований к согласованности или просто лени. Нужно понимать, что бизнес, как и технологии, неизбежно развивается.
34 | Глава 2 Выделение абстракций в коде — это не универсальное решение. Если поторопиться, недостатков будет больше, чем достоинств. Я часто видел, как такая стратегия многократно усложняла код, при этом абстрактный фрагмент повторно использовался в проекте всего пару раз. Разработчикам иногда случается перемудрить с решениями, которые они планируют использовать десятки и сотни раз, а в действительности применят всего в нескольких местах. Если мы будем использовать одни и те же библиотеки в разных проектах и командах, мы рискуем усложнить кодовую базу, затратить больше усилий на тестирование вручную или увеличить издержки на коммуникации, при этом не получив сопоставимых преимуществ. Для фронтенда тоже следует рассмотреть монолитную архитектуру. В долгосрочной перспективе такой подход не позволит нам совершенствовать архитектуру, особенно если мы работаем на платформах, которые должны быть доступны пользователям долгие годы, или над приложением трудятся распределенные команды в разных часовых поясах. Рис. 2.3. Микросервисы с микрофронтендами. Это обзорная схема, которая показывает их взаимодействие
Г Л А В А 6 Создание и развертывание микрофронтендов В этой главе мы обсудим еще один важный аспект распределенных систем вообще и микрофронтендов в частности — надежную стратегию автоматизации. Микросервисы повышают гибкость и масштабируемость архитектуры, поддерживая горизонтальное масштабирование API в зависимости от входящего трафика и позволяя выбирать паттерн под конкретные задачи, а не использовать универсальное решение для всех API, как в монолите. Да, у микросервисов много достоинств, но такой архитектурой сложнее управлять, потому что для ее создания и развертывания приходится выполнять много повторяющихся действий. Если вы собираетесь работать с микросервисной архитектурой, придется потратить немало времени и усилий на создание конвейеров непрерывной интеграции (continuous integration, CI) и непрерывного развертывания (continuous deployment, CD), о которых мы подробно поговорим в этой главе. Учитывая, как быстро современный бизнес может менять направление, недостаточно продумать конвейер CI/CD в начале проекта — мы должны развивать его непрерывно, на протяжении всего жизненного цикла приложения. Одна из главных характеристик надежной стратегии автоматизации — гарантия воспроизводимости программных пакетов и быстрый цикл обратной связи для разработчиков. Это относится и к микрофронтендам. Создавая продуманные конвейеры автоматизации, мы повышаем шансы нашего проекта на успех и получаем надежный фундамент для экспериментов, а также для создания и развертывания решений. В некоторых проектах микрофронтендов может быть столько, что управление системой потребует серьезных усилий. Следуя структуре принятия решений о микрофронтендах из главы 3, мы должны выбрать между горизонтальным разделением (несколько микрофронтендов в представлении) и вертикальным (одно представление — один микрофронтенд). При горизонтальном разделении в конвейерах автоматизации придется управлять десятками или даже сотнями программных пакетов. Для этого нужны специальные инструменты. Вертикальное разделение тоже потребует дополнительных усилий, но подход к автоматизации почти не отличается от традиционных методов, используемых для одностраничных приложений. Главное различие в том, что программных пакетов может быть несколько, а код нужно будет создавать и оптимизировать по-разному.
158 | Глава 6 В этой главе мы подробно рассмотрим эти особенности, начиная со стратегии быстрой и надежной автоматизации, а также эффективных инструментов для повышения простоты и скорости разработки. Затем мы проанализируем рекомендации по непрерывной интеграции и развертыванию микрофронтенда. Наконец, мы познакомимся с функциями приспособленности для автоматизации и тестирования характеристик архитектуры на различных этапах конвейера. Принципы автоматизации В микрофронтенд-архитектуре конвейер автоматизации нужно совершенствовать постоянно, иначе команды будут работать медленнее и начнут сомневаться, стоит ли развертывать свой продукт в среде эксплуатации. В худшем случае проект провалится, что приведет к разочарованию сотрудников и убыткам для бизнеса. Очень важно продумать автоматизацию, чтобы разработать эффективную стратегию непрерывной интеграции, непрерывной поставки или непрерывного развертывания. ʃʛʥʦʛʦʱʘʣʖʵʞʣʨʛʙʦʖʬʞʵ ʣʛʥʦʛʦʱʘʣʖʵʥʤʧʨʖʘʠʖ ʣʛʥʦʛʦʱʘʣʤʛʦʖʝʘʛʦʨʱʘʖʣʞʛ В этой книге мы не будем рассматривать эти три стратегии подробно, но обозначим их главные различия. Непрерывная интеграция — это стратегия, в рамках которой при каждом слиянии с главной ветвью запускается конвейер автоматизации, чтобы со всех сторон протестировать кодовую базу, прежде чем она попадет в ветвь. Непрерывная поставка — это продолжение непрерывной интеграции: после тестов мы создаем программный пакет, готовый к развертыванию по щелчку на панели развертывания. Непрерывное развертывание — это следующий шаг, на котором мы развертываем в среде эксплуатации программные пакеты, созданные после фиксации кода в системе контроля версий. Если хотите узнать больше, читайте книгу "Непрерывное развертывание ПО" ("Continuous Delivery") Дэвида Фарли (David Farley) и Джеза Хамбла (Jez Humble). Для того чтобы обеспечить высокую скорость и надежность автоматизированных процессов, мы должны соблюдать некоторые принципы: максимально быстрый цикл обратной связи; непрерывное улучшение стратегии автоматизации; помощь командам в принятии верных решений об их микрофронтендах; определение границ, в которых команды могут самостоятельно принимать решения, при этом используя набор стандартных инструментов; разработка надежной стратегии тестирования. Давайте подробно обсудим этим принципы.
Создание и развертывание микрофронтендов | 159 Быстрая обратная связь Одна из главных характеристик надежного конвейера автоматизации — быстрое выполнение. Каждый конвейер автоматизации предоставляет разработчикам обратную связь. Если мы сразу видим, как наш код вписался в кодовую базу, мы чувствуем себя увереннее при его написании. Эффективный автоматизированный процесс выполняется часто и дает обратную связь в течение нескольких секунд, максимум минут. Разработчикам нужна постоянная обратная связь, потому что она мотивирует их чаще выполнять тесты и проверки в конвейере автоматизации. Затем нужно анализировать, какие шаги можно выполнять параллельно, а какие — последовательно. В идеале ваше решение должно поддерживать обе стратегии. Параллельное выполнение, например, можно настроить для модульного тестирования, чтобы не ждать, пока друг за другом будут выполняться сотни и даже тысячи тестов. На некоторых этапах параллелизация будет неэффективна. Нужно тщательно все продумать, чтобы выбрать подходящую стратегию на каждом этапе. Микрофронтенды по определению упрощают оптимизацию стратегии автоматизации. Поскольку мы делим приложение на небольшие части, нужно будет тестировать и собирать меньше кода, так что каждый этап CI будет выполняться очень быстро. Но быстро не значит просто. Поскольку схожих конвейеров автоматизации будет несколько, следует руководствоваться принципами модели "инфраструктура как код" (Infrastructure as Code, IaC), чтобы запускать новые конвейеры, не создавая и не изменяя их вручную. ɾʣʪʦʖʧʨʦʩʠʨʩʦʖʠʖʠʠʤʚ Инфраструктура как код — это подход к управлению инфраструктурой (сети, виртуальные машины, балансировщики нагрузки и т. д.) с использованием описательной модели. То есть к инфраструктуре применяются принципы, которые действуют для исходного кода. Скажем, если один и то же исходный код должен всегда генерировать один и тот же двоичный файл, модель IaC должна при каждом применении создавать одинаковое окружение. Например, AWS CDK позволяет использовать TypeScript или JavaScript, чтобы определять инфраструктуру проекта в аккаунте AWS. Давайте в качестве примера возьмем этот фрагмент кода, в котором создается дистрибутив Amazon CloudFront с бакетом Amazon S3 в качестве источника: const cdk = require('@aws-cdk/core'); const cf = require('@aws-cdk/aws-cloudfront'); const origins = require('@aws-cdk/aws-cloudfront-origins'); const s3 = require('@aws-cdk/aws-s3'); class CfcliStack extends cdk.Stack { constructor(scope, id, props) { super(scope, id, props);
160 | Глава 6 const bucket = new s3.Bucket(this, "my-unique-bucket", { websiteIndexDocument: 'index.html' }); const distribution = new cf.Distribution(this, "my-CF-distro", { defaultBehavior:{ origin: new origins.S3Origin(bucket) } }) } } Таким образом мы описываем инфраструктуру, которую можно будет воспроизводить в разных аккаунтах AWS или средах разработки, не конфигурируя ее вручную. Когда мы определяем конвейеры автоматизации микрофронтендов, мы должны использовать IaC, чтобы разные команды создавали свои конвейеры из шаблона и тем самым соблюдали единые правила организации и не тратили время на конфигурацию однотипной инфраструктуры для каждого микрофронтенда. В рамках IaC мы автоматизируем настройку и подготовку инфраструктуры так же, как мы автоматизируем работу с любым другим кодом. Мы можем быть уверены, что не забудем или не испортим конфигурацию части инфраструктуры, ведь все необходимое описано в файлах конфигурации, т. е. в коде, с помощью которого мы можем генерировать одинаковые конвейеры репликации. Это важно, когда мы работаем в больших и особенно в распределенных командах, потому что таким образом мы можем легко выпускать модули и скрипты, которые затем могут использоваться другими командами. Частые итерации Конвейер автоматизации невозможно определить раз и навсегда, до самого окончания жизненного цикла проекта. Его необходимо регулярно пересматривать и совершенствовать. Он должен быть очень быстрым, чтобы разработчики как можно скорее получали обратную связь. Если визуализировать конвейер автоматизации, его будет проще совершенствовать. Над столами разработчиков должны висеть схемы, наглядно показывающие, сколько времени требуется для сборки программного пакета, чтобы все в команде сразу видели, насколько эффективные у них конвейеры и удалось ли выполнить ту или иную задачу. Если конвейеры занимают больше 8–10 минут, пора их пересмотреть и попытаться оптимизировать некоторые практики стратегии автоматизации. Анализируйте стратегию автоматизации регулярно: каждый месяц, если конвейеры слишком медленные, или каждые 3–4 месяца, если они выполняются эффективно. Всегда оценивайте конвейеры автоматизации через некоторое время после создания. Не жалейте времени и сил на улучшения, повышение производительности и ускорение цикла обратной связи — эти вложения очень быстро окупятся.
Создание и развертывание микрофронтендов | 161 Поддержка команд В некоторых компаниях, где я работал, стратегию автоматизации не доверяли самим программистам. Всего несколько человек в организации знали, как работает вся система автоматизация, и еще меньше было тех, кому разрешено было вносить изменения в инфраструктуру или запускать процесс создания или развертывания программного пакета. Это настоящий кошмар для разработчиков, которые работают в организации с одной или несколькими командами. Разработчик не должен ограничиваться написанием кода, он может также настраивать и менять конвейер автоматизации для программного пакета, над которым работает, будь то библиотека, микрофронтенд или все приложение. У команд, создающих микрофронтенды, должно быть достаточно свободы, потому что не всегда можно использовать один и тот же конвейер для всех микрофронтендов, ведь у нас может быть несколько стеков. Да, этап развертывания будет одинаковым для всех микрофронтендов в проекте, но в конвейере сборки могут использоваться разные инструменты или разные настройки, и если выбирать подходы и технологии централизованно, результат будет хуже. В идеале у разработчиков должна быть возможность определять свой конвейер автоматизации, но с соблюдением некоторых правил и ограничений. Например, инструмент CI/CD компания может выбрать централизованно, зато все скрипты и этапы по созданию программного пакета должны определяться командой, потому что никто лучше разработчиков не знает, как эффективнее всего создать пакет с написанным ими кодом. Это не значит, что команда должна отделиться от остальной организации, но руководство должно предоставить им свободу принимать некоторые решения, потому что это пойдет на пользу всему проекту. Наконец, поддерживайте культуру инноваций и обмена опытом, предоставляя условия, в которых разработчики могут делиться своими идеями, экспериментами и решениями. Это особенно важно при удаленной работе, когда члены команды не болтают друг с другом у кофемашины. Если вы организуете виртуальные собрания специально для общения, сначала это может показаться странным, но в результате поможет поднять командный дух и укрепить отношения между коллегами. Установка ограничений Если мы хотим дать команде свободу и при этом создать надежную стратегию автоматизации, нужно установить некоторые границы, определяющие общее направление. Техническое руководство совместно с архитекторами и инженерами, которые отвечают за платформу или облако, должно установить ограничения, в пределах которых команда может разрабатывать микрофронтенды. Сюда входят инструменты, с помощью которых мы реализуем стратегию автоматизации, панель управления для развертывания при непрерывной поставке или функции приспособленности для воплощения характеристик архитектуры.
162 | Глава 6 Мы не пытаемся загнать разработчиков в жесткие рамки. Скорее, мы обозначаем некоторые стандарты, которым они могут следовать, чтобы сосредоточиться на своей сфере и не тратить время на обдумывание абсолютно всех аспектов системы. При установке ограничений следует найти баланс и убедиться, что все понимают причины этих ограничений, не вдаваясь в технические детали. Распространять информацию среди команд и новых сотрудников удобно с помощью документации. Как и остальные части стратегии автоматизации, ограничения не должны быть статичными. Их следует постоянно пересматривать, улучшать или даже удалять по мере развития бизнеса. Разработка стратегии тестирования Очень важно уделить достаточно времени разработке стратегии тестирования, особенно сквозного тестирования, например, когда у нас несколько микрофронтендов в представлении, над конечным результатом работает несколько команд, а мы должны убедиться, что все части слаженно взаимодействуют. Мы должны также протестировать переход между представлениями, прежде чем развертывать программные пакеты в среде эксплуатации. Модульные и интеграционные тесты тоже важны, но в микрофронтенд-архитектуре они не вызывают особых проблем, в отличие от сквозного тестирования. Поскольку каждой команде принадлежит своя часть приложения, нужно тщательно протестировать критический путь и убедиться, что мы достигнем желаемого результата. Для этого и требуется сквозное тестирование. Простота и скорость разработки Простота и скорость разработки — важный аспект при работе с микрофронтендами. Не во всех компаниях есть отдельные команды, которые занимаются этой темой, но стоит собрать такую команду хотя бы виртуально. Она может создавать инструменты для повышения простоты и скорости разработки при работе с микрофронтендами, чтобы предотвращать проблемы при разработке новых возможностей. На этом этапе уже ясно, что каждая команда занимается своей частью приложения, а не всей кодовой базой. Повышение простоты и скорости разработки помогает разработчикам без лишних сложностей собирать, тестировать и отлаживать свой микрофронтенд. Микрофронтенд нужно тестировать изолированно, а также в контексте всего веб-приложения, потому что между микрофронтендами всегда есть точки соприкосновения, какую бы архитектуру мы ни выбрали. В идеале следует создать расширяемую систему, в которую можно будет добавлять новые инструменты на протяжении жизненного цикла проекта.
Г Л А В А 8 Бэкенд-архитектуры, совместимые с микрофронтендами Может показаться, что микрофронтенды сочетаются исключительно с микросервисами, потому что только так можно обеспечить полноценную автономию, а монолитная архитектура не будет поддерживать микрофронтенды или монолитный уровень API будет работать только с монолитным фронтендом. Это не так. Нужно учесть несколько нюансов, но в целом микрофронтенды можно использовать не только с микросервисами, но и с монолитным бэкендом. В этой главе мы рассмотрим несколько возможных комбинаций фронтенда и бэкенда. В частности, мы проанализируем, как микрофронтенды сочетаются с монолитом, с микросервисами и даже с паттерном Backend-for-Frontend (BFF), или "бэкенд для фронтенда". Мы также обсудим лучшие паттерны для разных реализаций микрофронтендов: вертикальное разделение, горизонтальное разделение с композицией на стороне клиента и горизонтальное разделение с композицией на стороне сервера. Наконец, мы увидим, как можно использовать GraphQL в контексте микрофронтендов как единую точку входа для API. Интеграция API и микрофронтенды Начнем с разных подходов к API в веб-приложении. Как видно на рис. 8.1, мы рассмотрим самые известные и популярные паттерны. Это не значит, что микрофронтенды сочетаются только с этими реализациями. Можно продумать подход с использованием WebSocket (двустороннего протокола коммуникации на основе TCP) или гипермедиа, на основе BFF, шлюза API или словаря сервисов. (Можно применить REST со ссылками гипермедиа в ответе, и тогда клиент, использующий API, сможет динамически переходить к нужным ресурсам, проходя по ссылкам гипермедиа.) Вот паттерны, которые мы рассмотрим в этой главе. Словарь (реестр) сервисов. Это просто список сервисов, доступных клиенту. Он используется в основном, когда мы разрабатываем уровень API с монолитной или модульной монолитной архитектурой, однако его можно реализовать и с микросервисами и шлюзом
200 | Глава 8 API. Словарь сервисов позволяет не создавать общие библиотеки, переменные среды или конфигурации, внедряемые в ходе непрерывной интеграции, а также обходиться без жесткого кодирования конечных точек в кодовой базе фронтенда. Словарь впервые загружается при загрузке микрофронтенда, позволяя клиенту извлекать URL, чтобы потреблять сервисы напрямую из словаря. Рис. 8.1. Микрофронтенды (МФ) и уровни API Шлюз API. Шлюз API широко используется с микросервисами и представляет собой единую точку входа для микросервисной архитектуры. Клиенты могут использовать API, разработанные внутри микросервисов, через шлюз. Шлюз API также позволяет централизовать выполнение некоторых задач, например следующие. Валидация токенов. Проверяет подпись токена до передачи запроса микросервису. Мониторинг и отчетность. У нас есть централизованный способ проверять входящий и исходящий трафик. Ограничение числа запросов. Шлюз API отклоняет запросы при достижении заданного порогового значения. Например, можно установить лимит в 100 запросов в секунду с клиента. Если лимит превышен, шлюз API возвращает ошибку и не вызывает микросервис. BFF. BFF — это расширение паттерна шлюза API, которое создает отдельную точку входа для клиентов одного типа. Например, у нас может быть один BFF
Бэкенд-архитектуры, совместимые с микрофронтендами | 201 для веб-приложения, еще один — для мобильного приложения и третий — для устройств Интернета вещей (Internet of things, IoT), которые мы продаем. BFF сокращает количество запросов и ответов между клиентом и сервером, объединяя ответы API и возвращая клиенту простую структуру данных, парсинг и рендеринг которой можно выполнить в пользовательском интерфейсе. Это дает больше свободы при создании API специально для клиента и сокращает обмен данными между клиентом и бэкендом. Эти паттерны не исключают друг друга — их вполне можно сочетать. Кроме того, можно написать библиотеку методов API и реализовать ее на стороне клиента, чтобы ею пользовались разные микрофронтенды. Я не советую так делать при использовании микрофронтендов, потому что кое-где мы могли прописать более старую версию библиотеки, а в пользовательском интерфейсе могут возникать разные проблемы, включая устаревшую информацию или даже ошибки из-за удаления некоторых API. Без эффективной системы управления и строгой дисциплины при использовании этой библиотеки есть риск, что некоторые микрофронтенды будут использовать неправильную версию API. Принципы предметно-ориентированного проектирования также влияют на решения по архитектуре и инфраструктуре. При использовании микросервисов и микрофронтендов мы делим приложение на несколько доменов, предметных областей бизнеса и подбираем подход для каждого домена. Например, часть приложения может предоставлять API через BBF, а другая часть — через словарь сервисов. Такая гибкость дает архитекторам и разработчикам невероятную широту выбора. При этом важно не переусердствовать с разнообразием подходов и инструментов, а внедрять новый паттерн, только если это действительно полезно для приложения. Работа со словарем сервисов Словарь сервисов — это просто список сервисов, доступных на уровне API, предоставляемый микрофронтенду. С его помощью можно использовать API, не подготавливая методы в коде клиента, чтобы затем внедрить их в конвейере непрерывной интеграции или в рамках общей библиотеки. Обычно словарь сервисов предоставляется через статический файл JSON или API, который мы должны получить при первом запросе к микрофронтенду (в архитектуре с вертикальным разделением) или через оболочку приложения (при горизонтальном разделении). Словарь сервисов можно интегрировать в имеющиеся файлы конфигурации или API, чтобы сократить обмен запросами и ответами с сервером и ускорить запуск клиента. В этом случае в объекте JSON может содержаться список конфигураций, необходимых клиенту, и одним из элементов будет словарь сервисов. Пример структуры словаря сервисов: { "my_amazing_api": { "v1": "https://api.acme.com/v1/my_amazing_api", "v2": "https://api.acme.com/v2/my_amazing_api",
202 | Глава 8 "v3": "https://api.acme.com/v3/my_amazing_api" }, "my_super_awesome_api": { "v1": "https://api.acme.com/v1/my_super_awesome_api" } } Как видите, мы указали все API, поддерживаемые бэкендом. Благодаря контролю версий API мы можем избежать критических изменений в кроссплатформенных приложениях, потому что каждый клиент сможет использовать подходящую для него версию API. Правда, а таких сценариях мы не можем контролировать наличие новой версии на каждом мобильном устройстве. При выпуске новой версии мобильного приложения требуются дни и даже недели, а иногда и дольше, чтобы обновление было установлено на всех устройствах. Поэтому так важно управлять версиями API, чтобы не испортить взаимодействие с пользователем. Важно также определить регулярность, с которой мы будем удалять старые версии API, в том числе для того, чтобы возможные атаки не нарушили стабильность нашей платформы. Обычно при переходе на новую версию API мы не только улучшаем бизнес-логику, но и усиливаем безопасность. Если изменение невозможно применить ко всем версиям определенного API, лучше подумать, нужны ли устаревшие версии пользователям, и если не нужны, их лучше удалить. Для того чтобы пользователи могли продолжить использование нашего продукта, можно принудительно установить обновление в каждом приложении, выпущенном в виде исполняемого файла (на мобильных устройствах, Smart TV и приставках), чтобы у пользователя не было доступа к более старым версиям приложения, которые уже не сочетаются с нашими API или даже бизнес-моделью. Мы должны продумать, как действовать в таких сценариях без ущерба для пользовательского опыта. Еще одна причина использовать словарь сервисов — обнаруживаемость конечных точек. Кросс-функциональные команды есть не во всех компаниях. Многие до сих пор делят команды по компонентам, причем за фронтенд и бэкенд отвечают разные команды. Словарь сервисов позволяет узнать, что происходит в других командах. Если в словаре сервисов появляется новый API или новая версия API, фронтендразработчики узнают об этом. Этот подход будет удобен и в кросс-функциональной команде. Маловероятно, что у команды "на две пиццы" будут все необходимые знания для разработки бэкенда, веб-приложения и мобильных приложений (для iOS и Android), а еще приложений для Smart TV и приставок, учитывая, что много устройств поддерживают HTML и JavaScript. ʀʤʢʖʣʚʖʣʖʚʘʛʥʞʬʬʱ Основатель Amazon Джефф Безос когда-то предложил "правило двух пицц": если мы не можем накормить команду двумя пиццами, в ней слишком много людей. В Amazon это правило означало, что команда должна состоять из восьмидевяти участников. Конечно, мы не пытаемся сэкономить на пицце. Дело в связях
Г Л А В А 1 0 Внедрение микрофронтендов в организации Вы дошли до последней главы книги и успели многое узнать о том, как выбрать подходящую архитектуру для своего контекста, создать микрофронтенды и добиться успеха при реализации проекта. Пора переходить к написанию кода? Не совсем. Осталось обсудить еще несколько тем, связанных с человеческим фактором в контексте внедрения новой или изменения имеющейся архитектуры. Когда мы вносим в архитектуру существенные изменения, нужно продумать, как организовать потоки коммуникации, как избежать разобщения между группами и как помочь разработчикам принимать верные решения в своем домене. Это лишь несколько важных аспектов, связанных с людьми, о которых мы должны думать в начале проекта и на протяжении всего жизненного цикла. Микрофронтенды помогают решить некоторые проблемы, но при неверном подходе создают другие, поэтому так важно тщательно проанализировать текущую структуру организации и ее совместимость с новой архитектурой. Зачем нам микрофронтенды? Технические руководители и директора часто задают этот вопрос, когда кто-то предлагает внедрить микрофронтенды в организации. Это разумный вопрос, и лучший способ ответить на него — оценить достоинства этой архитектурной парадигмы. Микрофронтенды дают несколько преимуществ, например независимость команд, безопасное развертывание, снижение когнитивной нагрузки на разработчиков, быстрые итерации и инновации. Но есть и недостатки, например риск внести разобщенность в организацию, необходимость инвестировать больше ресурсов в конвейеры автоматизации и возможное нарушение единообразия пользовательского интерфейса. Предлагая организации идею внедрения микрофронтендов, рассказывайте не только о технических, но и об организационных преимуществах. Вот несколько советов по подготовке убедительной презентации для заинтересованных лиц. Подчеркните, что микрофронтенды поддерживают более быструю итерацию и снижают риск внедрения ошибок во все приложение.
260 | Глава 10 Изучите и опишите контекст, в котором работает организация, и объясните, почему микрофронтенды помогут достичь целей бизнеса. Перечислите проблемы, которые вы пытаетесь решить с помощью этого подхода. Обдумайте лучший способ реализовать микрофронтенды в вашем контексте. Проанализируйте, как эта архитектура может повлиять на коммуникации в команде и между ними. Обозначьте идеальную схему управления архитектурой. Соберите метрики конвейера автоматизации, например время до развертывания и тестирования, и подумайте, как их можно улучшить. Это не полный список тем, которые волнуют техническое руководство или клиентов вашей организации. Предлагая техническое решение, не забывайте и об организационных проблемах. Продумайте все аспекты преобразований, которые принесут пользу компании и клиентам. Для того чтобы подобрать техническое решение для вашего контекста, начните с проверки концепции и оцените сложности и преимущества того или иного подхода. То, что подходит одной команде в организации, может не подойти другой. Предлагайте коллегам и руководству решение, которое лучше всего впишется в ваш контекст. Попробуйте сразу привлечь к этому нужных людей, потому что понять контекст бывает непросто, особенно если это организация среднего или крупного размера с распределенными командами и разными культурами в разных офисах. Эта глава посвящена созданию системы управления, ведению документации, подготовке организации и налаживанию потоков коммуникации в проекте по созданию микрофронтендов. Связь между организациями и программной архитектурой Как выбрать программную архитектуру? Самый простой способ — повторить опыт успешных компаний. Но идеальной архитектуры не бывает — бывают только варианты, подходящие или неподходящие в том или ином контексте. В любом случае придется идти на компромиссы — получить все и сразу, увы, не получится. Мы должны стремиться к тому, чтобы создать архитектуру, которая отвечает потребностям нашей организации и контексту, в котором мы работаем. Мы смотрим много презентаций конкретных вариантов реализации, и некоторые идеи и решения кажутся идеальными для нашей ситуации. К сожалению, все гораздо сложнее. В любом выступлении или книге решение описывается под одним углом, с точки зрения одного человека, который представляет только часть организации. Обычно в таких примерах мы подробно видим, как реализовано решение, но мало что знаем о контексте, в котором оно принесло хорошие результаты, и почти не представляем себе, почему решение сработало в данном контексте. А ведь именно контекст позволяет нам взвесить все плюсы и минусы и найти компромисс.
Внедрение микрофронтендов в организации | 261 Как выбрать программную архитектуру? Зависит от контекста. Универсального решения вы не найдете. Адаптируйте архитектуру под свои потребности, применяя паттерны, которые лучше всего решают ваши задачи и подходят к вашей ситуации. Помните, что бизнес не стоит на месте, и то, что сегодня кажется подходящим вариантом, завтра придется переделать. Модульный подход позволяет приспосабливаться к новым направлениям бизнеса, ускоряя и упрощая достижение поставленных целей. В то же время добиться модульности не так просто. Для этого требуется дисциплина, анализ и много усилий всех участников проекта. Микрофронтенды, как и любая другая архитектура, подходят не для всех проектов. Это хороший вариант для средних и крупных приложений, в которых над одним только фронтендом работают три-четыре команды. Они также могут быть очень полезны в ситуациях, когда масштабирование является одним из требований бизнеса, когда успех приложения зависит от скорости выхода на рынок, когда нужно переделать устаревшее приложение, чтобы пользователи сразу заметили преимущества, а не ждали окончания разработки, и для многих других сценариев. Ваша реализация микрофронтендов может отличаться от подходов, описанных в этой книге. Не стесняйтесь придумывать свои подходы, специально для своего контекста. Это нормально, если для этого есть веские причины и так будет лучше для вашей команды, целой организации или процесса. Как комитеты изобретают новое? В первой главе я уже упоминал о законе Конвея: "При проектировании систем (причем не только информационных) организации неизбежно создают проекты, копирующие их собственные коммуникационные структуры". Этот закон сформулирован в докладе Мелвина Конвея (Melvin Conway) от 1968 г. "Как комитеты изобретают новое?" ("How Do Committees Invent?"1 ). В нем Конвей объясняет, что программная архитектура обычно проектируется по принципам структуры компании. Но так делать необязательно. Иногда можно продумать архитектуру, которая лучше всего подходит для разработки нашей платформы, а затем изменить структуру команд, чтобы приспособиться к этой архитектуре. Это так называемый обратный маневр Конвея. В разделе об этапах проектирования программной архитектуры (Stages of Design) Конвей дает несколько рекомендаций: определите границы проектной деятельности и проектируемой системы, установленные заказчиком и объективными реалиями; предварительно оцените структуру системы, чтобы продуманно сформировать группы, которые будут заниматься проектированием. За полвека эти советы ничуть не утратили своей актуальности. В книге "Ускоряйся" ("Accelerate") Николь Форсгрен (Nicole Forsgren), Джез Хамбл (Jez Humble) и Джин 1 См. https://oreil.ly/v5WM0.
262 | Глава 10 Ким (Gene Kim) делятся своими наблюдениями за успешными организациями в разных отраслях. Все рассмотренные организации используют обратный маневр Конвея при развитии своих социотехнических систем. Архитектура и коммуникации тесно связаны. Это нужно очень хорошо понимать, потому что такая связь во многом повлияет на выбор варианта микрофронтендархитектуры. В идеале следует спроектировать подходящую архитектуру для определенного контекста, а затем назначить команды для реализации проекта, но это не всегда возможно. По моему опыту, такое случается крайне редко, но все же случается. Если мы должны придерживаться существующей в организации структуры, при проектировании нужно учитывать текущие потоки коммуникации между командами, их ежедневные взаимодействия и организационную структуру, чтобы архитектура вписалась в организацию. Понимая связь между потоками коммуникации и архитектурой, мы сможем подобрать лучший паттерн для своего контекста. Для команд, работающих в офисе и удаленно, потоки коммуникации будут различаться. Сэм Ньюман (Sam Newman) очень точно высказался о законе Конвея в своей статье2 : "Пути коммуникации, о которых говорит Конвей, тесно связаны с самим кодом, потому что единая кодовая база требует тесного взаимодействия, которое невозможно в распределенной команде. Если это противоречие возникает, ищите возможности разделить монолитную систему по границам организации" (курсив автора). Тип коммуникации — тесная или поверхностная — во многом влияет на нашу архитектуру. В распределенной компании можно достичь тесной коммуникации, если все работают удаленно и между командами нет различий. Если в организации появляется несколько центров разработки в разных местах, поток коммуникации меняется, и когда несколько команд работают над одной областью кодовой базы, но в разных офисах, минусов может быть больше, чем плюсов. Для решения этой проблемы можно назначить все пересекающиеся и схожие поддомены команде, работающей в одном офисе, а не распределенной по разным местам. Представьте платформу видеостриминга, состоящую из нескольких областей: главная страница; каталог фильмов; воспроизведение; поиск; персонализация; вход; регистрация; оплата; восстановление электронной почты; 2 См. https://oreil.ly/Uoa6j.
П Р И Л О Ж Е Н И Е Что сами разработчики и архитекторы думают о микрофронтендах В этой книге мы познакомились с микрофронтендами, узнали, как создавать микрофронтенд-архитектуру, и рассмотрели социотехнические аспекты этой архитектурной парадигмы. Как мы увидели в главе 1, многие компании по-разному реализуют микрофронтенды в среде эксплуатации. Я поговорил с несколькими специалистами, внедрившими микрофронтенды в своей организации. В этом приложении технические руководители, архитекторы и разработчики расскажут о своем опыте с реализацией микрофронтендов. Нимиша Астагири, главный архитектор в edX Расскажите о себе Нимиша Астагири (Nimisha Asthagiri) работает в edX с 2014 г. Как главный архитектор, она активно поддерживает стратегические инициативы по реализации тщательно продуманной архитектуры для глобальной платформы онлайн-образования нового поколения. Она несколько лет занималась проблемами распределенных вычислений и масштабирования. Сейчас работает над оптимизацией монолитной архитектуры, перепроектированием платформы на современный лад и внедрением принципов и практик разумного проектирования среди разработчиков edX. Нимиша верит, что образование вдохновляет людей и ведет их к лучшей жизни. edX — это глобальная некоммерческая платформа с открытым кодом для образования и обучения. Расскажите о своем опыте с микрофронтендами Два года назад мы начали переделывать архитектуру, чтобы отделить фронтенд от бэкенда. Мы взялись за это, потому что фронтенд-разработка отнимала слишком много сил и времени.
280 | Приложение Мы используем веб-фреймворк Django. Представления на фронтенде реализуются как шаблоны Django и поставляются с бэкенда в среде разработки на Python. Представьте, как монолитный бэкенд затруднял работу фронтенд-разработчиков, которые пишут и обслуживают код JavaScript. В монолите 1,5 млн строк кода, а во всей платформе — 4,5 млн. Для решения этой проблемы мы собрали команду из трех человек, которая впоследствии разрослась до шестерых. Ее задачей было создать фундамент и сформулировать базовые архитектурные принципы для микрофронтендов на нашей платформе. Вдохновившись заметкой о микрофронтендах в Tech Radar1 и другими статьями2 , я предложила модель возможностей3 , ориентируясь на которую мы могли бы перейти с монолита на распределенную архитектуру на основе принципов предметно-ориентированного проектирования. Какие преимущества и недостатки микрофронтендов вы можете отметить? Мы заметили значительное повышение продуктивности разработчиков. Простота и скорость разработки существенно увеличились, тем более что фронтендразработчики продолжали использовать привычные технологии, вроде npm и webpack. Время до развертывания фронтенда сократилось до 10 минут — с монолитом на это уходили часы. Код фронтенда удалось уменьшить до удобоваримого объема и отделить от сложного бэкенда. Один из главных недостатков связан не столько с микрофронтендами как с подходом, сколько с затратным переносом на другую платформу созданных за восемь лет функций, у которых не было определенных API (пользовательский интерфейс рендерился на стороне сервера), при этом мы хотели достичь равенства функций. Мы решили сохранить равенство функций со старой реализацией, чтобы не пришлось менять сразу и технологию, и функции, ведь это могло бы негативно отразиться на результатах бизнеса. После переписывания нескольких важных страниц мы распустили команду реплатформинга, так что этот процесс еще не завершен. Пока мы не достигли цели: часть фронтенда мы перевели на микрофронтенды, а часть пока работает на Django. В будущем команды по функциям перепишут оставшееся, используя паттерн "душитель" и не обязательно соблюдая равенство функций. Еще одна проблема — поддержка небольших операторов в нашем сообществе разработчиков. У них недостаточно опыта в управлении облачной инфраструктурой, так что после внедрения новых конвейеров развертывания вместо одноэтапного развертывания монолита возникли новые проблемы. 1 См. https://oreil.ly/lC4eO. 2 См. https://oreil.ly/vFzEV. 3 См. https://oreil.ly/vFzEV.
Что сами разработчики и архитекторы думают о микрофронтендах | 281 Вы участвуете в проектах с открытым исходным кодом, связанных с микрофронтендами? Если да, то в каких? Мы открыли исходный код наших библиотек микрофронтендов. Некоторые из них могут пригодиться. Frontend-platform4 — фреймворк для микрофронтенд-приложений с API для журналирования, аналитики, аутентификации и локализации. Frontend-build5 — это библиотека для линтинга (eslint), тестирования (jest), сборки (webpack) и создания сервера разработки (webpack-dev-server). Не связано напрямую с микрофронтендами, но это ресурс ОС для разработки на React: Paragon6 — библиотека шаблонов для поддержки специальных возможностей (a11y) в компонентах React и платформа SCSS на Twitter Bootstrap. В каких ситуациях следует использовать микрофронтенды, а в каких — избегать? Микрофронтенды хорошо подходят для ситуаций, когда мы хотим распределить фронтенд-разработку большой кодовой базы по нескольким командам. У каждого микрофронтенда свои границы, которые поддерживают естественную независимость и позволяют контролировать когнитивную нагрузку. Микрофронтенды слишком сложны для прототипов и небольших реализаций — на этом этапе будет легче управлять простым веб-фреймворком с менее объемной инфраструктурой. Если говорить о вашем последнем проекте по разработке микрофронтендов, что получилось, а что — не очень? Разработчики по всей организации с готовностью приняли новый фреймворк и методологию микрофронтендов. Мы заметили, что фронтенд-разработка серьезно ускорилась, а разработчики довольны происходящим, и это важное преимущество с точки зрения бизнеса и технической стороны. Из минусов — у нас не было готовых API, с помощью которых микрофронтенды могли бы связываться с бэкендом, и это серьезно замедлило разработку. Мы подумываем инвестировать в GraphQL, чтобы частично решить проблему. Этот инстру- 4 См. https://oreil.ly/ujlM6. 5 См. https://oreil.ly/3CX8q. 6 См. https://oreil.ly/6uyip.
282 | Приложение мент позволит разработчикам микрофронтендов легко запрашивать нужные данные, не дожидаясь обновления или создания RESTful API. Без каких инструментов невозможно обойтись при разработке микрофронтендов? Инфраструктура развертывания, которая масштабируется вместе с ростом числа микрофронтендов и различает версии кода микрофронтендов. Локальная среда разработки, в которой удобно работать. Стратегия тестирования с инструментами для модульного тестирования и тестирования контрактов API (для обнаружения ошибок контрактов на бэкенде). Что вы порекомендовали бы человеку, который хочет внедрить эту архитектуру? Для того чтобы оценить уровень зрелости и готовности к реализации микрофронтендов, придерживайтесь тех же рекомендаций, что и для микросервисов. Даже при разработке микрофронтендов нужно будет инвестировать в общую инфраструктуру и общий фреймворк. Как справились с микрофронтендами разработчики, которые раньше с ними не работали? С какими трудностями вы столкнулись? В целом у нас не было особых проблем с переходом и внедрением микрофронтендов в организации, потому что еще на начальных этапах мы заручились поддержкой руководителей. Они знали, какой сложной была фронтенд-разработка до миграции. Для того чтобы помочь разработчикам, мы проводили обучающие семинары и неформальные совещания для обмена мыслями и опасениями, а теперь у нас есть регулярная учебная группа по фронтенду, с помощью которой команды делятся опытом и рекомендациями. Как бы вы оценили простоту и скорость разработки в последнем проекте? Мы инвестировали в разработку библиотек frontend-platform и frontend-build [описано выше], которые значительно упрощают создание новых микрофронтендов. К сожалению, пока при создании нового микрофронтенда приходится вручную интегрировать его в инфраструктуру: GoCD, Terraform, Travis, Analytics, APM, i18n.
Что сами разработчики и архитекторы думают о микрофронтендах | 315 Как бы вы оценили простоту и скорость разработки в последнем проекте? В проекте Luigi мы создали инструмент Luigi Fiddle24 — площадку для экспериментов, где можно опробовать большую часть основного функционала. Очень полезный инструмент, особенно для обучения новых разработчиков. Многие разработчики переживают, что после перехода на микрофронтенды будет сложнее поддерживать высокую производительность и единообразие дизайна. Что вы посоветуете для решения этих проблем? Эти аспекты, особенно производительность, во многом зависят от выбранного подхода. Например, в Luigi есть разные механизмы (группы представлений, кэширование, предварительная загрузка), чтобы отчасти решить проблемы с производительностью, возникающие на стороне конечного пользователя. Что касается единообразия дизайна, я даже удивился, когда узнал, что для кого-то это проблема. Обычно я спрашиваю, как разработчики добиваются единообразия в приложении без микрофронтендов, и они отвечают, что это не проблема, потому что у них есть единые стили CSS. В итоге они почти всегда понимают, что можно использовать один набор CSS для разных приложений. С тем же успехом можно создавать компоненты Angular, которые отличаются от остального приложения. Так что разработчикам в любом случае нужно следить за согласованностью, чтобы их часть пользовательского интерфейса хорошо смотрелась. С чего начать работу с микрофронтендами? Подумайте, как можно разделить пользовательский интерфейс, а потом используйте структуру принятия решений, которую предложил Лука Меццалира (Luca Mezzalira). Узнайте, существует ли фреймворк, который уже соответствует вашим требованиям. Чего нужно избегать при работе с микрофронтендами? Приведите один пример Убедитесь, что в стеке не будет монолитного уровня, иначе вы потеряете большую часть преимуществ микрофронтендов. Лучше всего микрофронтенды сочетаются с микросервисами. 24 См. https://fiddle.luigi-project.io/.
316 | Приложение В чем, по-вашему, главные сложности внедрения этой архитектуры? Главная сложность — неподходящая структура организации. Руководство должно так изменить структуру, чтобы отдельная единица (команда разработчиков в самом простом случае) могла независимо поставлять всю функцию. Поделитесь полезными ресурсами о микрофронтендах Все публикации Луки Меццалира. На сайте Мартина Фаулера25 можно найти хорошее объяснение микрофронтендов. И, конечно, изучите сайт проекта Luigi26 и наш канал YouTube, посвященный Luigi и общим темам, связанным с микрофронтендами. Микрофронтенды в трех словах... Разделяй и властвуй. 25 См. https://martinfowler.com/. 26 См. https://luigi-project.io/.