Они принципиально различаются, когда речь идет о совместном использовании кода. Узнайте, почему
За прошедшие годы микросервисы оказали значительное влияние на интерфейсные архитектуры. Разработчики выбирают микросервисы, поскольку они позволяют им распространять разработку и часто выпускать изменения.
Под влиянием микросервисов разработчики переняли такие концепции, как совместное использование кода, для Microfronted. Однако мы не можем полностью сопоставить эти концепции между микросервисами и микрофоронтендами, поскольку они принципиально разные. Например, микросервисы — это распределенные системы, а микрофронтенды во время выполнения работают в браузере пользователей. Следовательно, это существенно влияет на то, как мы повторно используем код.
Итак, в этой статье мы обсудим, как мы должны использовать совместное использование кода, и ключевые различия в совместном использовании кода между Microfronted и Microservices.
Совместное использование кода в микросервисах
Совместное использование кода в микросервисах может быть сомнительной темой для многих, поскольку основная концепция микросервисов заключается в создании автономных сервисов. Однако, поскольку они являются распределенными системами, мы должны рассматривать их независимо и сводить к минимуму совместное использование кода. В противном случае могут возникнуть проблемы с зависимостями, и в конечном итоге ваш проект может стать монолитом.
Тем не менее, могут быть неизбежные ситуации, когда нам нужно использовать совместное использование кода между микросервисами. В таких случаях важно придерживаться лучших практик, чтобы не попасть в ловушку зависимости.
Совместное использование как библиотеки
При таком подходе вы можете извлечь общий код из микросервисов и опубликовать его в виде библиотеки в репозитории пакетов, таком как NPM или Nuget. Затем каждая команда может установить эту библиотеку или пакет в свои службы и использовать их без вмешательства со стороны других команд.
Хотя это звучит просто, есть несколько вещей, которые вы должны рассмотреть, прежде чем использовать этот подход.
Все микросервисы, которые хотят использовать библиотеку, должны использовать тот же язык, что и библиотека. Затем вам нужно назначить отдельную команду, которая станет владельцем библиотеки, поскольку могут возникнуть конфликты, если несколько команд начнут вносить изменения.
Выбор общего кода — самое важное в создании библиотек. Вы должны выбрать минимальный код, необходимый для функциональности, и он не должен требовать регулярных изменений.
Совместное использование как микросервисы
Если у вас есть большой код, который быстро меняется, совместное использование его с помощью библиотеки или компонента будет неэффективным. В этом случае лучший способ поделиться им — создать новый микросервис и предоставить код через API.
В отличие от двух других подходов, этот подход не имеет языковых ограничений, поскольку мы предоставляем API. Однако создание и рисование отдельного микросервиса увеличит нагрузку на разработчиков.
Микросервисы, написанные на любом языке, могут получить доступ к коду. Однако, если вы используете этот подход, рекомендуется следовать шаблонам проектирования, таким как Saga или Sidecar, чтобы обеспечить постоянство данных в сложных транзакциях. Кроме того, нужно выделить отдельную команду для обслуживания нового Микросервиса.
Хотя я упомянул вышеупомянутые методы как методы совместного использования кода в микросервисах, я настоятельно рекомендую вам максимально избегать совместного использования кода между микросервисами. По своей природе микросервисы — это распределенные системы, и совместное использование кода между ними может затмить преимущества использования микросервисов.
Совместное использование кода в микрофронтендах
По сравнению с микросервисами совместное использование кода можно легко адаптировать к микрофронтендам. Когда приложение выполняется, все внешние компоненты запускаются как одно приложение в браузере пользователя. Независимо от того, как вы разрабатываете, все микрофронтенды объединяются во время выполнения. Таким образом, совместное использование кода в процессе разработки не нарушает основ микрофронтенда.
Кроме того, пользователи напрямую взаимодействуют с внешними компонентами, и вам необходимо убедиться, что каждый компонент имеет одинаковый дизайн и интерфейс. Таким образом, наиболее эффективным способом является совместное использование кода между микрофронтендами, а не повторение одного и того же кода в каждом компоненте.
Я думаю, теперь вы знаете, почему совместное использование кода больше подходит для Microfronted. Итак, давайте обсудим различные методы, которые мы можем использовать для совместного использования кода между Microforntends.
Совместное использование как библиотеки
Как и в случае с микросервисами, вы можете извлечь код, которым необходимо поделиться, и опубликовать его в виде библиотеки. Например, если у вас есть служебный код для форматирования даты, вы можете опубликовать его как библиотеку и использовать во всех компонентах.
Я не буду вдаваться в подробности об этом подходе, так как я обсудил все проблемы этого подхода в разделе «Микросервисы». Однако этот подход не подходит, если ваш код нуждается в регулярных обновлениях.
Монорепозитории и полирепозитории
Как монорепозитории, так и полирепозитории широко используются для управления базами кода Microfrontend. Когда дело доходит до совместного использования кода, мы можем извлечь выгоду из обеих их характеристик.
Монорепо
В монорепозитории все Microforntends управляются в одном репозитории. У каждого компонента будет отдельная папка в репозитории, и все команды будут иметь доступ к репозиторию. Точно так же вы можете создать общую папку и поместить в нее весь общий код.
Если вы используете этот подход, вам необходимо убедиться, что код, включенный в общую папку, не будет часто меняться. Кроме того, управление доступом к общему коду может быть затруднено, поскольку каждый раз имеет доступ к репозиторию.
Полирепы
В полирепозиториях каждый проект или компонент имеет отдельный репозиторий. Он позволяет вам управлять доступом пользователей к компонентам и управлять отдельными кодовыми базами. Однако совместное использование кода в полирепозиториях может быть немного сложнее, чем в монорепозиториях.
В полипорах вы можете использовать Git Subtrees или Git Submodules для совместного использования кода. Эти два метода позволяют сохранить копию или ссылку из другого репозитория. Таким образом, вы можете использовать отдельный репозиторий для поддержки общего кода и загрузки его в свой репозиторий с помощью этих двух методов.
Однако выборка из подмодулей и поддеревьев может быть затруднена, если у вас много общих компонентов. Например, вам придется постоянно вносить и отправлять изменения из общих репозиториев и в них, а также будет возникать множество конфликтов, которые необходимо обработать.
Совместное использование в качестве компонентов
Совместное использование кода как компонентов — одна из последних технологий, представленных для совместного использования кода. Вы можете использовать такую платформу, как Bit, чтобы легко реализовать этот подход, и он решит большинство проблем, обсуждавшихся в предыдущих подходах.
Например, совместное использование кода через библиотеки может быть затруднено из-за проблем с жизненным циклом или постоянных изменений кода. Если вы используете совместное использование кода на основе компонентов, вы по-прежнему будете чувствовать себя как библиотека, но вам не нужно беспокоиться о проблемах жизненного цикла или постоянных обновлениях.
Кроме того, компонентный подход к совместному использованию кода объединяет лучшие возможности монорепозиториев и полирепозиториев в одном месте. Он отслеживает все компоненты по отдельности, позволяя разработчикам легко вносить изменения и делиться ими между командами. Кроме того, нет ограничений на максимальное количество компонентов, которыми вы можете поделиться.
Однако этот подход может быть новым для многих разработчиков. Итак, я призываю вас поэкспериментировать с Bit и применить этот подход для создания ваших микрофронтендов, поскольку он решает некоторые важные проблемы в совместном использовании кода Microfntend.
Ключевые выводы
В этой статье обсуждались различные методы совместного использования кода для микроинтерфейсов и микросервисов. Кроме того, я подчеркнул, почему разработчики должны избегать совместного использования кода в микросервисах и почему разработчики должны использовать совместное использование кода в микрофронтендах.
В двух словах, микросервисы — это распределенные системы, предназначенные для независимой работы. Если мы разделим слишком много между микросервисами, это разрушит фундаментальную основу микросервисов. Кроме того, совместное использование кода может увеличить количество зависимостей между сервисами и затруднить работу разработчиков. Таким образом, мы должны максимально избегать совместного использования кода в микросервисах.
Когда дело доходит до совместного использования кода, микрофронтенды действуют совершенно иначе, чем микросервисы. Хотя мы разрабатываем Microfontend по отдельности, все они объединяются в браузере во время выполнения. Таким образом, мы не нарушаем никаких основ микрофронтенда, делясь кодом. Кроме того, необходимо иметь одинаковый стиль и пользовательский интерфейс во всех компонентах интерфейса. Таким образом, лучший способ добиться идентичного внешнего вида в большом проекте — поощрять совместное использование кода.
В заключение, есть много причин, по которым мы должны и не должны использовать совместное использование кода в микросервисах и микрофронтендах. Я надеюсь, что эта статья поможет вам развеять сомнения и понять правильные методы совместного использования кода в микросервисах и микрофронтендах. Спасибо за чтение.
Станьте компонуемым: создавайте приложения быстрее, как Lego
Bit – это инструмент с открытым исходным кодом для модульного и совместного создания приложений. Перейдите на компоновку, чтобы поставлять быстрее, более последовательно и легко масштабировать.
Создавайте приложения, страницы, пользовательский опыт и пользовательские интерфейсы как автономные компоненты. Используйте их, чтобы быстрее создавать новые приложения и возможности. Используйте любой фреймворк и инструмент в своем рабочем процессе. Делитесь, повторно используйте и сотрудничайте, чтобы строить вместе.
Помогите своей команде:
→ Совместное использование кода и повторное использование
→ Монорепо
