Обмен интерфейсами между API и внешним интерфейсом - PullRequest
Новая
       3

Обмен интерфейсами между API и внешним интерфейсом

0 голосов
/ 01 марта 2019

Я развиваю обе стороны.API находится в nest.js, а внешний интерфейс - в Angular.Обе стороны используют машинопись, и я сталкиваюсь с проблемой совместного использования интерфейсов, которая должна быть одинаковой.Например, ILoginRequest и ILoginResponse.Я хочу, чтобы оба проекта были в отдельных репозиториях GIT.Должен ли я использовать подмодуль GIT с третьим общим репозиторием GIT или каким-либо образом создать общий пакет npm, или есть какой-то хороший инструмент для автоматического генерирования классов (из определения чванства) во внешний интерфейс или что-то еще?

Ответы [ 2 ]

0 голосов
/ 08 августа 2019

ПРИМЕЧАНИЕ. Недавно я наткнулся на typeorm-entitysharer , который "может использоваться для создания клиент-серверных классов на основе одних и тех же сущностей TypeORM, что позволяет вам делиться ими".Это дает вам больше контроля над тем, что вы хотите поделиться, вы можете взглянуть на их пример.Я не решил использовать его, потому что это для меня излишне.Тем не менее, вот как я структурировал свой последний проект:

У меня есть мой фронтенд и бэкэнд в одном репозитории, но я думаю, вы могли бы разделить их, но вам все равно нужно как-то держать их рядом друг с другом.Структура файла будет выглядеть примерно так: 
workspace
  ├─backend        <- repo #1
  │   ├─src
  │   │   ├─shared <- shared code goes here
  │   │   └─proxy.ts
  │   └─tsconfig.json
  └─frontend       <- repo #2
      ├─src
      │   └─proxy.ts
      └─tsconfig.json

Затем в backend/tsconfig.json вы вводите 

{
    ...
    "paths": {
        "@shared/*": [ "src/shared/*" ],
    }
}

, а в frontend/tsconfig.json вы вводите 

{
    ...
    "paths": {
        "@shared/*": [ "../backend/src/shared/*" ],

        // if you're using TypeORM, this package has dummy decorators
        "typeorm": [ "node_modules/typeorm/typeorm-model-shim.js" ]
        // you can do the same for other packages, point them to dummy paths

        // altirnatively you can route the shared imports through the proxy.ts
        // and replace them in frontend/src/proxy.ts with dummy ones
    }
}

также не забудьте npm i typeorm в своем интерфейсе.

Пример

Допустим, у меня есть это в backend/src/shared/user.entity.ts

import { PrimaryGeneratedColumn, Column } from 'typeorm';

export class UserEntity
{
    @PrimaryGeneratedColumn() id: number;
    @Column() name: string;
    @Column() password: string;
}

Теперь я могу использовать его где угодно, например так: 

import { UserEntity } from '@shared/model/user.entity';

В бэкэнде это очевидно, а во внешнем интерфейсе @shared/model/user.entity сопоставляется с ../backend/src/shared/model/user.entity, а import from 'typeorm' внутри сущности сопоставляется спустышка.

0 голосов
/ 01 марта 2019

Столкнувшись с той же проблемой и рассмотрел несколько альтернатив.Вот что я рассмотрел и что я выбрал:

  1. Разделение определений сущностей в отдельную базу кода - потенциально в другом git-репо.Проблема заключается в том, что Nest использует декораторы, которые Angular не понимает.Это означало бы, что мне придется включить Nest в качестве зависимости, которая кажется плохой идеей, или создать декораторы-заглушки - пустая трата времени.Отклонено
  2. Создание пакета узла - те же проблемы, что и # 1.Отклонено
  3. Копировать вставить.И у внутреннего, и у внешнего проекта есть папка объекта.Объекты бэкэнда - это классы , которые украшены декораторами TypeORM (для меня).Я копирую их в каталог сущностей внешнего интерфейса и преобразую их в интерфейсы , потому что вы получаете обратно из библиотеки httpclient (объекты, которые должны соответствовать интерфейсу, а не экземпляры классов).Принято

Наконец, просматривая комментарии, я не вижу, как GraphQL помогает здесь, поскольку вы не пытаетесь использовать существующий интерфейс - надеясь услышать от кого-то об этом:)

...