Организация Typescript и Node.js для общей библиотеки между микро-сервисами - PullRequest
0 голосов
/ 20 октября 2019

В системе микроуслуг, с несколькими микроуслугами node.js + express + typcript, у меня есть инфра-код, который я хотел бы разделить между различными микроуслугами node.js, вопрос в том, как организовать /правильно построить эту библиотеку, чтобы все микросервисы могли использовать эту библиотеку, так как существует несколько деталей реализации модуля, который пересекается между машинописью, приложением monoloithic node.js и системой узлов мультисервисов:

dir:
app-services
---service1
---service2
---serviceN
---service-infra
------data
------com
------security

Теперь, если онабыло только одно приложение монолитного узла, используя машинописный текст, я смог бы

import ClassA from "service-infra/data/ClassA"
import ClassB from "service-infra/data/ClassB"
import security from "service-infra/security"

Но поскольку это общая библиотека, а не внутри службы, она сама, нужно упаковать все это в один модуль узла и создатьФайл модуля index.ts, в который я импортирую все внутренние классы и реэкспортирую их, поэтому любая служба просто сможет добавить зависимость в свой package.json и импортировать эти классы через index.ts, но при этом плохо переопределити отменить внутреннюю структуру каталогов модуля data / com / securityh 'мешок' смешанного и различного экспорта, который я пытаюсь предотвратить.

Другой вариант заключается в том, что я определяю каждый com / security / data как отдельный модуль узла со своим собственным package.json (npm init), но у него большие накладные расходы на обслуживание, поэтому я стараюсь избегать этого, если неЕдинственный способ.

Из документации по машинописи:

On the organization front, namespaces are handy for grouping together logically-related objects and types in the global scope. For example, in C#, you’re going to find all the collection types in System.Collections. By organizing our types into hierarchical namespaces, we provide a good “discovery” experience for users of those types. Modules, on the other hand, are already present in a file system, necessarily. We have to resolve them by path and filename, so there’s a logical organization scheme for us to use. We can have a /collections/generic/ folder with a list module in it.

Но я не понимаю, как можно организовать код с использованием каталогов при упаковке всего src в качестве модуля узла для потребления другими службами в качестве импорта-re-export отменяет эту структуру dir, возможно только при реализации в одной и той же службе.

В нижней строке: 1. Как получить «подобные пространства имен или подобные каталоги» совместно используемой библиотеки в сценарии типа, упакованном какмодуль, который может быть использован другими службами?

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

Спасибо за вашу помощь / руководство и время,

С уважением,

Джеймс

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...