3
votes

Partager les interfaces entre l'API et le frontend

Je développe les deux côtés. Une API est dans nest.js et frontend dans Angular. Les deux côtés utilisent dactylographié et je suis confronté à un problème de partage d'interfaces, qui devrait être la même chose. Par exemple ILoginRequest et ILoginResponse. Je veux avoir les deux projets dans des référentiels GIT séparés. Dois-je utiliser le sous-module GIT avec le 3ème dépôt GIT partagé ou créer en quelque sorte un package npm partagé ou y a-t-il un bon outil pour générer automatiquement des classes (à partir de la définition swagger) dans le frontend ou autre chose?

typescript angular git nestjs

2 commentaires

Créer un package npm serait le moyen le plus simple. Tout ce dont vous avez besoin, ce sont vos interfaces et un package.json pour le publier.

graphql pourrait être un bon choix pour vous.

3 Réponses :

1
votes

Ayant rencontré le même problème et examiné quelques alternatives. Voici ce que j'ai considéré et ce que je choisis:

Séparer les définitions d'entité dans une base de code distincte - potentiellement dans un dépôt git différent. Le problème, c'est que le Nest utilise des décorateurs qu'Angular ne comprend pas. Cela signifierait que je devrais inclure Nest comme une dépendance qui semble être une mauvaise idée ou créer des décorateurs de bout - une perte de temps. Rejeté
Création d'un package de nœuds - mêmes problèmes que # 1. Rejeté
Copier coller. Les projets backend et frontend ont tous deux un dossier d'entité. Les entités du backend sont des classes qui sont décorées avec des décorateurs TypeORM (pour moi). Je les copie dans le répertoire d'entités du frontend et les convertis en interfaces parce que ce que vous récupérez de la bibliothèque httpclient (des objets qui doivent être conformes à l'interface - pas des instances de classe). Adopté

Enfin, en regardant les commentaires, je ne vois pas comment GraphQL aide ici car vous n'essayez pas d'exploiter une interface existante - vous cherchez à entendre quelqu'un à ce sujet :)

3 commentaires

Concernant graphql: Vous pouvez créer (et mettre à jour) des définitions de type d'interface avec un script à partir d'un serveur en cours d'exécution. C'est un moyen facile de partager (semi) automatiquement les définitions de type entre les dépôts tout en ayant le contrôle total et en perdant le couplage. Jetez un œil au schéma apollo: téléchargement et client apollo: codegen

Je ne sais pas comment l'option 3 peut fonctionner, quand il s'agit de deux référentiels différents?

Que diriez-vous d'utiliser monorepo (par exemple, les espaces de travail Yarn, lerna) pour le partage

7
votes

REMARQUE: je suis récemment tombé sur typeorm-entitysharer qui "peut être utilisé pour créer des classes client / serveur basées sur les mêmes entités TypeORM, vous permettant de les partager. " Cela vous donne plus de contrôle sur ce que vous souhaitez partager, vous pouvez jeter un œil à leur exemple. Je n'ai pas choisi de l'utiliser parce que c'est un peu exagéré pour moi, je suppose. Cependant, c'est ainsi que j'ai structuré mon dernier projet:

J'ai mon frontend et mon backend dans un référentiel, mais je suppose que vous pourriez les séparer, mais vous auriez toujours besoin de les garder l'un à côté de l'autre. La structure du fichier serait quelque chose comme ceci:

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

Ensuite, dans backend / tsconfig.json vous introduisez

import { PrimaryGeneratedColumn, Column } from 'typeorm';

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

1 commentaires

Merci pour cela, pour moi c'est la voie à suivre sans avoir besoin de maintenir un repo juste avec les entités

0
votes

Après avoir perdu une journée entière à essayer de faire fonctionner cela, je suis tombé sur NX / NRWL .

Il s'agit essentiellement d'une CLI avec des outils pour vous aider à structurer correctement votre application. J'ai pu le faire fonctionner correctement en une heure environ. Les interfaces partagées dans un mono-repo sont la voie à suivre.

0 commentaires