Maison >interface Web >js tutoriel >Construisez une passerelle GraphQL: combinez, cachez ou fusionnez n'importe quelle source de données
Points de base
Cet article discutera de la façon d'obtenir des données à partir de plusieurs sources de données tout en gardant rapidement le front-end et une solution potentielle: à l'aide de GraphQL Gateway.
En tant qu'ingénieurs logiciels, nous sommes tous confrontés au défi de créer des données de plusieurs systèmes. Même une seule page exige que les données de plusieurs services soient rendues.
Les données sont partout, du CRM aux systèmes financiers, des plates-formes SaaS aux bases de données. Il est inévitable que chaque entreprise achète un grand nombre de plateformes SaaS et espère ensuite avoir une vue commerciale unifiée en plus de chacun d'eux. Nous devons faire face à ce problème et tout rassembler.
GraphQL Gateway combine les avantages des passerelles API traditionnelles et GraphQL.
Nous allons d'abord discuter des avantages des passerelles API, puis voir comment GraphQL s'inscrit. Veuillez continuer à lire cet article, nous couvrirons certains cadres pour construire nos propres passerelles API.
Avantages de la passerelle API
Protéger les API orientées publiques contre les pirates est un travail toutes les temps. Au fil du temps, les organisations ont évolué pour créer de nombreuses API, des architectures axées sur le service aux microservices. Les organisations ont tendance à ajouter une couche de sécurité supplémentaire plutôt que de mettre ces API directement sur Internet, qui est en avance sur toutes ces API et à garantir que l'accès aux données suit toujours les mêmes règles d'authentification.
Ils utilisent une passerelle API pour ce faire.
Des produits tels que Kong ou Apigee exposent des API internes à partir d'un emplacement central. Ils agissent comme un proxy inversé avec des fonctionnalités telles que la gestion des clés de l'API, la limitation des taux et la surveillance.
La passerelle API nous permet de contrôler qui et ce qui peut accéder à chaque service, les connexions de surveillance et l'accès à l'enregistrement.
Récemment, les applications doivent combiner les données des passerelles API et d'autres fournisseurs de SaaS externes. Cela signifie que les anciens outils centralisés (assurez-vous que nos règles sont suivies) sont désormais contournés régulièrement.
Supposons que nous créons une application Web pour l'entreprise. Notre tâche consiste à créer des pages de profil utilisateur. Pendant le processus de connexion, nous devons combiner les données de plusieurs systèmes:
Le client doit émettre trois demandes distinctes pour obtenir les données, comme le montre la figure ci-dessous.
Dans l'image ci-dessus, le client Web envoie trois demandes API distinctes, puis les résultats doivent être combinés dans le code frontal. L'envoi de plusieurs demandes peut affecter les performances de votre application et la combinaison de ces données peut augmenter la complexité de votre code. De plus, s'il existe plusieurs applications, toutes les applications doivent maintenant connaître tous les backends, et un seul changement d'API dans un service peut entraîner des mises à jour pour toutes nos applications.
Nous pouvons faire mieux. Idéalement, nous voulons réduire la demande de trois à un. Nous pouvons créer un nouveau service pour ce faire - un service qui coordonne les demandes de services backend. Cette idée a un nom: Mode BFF.
Le backend, c'est-à-dire le mode d'architecture Frontend (BFF) permet au frontend d'émettre une seule demande.
Mais comment ça marche? Examinons de plus près ce modèle.
Avantages du mode BFF
À l'aide du mode BFF, l'application envoie une seule demande à la passerelle API. Le service BFF demande ensuite les données de chaque service backend et les combine. Enfin, les données sont filtrées et seules les données requises par le frontal sont renvoyées, réduisant ainsi la quantité de données transmises sur le réseau.
Comme indiqué dans l'image ci-dessus, nous introduisons une couche supplémentaire dans la pile pour coordonner les demandes.
Le point de terminaison du profil utilisateur renvoie les données requises par l'application sur la page de profil. La réduction de nos trois demandes à une a résolu nos problèmes de performances précédents.
mais nous n'avons pas encore fini.
L'entreprise décide de publier une application mobile. L'application mobile a également une page de profil, mais cet écran affiche beaucoup moins d'informations de profil.
À ce stade, l'équipe mobile a deux options. L'équipe peut utiliser les points de terminaison de l'équipe Web, ce qui signifie que nous surfacturé des données (obtenez plus de données dont l'application mobile n'a pas besoin). Une autre option consiste à créer vos propres meilleurs amis dans l'équipe mobile.
Selon les attentes, l'équipe mobile a décidé de créer ses propres meilleurs amis car ils voulaient de bonnes performances pour leurs applications.
Comme indiqué dans l'image ci-dessus, les choses commencent à se compliquer, et nous avons maintenant deux nouveaux problèmes:
Comment résolvons-nous ces problèmes?
Nous avons besoin d'une solution où chaque application peut choisir les données dont elle a besoin, et il devrait être une seule API utilisée par toutes les applications de l'entreprise.
À mesure que BFF mûrit, de nombreux développeurs ont commencé à essayer d'utiliser GraphQL au lieu de repos.
Voyons comment cette technologie peut aider.
Les avantages de GraphQL sur BFF
GraphQL présente de nombreux avantages qui en font une technologie idéale pour BFF:
Le frontal ne peut désormais sélectionner que les données requises pour chaque demande.
Nous pouvons désormais connecter deux de nos applications au même serveur GraphQL, réduisant le besoin d'un deuxième service BFF.
Nous pouvons désormais partager BFF pour toute application dans notre organisation. Nous avons également un seul point final qui doit être testé pour la pénétration.
Mais, nous avons introduit un autre nouveau problème! Nous devons encore gérer deux systèmes - API Gateway et GraphQL BFF.
Et si nous fusions les deux dans une passerelle GraphQL?
Ensuite, voyons comment fonctionne GraphQL Gateway.
Qu'est-ce qu'une passerelle GraphQL?
GraphQL Gateway combine API Gateway avec API GraphQL pour les meilleurs résultats des deux technologies.
passons en revue les avantages:
L'image suivante montre comment les demandes d'API de profil utilisateur fonctionnent avec GraphQL Gateway.
Dans l'image ci-dessus, le client envoie une seule demande à la passerelle GraphQL, demandant ses données requises. La passerelle émet une seule demande à chaque service et combine les résultats. Nous n'avons maintenant qu'un seul service qui doit être géré et déployé.
J'espère que vous êtes prêt à l'essayer vous-même. Ensuite, voyons comment construire une passerelle GraphQL.
Build GraphQL Gateway
Lors du choix d'un cadre de passerelle, nous devons rechercher certaines fonctionnalités clés:
Il existe de nombreux frameworks à choisir, mais je recommande d'explorer les trois cadres suivants.
Hasura est devenu de plus en plus populaire au fil des ans, initialement en tant que serveur GraphQL-Over Over Postgres. Cependant, il augmente la capacité de se connecter à des systèmes externes.
Nous pouvons nous connecter à un "mode distant" qui combine GraphQL à partir d'autres serveurs.
Cette méthode présente quelques inconvénients. Tout d'abord, nous devons créer et gérer notre schéma distant dans un service séparé, et ce service doit être un point de terminaison GraphQL. Cela conduit à un deuxième problème: nous ne pouvons pas nous connecter directement à la source de données.
De plus, Hasura ne nous permet pas de filtrer les données dans une source de données en fonction des valeurs d'une autre source de données. Cela peut sembler académique, mais nous voulons souvent exprimer quelque chose comme «Donnez-moi une commande avec le nom« ABC »».
Cela offre une flexibilité, mais au prix de la gestion de plusieurs services. Jetons un coup d'œil à une option qui peut être connectée directement.
SPEZEN nous permet de nous connecter directement à la source de données à partir du serveur GraphQL. Cela réduit la nécessité d'exécuter plusieurs services pour créer une passerelle.
Pour connecter le SPEZEN à la source de données, nous créons un fichier de schéma GraphQL comme indiqué ci-dessous:
<code>type Query { anything(message: String): JSON @rest ( endpoint: "https://httpbin.org/anything" method: POST headers: [ {name: "User-Agent", value: "StepZen"} {name: "X-Api-Key", value: "12345"} ] postbody: """ { "user": { "id": "1000", "name": "The User" } } """ ) } </code>
Dans cet exemple, nous utilisons le mode personnalisé pour connecter le serveur à la base de données.
Il existe une autre option que vous préférez, qui est l'approche du code pur. Jetons un œil ensuite.
Depuis quelques années, j'ai développé un produit open source appelé Graphweaver qui peut être utilisé comme passerelle GraphQL.
Il se connecte directement à notre source de données et crée une API GraphQL instantanée. Cette API contient toutes les opérations CRUD que nous pouvons nous attendre à créer, lire, mettre à jour et supprimer. Il génère automatiquement des filtres, des paramètres de tri et de pagination, ce qui permet d'économiser du temps. Nous pouvons étendre les opérations intégrées avec notre code pour une flexibilité complète.
Graphweaver fournit des connecteurs de données hors de la boîte pour les bases de données telles que Postgres et MySQL, ainsi que les fournisseurs SaaS tels que Xero et Contentful.
apporter des modifications ou la connexion aux sources de données implique d'écrire du code TypeScript, ce qui nous permet de faire une personnalisation complète.
Si vous êtes intéressé à créer votre propre API GraphQL, je vous recommande fortement de consulter le code Graphweaver GitHub.
Conclusion
Dans cet article, nous examinons comment remplacer notre passerelle API actuelle et notre modèle BFF par une seule passerelle GraphQL.
Nous avons examiné les avantages des passerelles API et pourquoi les organisations les utilisent. Le versioning, la limitation des taux et la gestion de l'accès sont des raisons.
Nous avons également examiné le modèle BFF et comment il coordonne les demandes d'API pour les applications frontales.
Enfin, nous avons regardé GraphQL et pourquoi c'est une technique bénéfique pour BFF.
Fin de la journée, cela nous a amenés à créer une passerelle GraphQL, et nous avons examiné trois options pour créer la nôtre: Hasura, STEPZEN et le produit Graphweaver, que j'ai développé.
J'espère que cet article vous convainc d'essayer d'utiliser vous-même GraphQL Gateway, et si vous le pouvez, envisagez d'essayer Graphweaver.
GraphQL Gateway FAQ (FAQ)
La passerelle GraphQL agit comme un seul point d'entrée pour toutes les opérations GraphQL. Il est responsable de l'acheminement des demandes vers le service correspondant, d'agrégation des réponses et de les renvoyer au client. Cela vous permet de gérer plusieurs modèles et services GraphQL à partir d'un seul emplacement, ce qui rend vos applications plus évolutives et plus faciles à entretenir.
La passerelle API traditionnelle est conçue pour gérer les API RESTful, et son mode de fonctionnement est différent de celui de GraphQL. D'un autre côté, les passerelles GraphQL sont spécialement conçues pour gérer les opérations GraphQL. Il fournit des fonctionnalités telles que les coutures de motifs et la fusion qui vous permettent de combiner plusieurs modèles GraphQL en un seul. C'est quelque chose que les passerelles API traditionnelles ne peuvent pas faire.
Le couture de mode est une fonctionnalité de la passerelle GraphQL qui vous permet de combiner plusieurs modèles GraphQL en un seul. Ceci est particulièrement utile lorsque vous avez plusieurs services et que chacun a son propre schéma et que vous souhaitez les exposer en une seule API. Les coutures de motifs sont responsables de la fusion des modèles et de la résolution de tout conflit, offrant une expérience transparente au client.
Les passerelles GraphQL peuvent améliorer considérablement les performances en réduisant le nombre d'aller-retour entre les clients et les serveurs. Au lieu de faire plusieurs demandes à différents services, le client fait simplement une seule demande à la passerelle GraphQL, qui achemine ensuite les demandes du service correspondant, agrége les réponses et les renvoie au client. Cela réduit la latence du réseau et améliore les performances globales.
Oui, les passerelles GraphQL conviennent particulièrement aux architectures de microservice. Chaque microservice peut avoir son propre motif GraphQL, que la passerelle peut épisser ensemble pour fournir une API unifiée. Cela vous permet de gérer et d'échapper indépendamment les microservices tout en fournissant une interface cohérente à vos clients.
La passerelle GraphQL est sans langue, ce qui signifie qu'elle peut être utilisée avec n'importe quel langage de programmation qui prend en charge GraphQL. Cela comprend des langues populaires telles que Javascript, Python, Ruby et Java.
GraphQL Gateway offre de puissantes capacités de gestion des erreurs. Si une erreur se produit dans l'un des services, la passerelle renvoie un message d'erreur détaillé au client, y compris des informations sur le service a provoqué l'erreur et quelle erreur s'est produite. Cela facilite le diagnostic et la résolution des problèmes.
Oui, GraphQL Gateway est compatible avec l'architecture sans serveur. Vous pouvez déployer votre passerelle en tant que fonction sans serveur, qui vous permet de profiter de l'évolutivité et de la rentabilité de l'informatique sans serveur.
GraphQL Gateway fournit une variété de fonctionnalités de sécurité, notamment l'authentification et l'autorisation, la limitation des taux et la vérification de la demande. Ces fonctionnalités aident à protéger vos services contre l'accès et les abus non autorisés.
Oui, vous pouvez utiliser GraphQL Gateway avec votre API RESTful existante. Les passerelles peuvent envelopper votre API RESTful dans le modèle GraphQL, vous permettant de profiter de GraphQL tout en utilisant des API existantes.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!