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

Обзор серии

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

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

Идет микросерия

  1. [Вы здесь] Часть 1 — Введение в микроинтерфейсы
  2. Часть 2. Наш первый микроинтерфейс: консоль Yalo
  3. Часть 3. Дальнейшие действия. Что дальше с микроинтерфейсами Yalo?

Что такое микрофронтенды?

Наиболее распространенное определение микрофронтенда:

«Архитектурный стиль, в котором независимые интерфейсные приложения составляют единое целое»

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

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

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

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

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

Почему микрофронтенды?

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

  • дублирование зависимостей
  • раздувание кода
  • может быть фрагментация в том, как работают ваши команды

Однако наша организация может управлять этими рисками, и выгоды должны перевешивать затраты на микроинтерфейсы.

Мне нравится, как Кэм Джексон представляет микрофронтенды:

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

Итак, давайте углубимся в основные идеи, лежащие в основе микрофронтендов:

Простые, несвязанные кодовые базы

Каждый микроинтерфейс должен фокусироваться на определенной области всего приложения. Каждый микрофронтенд должен жить без связи с другими микрофронтендами.

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

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

Независимое развертывание

Независимо от того, как и где размещен код внешнего интерфейса, у каждого микроинтерфейса должен быть свой конвейер непрерывной доставки. Этот конвейер доставки должен создаваться, тестироваться и развертываться от разработки до производства.

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

Автономные команды

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

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

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

Технология агностик

Каждая автономная команда должна выбирать и обновлять свой технологический стек, не координируя свои действия с другими командами. В зависимости от конкретной части приложения некоторые технологии могут подойти лучше.

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

Как мы внедряем микрофронтенды?

Изучив различные способы реализации микроинтерфейсов, мы решили использовать Single SPA. Они определяют себя как:

Маршрутизатор javascript для интерфейсных микросервисов

И дают следующие обещания:

  • Свобода фреймворка. Используйте несколько фреймворков в одностраничном приложении, что позволяет разделить код по функциональности и иметь приложения Angular, React, Vue.js и т. д., живущие в гармонии. Несмотря на то, что на данный момент мы используем только React, хорошо иметь готовую гибкость.
  • Отложенная загрузка приложений. Single SPA не будет загружать приложения, пока они не потребуются пользователю. Как я упоминал ранее, размер загружаемого браузером кода — один из самых существенных недостатков микрофронтендов. Однако Single SPA по умолчанию предоставляет стратегию для решения этой проблемы.
  • Внешние микросервисы. Мы можем комбинировать небольшие приложения, позволяя другим командам выбирать любую технологию и оставаться гибкими по мере роста нашей организации.

Использование единого SPA в Yalo

У нас будет приложение root config. Это приложение отвечает за рендеринг страницы HTML и JS, который регистрирует остальные приложения. Для регистрации каждого приложения необходимо три вещи:

  • Имя.
  • Функция для загрузки кода приложения.
  • Функция, которая определяет, когда это приложение активно или нет.

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

Спасибо, что прочитали эту статью. Пожалуйста, следите за обновлениями в следующих частях.

Рекомендации

Я настоятельно рекомендую вам ознакомиться со следующими ссылками. Без них этой статьи не было бы.

Вам нравится то, что вы видите.

Хлопайте, оставляйте комментарии, делитесь или оставляйте комментарии. Я ценю ваши отзывы. Также ознакомьтесь с другими статьями в нашем блоге. Не забудьте проверить нашу карьерную страницу и наши вакансии!