В последнее время микросервисная архитектура серьезно влияет на фронтенд. Разработчики отдают предпочтение микросервисам, поскольку они позволяют распределять разработку проекта и чаще выпускать изменения.
Под влиянием микросервисов в разработке микрофронтендов появились такие концепции, как совместное использование кода. Однако полностью сопоставлять эти концепции между микросервисами и микрофронтендами нельзя, поскольку они принципиально отличаются. В частности, микросервисы — это распределенные системы, а микрофронтенды выполняются в браузере пользователей.
Обсудим совместное использование кода и ключевые различия, имеющиеся при этом между микрофронтендами и микросервисами.
Микросервисы
Может показаться, что совместное использование кода — не самый подходящий подход для микросервисов, так как в основе их концепции лежит автономное функционирование. При этом, поскольку они являются распределенными системами, мы должны рассматривать их независимо и сводить к минимуму совместное использование кода. В противном случае могут возникать проблемы с зависимостями, и в конечном итоге проект может превратиться в монолит.
Тем не менее возможны ситуации, когда совместное использование кода в микросервисах необходимо. В таких случаях нужно действовать по наиболее подходящим методикам, чтобы не попасть в ловушку зависимости.
В виде библиотеки
При таком подходе можно извлечь общий код из микросервисов и опубликовать его в виде библиотеки в репозитории пакетов, например NPM и Nuget. Затем каждая команда разработчиков может установить эту библиотеку или пакет в свои сервисы, чтобы использовать без внешнего вмешательства.
Кажется, что все просто. Однако прежде чем использовать этот подход, нужно учесть ряд особенностей.
Во всех микросервисах и используемой ими библиотеке должен применяться один и тот же язык. Поскольку могут возникнуть конфликты, если несколько команд начнут вносить изменения, также нужно назначить одну из них владельцем библиотеки.
Выбор общего кода — самый важный шаг при создании библиотек. Нужно выбирать необходимый для функциональности минимальный объем кода, который не должен требовать регулярных изменений.
В виде микросервиса
Совместно использовать большой объем часто изменяемого кода с помощью библиотеки или компонента неэффективно. В этом случае лучший способ поделиться кодом — создать новый микросервис и предоставлять код через API.
В отличие от двух других подходов, здесь нет языковых ограничений, поскольку мы предоставляем API. Впрочем, разработка и создание отдельного микросервиса — дополнительная нагрузка на разработчиков.
Микросервисы, написанные на любом языке, могут получить доступ к коду. Так или иначе, при подобном подходе рекомендуется следовать таким паттернам проектирования, как Saga и Sidecar, чтобы обеспечить сохраняемость данных в сложных транзакциях. Кроме того, для обслуживания нового микросервиса придется выделить отдельную команду.
Несмотря на то что вышеупомянутые методы и относятся к способам совместного использования кода в микросервисах, я настоятельно рекомендую избегать такой подход. По своей природе микросервисы — это распределенные системы, а совместное использование кода между ними может затмить их преимущества.
Микрофронтенды
Совместное использование кода легче адаптировать к микрофронтендам, чем к микросервисам. Все компоненты интерфейса запускаются и выполняются как единое приложение в браузере пользователя. Независимо от особенностей разработки все микрофронтенды объединяются во время выполнения. Таким образом, совместное использование кода в процессе разработки не нарушает основ микрофронтендов.
Кроме того, пользователи напрямую взаимодействуют с фронтенд-компонентами, и все они должны иметь одинаковый дизайн и интерфейс. Поэтому совместное использование кода в микрофронтендах — более эффективный способ, чем повторение одного и того же кода в каждом компоненте.
Рассмотрим различные подходы к обмену кодом между микрофронтендами.
В виде библиотеки
Как и в случае с микросервисами, можно извлечь код для совместного использования и поместить его в библиотеку. Например, служебный код для форматирования даты можно опубликовать виде библиотеки и использовать во всех компонентах.
Однако для регулярно обновляемого кода такой метод не подходит.
Монорепозитории и полирепозитории
Как моно-, так и полирепозитории часто используют для управления базами кода микрофронтендов. Оба типа репозитариев будут полезны для совместно используемого кода.
- Монорепозитории
В этом случае все микрообъекты содержатся в одном репозитории. У каждого компонента будет отдельная папка, а все разработчики будут иметь доступ к репозиторию. Аналогичным образом, можно создать общую папку и поместить в нее весь общедоступный код.
Используя этот подход, необходимо убедиться, что включенный в общую папку код не будет часто меняться. Кроме того, доступ к общему коду может быть затруднен из-за необходимости постоянного обращения к репозиторию.
- Полирепозитории
В этом случае каждый проект или компонент имеет отдельный репозиторий. Это позволяет управлять отдельными кодовыми базами и доступом пользователей к компонентам. Однако в этом случае использовать код совместно может быть сложнее, чем в монорепозитории.
Для обмена кодом в полирепозитории можно использовать подмодули и поддеревья Git. Эти методы позволяют сохранить копию или ссылку из другого репозитория. Таким образом, вы можете использовать отдельный репозиторий для поддержки общего кода и выборки его в свой репозиторий с помощью этих двух методов.
Однако в случае множества общих компонентов выборка из подмодулей и поддеревьев может быть затруднена. Например, изменения придется постоянно вносить в общие репозитории и переносить из них, а также придется обрабатывать множество возникающих конфликтов.
В виде компонентов
Это одна из последних методик совместного использования кода. Для простой реализации этого подхода можно использовать платформу, подобную Bit. Таким образом решается большинство обозначенных выше проблем.
Например, использовать код совместно через библиотеки может быть сложно из-за проблем с жизненным циклом и частых изменений. Совместное использование кода на основе компонентов напоминает библиотечный подход, но при этом не нужно беспокоиться о проблемах жизненного цикла и частых обновлениях.
Кроме того, основанный на компонентах обмен кодом объединяет все лучшее из моно- и полирепозиториев. Все компоненты отслеживаются по отдельности, упрощая внесение изменений и совместное использование кода между командами. Кроме того, нет ограничений на максимальное количество совместно используемых компонентов.
Выводы
Мы рассмотрели методы совместного использования кода для микрофронтендов и микросервисов. Также мы разобрались, почему следует избегать этого подхода в микросервисах и рекомендуется применять его в микрофронтендах.
Микросервисы — это распределенные системы для независимого функционирования. Активный обмен кодом подрывает фундаментальные основы микросервисов. Кроме того, совместно используемый код может способствовать увеличению зависимостей между сервисами и осложнит задачи разработчиков. Поэтому следует по возможности избегать такого подхода в микросервисах.
С микрофронтендами ситуация обстоит иначе. Они разрабатываются индивидуально, но объединяются в браузере во время выполнения. Таким образом, делясь кодом, мы не нарушаем основы микрофронтендов. Однако при этом необходим единый стиль и пользовательский интерфейс во всех компонентах микрофронтэнда. Поэтому совместное использование кода — лучший способ обеспечить идентичный внешний вид в большом проекте.
Читайте также:
- Как разбить монолитное приложение на микросервисы без рефакторинга
- Советы по созданию хорошего дизайна API
- Прототипирование с веб-компонентами: создание RSS Reader
Читайте нас в Telegram, VK и Дзен
Перевод статьи Chameera Dulanga: Differences in Code Sharing Between Microservices & Microfrontends
