Особенности архитектуры: пользовательский моно-репорт Angular CLI с кодом браузера и сервера - PullRequest
Новая
       2

Особенности архитектуры: пользовательский моно-репорт Angular CLI с кодом браузера и сервера

0 голосов
/ 03 декабря 2018

В моей компании есть небольшой проект, который служит начальным проектом для более быстрой загрузки реальных проектов.Это экспресс + Angular-проект.Недавно мы перевели его с полностью настраиваемой архитектуры Webpack на Angular CLI, поскольку теперь она позволяет иметь больше настраиваемых настроек (мы используем настраиваемые компоновщики Angular).

По сути, это выглядит так (и этовдохновлено nrwl схемами, но мы их не используем): 

.
├── apps          Project applications
│   ├── client      Angular client
│   ├── server      Node.js server, API...
├── shared        Reusable, portable JavaScript code
│   ├── intl        Contains translations strings and basic i18n configuration
│   ├── models      Basic TypeScript definitions of the database documents used both in the client and the server
│   └── ...         A few other little things that are platform-agnostic
└── webpack       Additional Webpack configuration
    ├── client
    └── server

Оказалось, что оно очень хорошо работает на небольших проектах (у нас есть несколько).

Теперь мы перенесли наш главный большой проект на эту архитектуру.На данный момент это выглядит так: 

.
├── apps
│   ├── admin      Angular app
│   ├── cli        The CLI was previously part of the server
│   ├── server
│   └── worker     The worker was also part of the server
├── shared
│   ├── intl
│   ├── models
│   └── ...
└── webpack
    ├── admin
    ├── cli
    ├── server
    └── worker

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

Он компилируется, но я хотел бы разделить проблемытем более что эти «приложения» не должны искусственно зависеть друг от друга;в настоящее время это не имеет смысла.В будущем будут добавлены другие приложения (миграция еще не завершена, мы добавим в нее другие репозитории).

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

Например, в apps/server у нас есть бизнес-логика, декларации схемы и моделей mongoose ODM или служебные модули, такие как регистратор и конфигурация.

Я просто не знаю, куда поместить эти вещитак как они также используются cli и worker (в настоящее время они просто import, что им нужно от server).Я также хочу сделать их доступными для будущих приложений.

Да, есть shared/, но в настоящее время у нас есть только переносимый код, который работает на стороне браузера и сервера.

Если мы поместим в него код, специфичный для Node или Angular, как семантически показать, что они не полностью доступны для совместного использования?Как понять, что такая папка предназначена для узла, а этот - многоразовый угловой модуль?Где разместить бизнес-логику?

У Nrwl есть папка libs/, но опять же, это просто, потому что она официально охватывает только код Angular.

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

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

...