GraphQL évite-t-il les objets de transfert de données ?

Question

D'après ce que j'ai compris, Objets de transfert de données (DTO) sont généralement des objets sérialisables de petite taille, plats, sans comportement, dont le principal avantage est la facilité de transport sur les réseaux.

GraphQL présente les facettes suivantes :

• encourage à servir graphes d'objets riches ce qui (dans ma tête en tout cas) contredit la partie "plate" des DTO,
• permet aux clients choisir exactement les données qu'ils souhaitent qui répond à la partie "petit",
• renvoie à Objets JSON-esque qui traite des parties "sans comportement" et "sérialisable".

GraphQL et le modèle DTO s'excluent-ils mutuellement ?

Voici ce qui a conduit à cette question : Nous envisageons une architecture de microservices avec une passerelle. Je suis en train de concevoir une API qui s'intégrera dans cette architecture et qui servira (entre autres) à géométries . Dans de nombreux cas (probablement la plupart), les géométries ne seront pas utiles aux applications clientes, mais elles seront critiques dans d'autres cas et doivent donc être servies. Quelle que soit la façon dont elles sont sérialisées, les géométries peuvent être volumineuses, si bien que donner aux clients la possibilité de les refuser permet d'économiser beaucoup de bande passante. Les API RESTful que j'ai vues gérer les géométries le font en fournissant une fonction "Paramètre "returnGeometry dans la chaîne d'interrogation. Je ne me suis jamais senti tout à fait à l'aise avec cette approche, et j'ai d'abord envisagé de servir un ensemble raisonnablement profond d'objets de retour connexes/enchevêtrés, dont beaucoup seront refusés par les clients. Tout cela m'a amené à envisager une interface GraphQL. Au fur et à mesure que la conception a progressé, j'ai commencé à envisager d'aplatir la sortie (entièrement ou partiellement), ce qui m'a amené à envisager le modèle DTO. Maintenant, je me demande s'il ne serait pas préférable de tout aplatir dans des DTO et de ne pas utiliser GraphQL (en faveur de REST, je suppose ?). J'ai envisagé un moyen terme avec des DTOs servis en utilisant GraphQL pour laisser les clients choisir les attributs qu'ils veulent sur eux, mais je me demande si ce n'est pas mélanger les modèles et les technologies de manière inappropriée.

Answer 1

Je pense qu'il est utile de différencier deux cas d'utilisation typiques de GraphQL, et un troisième cas d'utilisation caché qui combine les deux premiers.

Dans les trois cas cependant, la nature même d'un GraphType est de décider de manière sélective quels champs vous voulez exposer à partir de votre entité de domaine. Cela vous semble familier ? C'est normal, c'est ce qu'est un DTO. GraphQL ou pas, vous ne voulez pas exposer le champ "password" de votre table Users par exemple, et vous devez donc le cacher à vos clients d'une manière ou d'une autre.

Ceci est rendu possible par le fait que GraphQL ne fait aucune hypothèse sur votre couche de persistance et vous donne les outils pour traiter vos types d'entrée / requêtes comme vous le souhaitez.

1. Point de terminaison GraphQL exposé directement aux clients (par exemple, web, mobile) :

Dans ce cas d'utilisation, vous utiliserez n'importe quel client GraphQL pour parler à votre graphql directement. Les DTOs ici sont les objets GraphType réels, et sont structurés en fonction des champs que vous avez ajoutés à vos GraphTypes exposés.

En interne, vous utiliseriez des résolveurs de champs pour transformer votre DTO en entité de votre domaine, puis vous utiliseriez votre référentiel pour le conserver.

La transformation DTO se produit à l'intérieur de le résolveur de champs du GraphType.

GraphQL --> DTO --> Domain Entity --> Data Store

2. Point de terminaison REST exposé aux clients, qui consomme en interne un point de terminaison GraphQL :

Dans ce cas d'utilisation, vos clients web et mobiles travaillent avec des DTOs traditionnels via REST. Les contrôleurs, quant à eux, se connectent à un point de terminaison GraphQL exposé en interne - contrairement au cas d'utilisation n°1 - dont les GraphTypes sont une correspondance exacte des entités de votre domaine, champ du mot de passe inclus !

La transformation DTO se fait dans le contrôleur avant appeler le point de terminaison.

DTO --> Domain Entity --> GraphQL --> Data Store

3. Combinaison de 1 et 2

Il s'agit d'un cas d'utilisation lorsque vous faites passer votre architecture de l'une à l'autre et que vous ne voulez pas casser les choses pour les clients. Vous laissez donc les deux options ouvertes et finissez par en déclasser une.

J'espère que cela vous aidera !