Рабочие пространства и микросервисы NPM

Как сделать MonoRepos с микросервисами в NPM?

Репозиторий -›https://github.com/RaulGF92/NpmWorkspaceMicroServices

Введение

В эти недели в моей работе мы говорим о MonoRepos и о том, как это может быть решением наших проблем.

Мы работаем с огромным облаком MicroService, и иногда любое изменение оказывает большое влияние на наш процесс разработки UpVersion -> PullRequest -> CI/CD, который может иметь минимальные изменения. большое усилие (и это выглядит так, что со временем может исчезнуть)

MonoRepo может быть решением этой проблемы, потому что:

Все разработчики могут знать все микро
Мы разделяем конфигурации проекта во всех проектах
Мы могли бы внести «массовые изменения» во многие проекты.

Но у всех есть недостатки, и подход MonoRepo, используемый для того, чтобы иметь представление о монолитном проекте, а не о видении микросервисов, что очень пропитано философией моей компании, но может ли вести себя и то, и другое? Чем хороши MonoRepos и хороши MicroServices? Ответ — да, но вам придется немного повоевать, здесь у вас есть разные программные решения:

NX.js: они лучше всего подходят для создания монорепозитория в JS, содержат генераторы, и вы можете без особых усилий развернуть их в MicroServices, проблема этого решения слишком сложна, если вы не будете следовать его структура, необходимая для начала создания собственных генераторов и скриптов (также передайте все эти знания команде разработчиков)

Я рекомендую этот блог, действительно полезный для знакомства с NX.js с микро
https://blog.nrwl.io/nx-and-node-microservices-b6df3cd1bad6

Lerna.js:Lerna может быть хорошим решением, если у вас есть частное репозиторий NPM, Lerna загрузит каждый Micro в NPM, и они будут в вашем докере, вам нужно установить свою библиотеку MS в свой DockerFile, а затем запустить , для меня может быть решением, но очень сложным

Для меня этот блог помогает понять, как работает Lerna https://semaphoreci.com/blog/javascript-monorepos-lerna

Рабочее пространство TurboRepo/NPM: для меня TurboRepo — лучшее решение не потому, что оно лучшее (на самом деле вам нужно понимать рабочее пространство NPM, чтобы понять TurboRepo), но оно открыто для вашей структуры, и вам нужно только использовать рабочее пространство NPM (в новой версии Lerna оно также используется). TurboRepo оптимизирует ваше выполнение (с разными проектами в одной рабочей области) и создаст кеши, чтобы избежать повторного сброса.
бесполезные команды.

Начало работы с рабочей областью NPM

Следующая документация по NPM могла бы лучше объяснить вам, как рабочее пространство NPM работает лучше, чем мое, я объясню приложение для использования в MicroServices.

https://docs.npmjs.com/cli/v7/using-npm/workspaces

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

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

MyProject
  package.json
  package-lock.json
  applications
  | (Microservices)
  libs
  | (common projects)

У нас есть только одно правило! Одно уникальное правило! (Это правило повлияет на будущие CI/CD)

Проекты приложений НИКОГДА не должны импортировать другие проекты из папки приложений, только из папки libs

Установите микросервис

Мы собираемся установить новый MicroService, называемый User-Service (вы можете увидеть мою реализацию в моем репозитории).

npm init -w ./applications/user-service

Также мы собираемся создать общую библиотеку

npm init -w ./libs/hello-i18n

Теперь структура будет выглядеть так:

MyProject
  package.json
  package-lock.json
  applications
  | (Microservices)
    user-service
      package.json
  |
  libs
  | (common projects)
    hello-i18n
      package.json
  |

Дополнительную информацию можно найти внизу статьи, в разделе "Как работает рабочее пространство NPM".

Теперь мы собираемся установить минимальную установку, чем нужны все проекты, в моем случае это будут Express.js, TypeScript (см. в репо) и winston.js, в корневой папке мы выполнили

npm install --workspaces express winston mocha chai

Это установит зависимости в каждом проекте, и это важный ключевой момент: родительские рабочие пространства NPM не делятся зависимостями со своими дочерними элементами (это не совсем так, но это настоящий беспорядок и может быть отлично, на данный момент сказать, что это невозможно)

Пока я писал этот блог, я понял, что мы можем использовать процессор Gulp или Grunt, чтобы дать нам возможность синхронизировать различные пакеты, которые есть у родительского пакета в каждом дочернем пакете.

Чтобы установить определенную зависимость в другом проекте, вы можете установить ее с помощью команды -w:

npm install axios -w user-service

Как развернуть микросервис?

Это то, чем мы здесь занимаемся, и мы попытаемся ответить на этот вопрос. Идея состоит в том, чтобы создать файл DockerFile для каждого приложения или папки микросервиса, в этот файл DockerFile мы собираемся добавить полный монолит, но , мы добавим целевое приложение и всю папку lib, как в этом примере:

Внутри DockerFile мы устанавливаем все зависимости каждого элемента рабочей области и собираем все проекты (в случае монорепозитория машинописи), эти скрипты размещаются в родительской папке и будут содержать флаг с именем — если присутствует и они дают нам возможность не выделять всю рабочую область в каждой реплике, это здорово!

"scripts": {
  "build-all": "npm run build --workspaces --if-present",
  "install-all": "npm install --workspaces  --if-present",
  "lint-all": "npm run lint --workspaces --if-present",
  "lint-fix-all": "npm run lint-fix --workspaces --if-present"
},

И с этим моментом мы разрешили уникальное правило, которое было создано для этого решения:

Проекты приложений НИКОГДА не должны импортировать другие проекты из папки приложений, только из папки libs

Это связано с тем, что когда мы создаем микросервис, проект приложения не будет иметь доступа к другому приложению, но да к папке lib (это решение может быть изменено для пользовательской адаптации).

Теперь, если мы хотим развернуть это, мы можем использовать docker-compose или Kubernetes, это пример docker-compose, размещенный в корневой папке:

Так что это основная цель этой записи, я должен провести параллель с этим процессом в GitHub!

Как работает рабочее пространство NPM?

Если вы хотите узнать, как работает рабочее пространство NPM, вам нужно выполнить установку npm в родительской корневой папке, здесь NPM установит package.json из каждого дочернего элемента и внедрит его в родительский node_modules.

Если мы перейдем к package.json, мы увидим рабочую область (да, я использую Windows, но одинаково работает в системе Unix).

"workspaces": [
    "applications\\user-service",
    "libs\\*"
  ]

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

npm run test --workspaces

или конкретный проект:

npm run test --workspace=user-service

Рабочие пространства и микросервисы NPM