Combinez, assemblez ou fusionnez n’importe quelle source de données –

Dans cet article, nous aborderons le problème de la récupération de données à partir de plusieurs sources tout en gardant notre frontend vif, ainsi qu’une solution potentielle : l’utilisation d’une passerelle GraphQL.

En tant qu’ingénieurs logiciels, nous avons tous été confrontés au défi de combiner les données de nombreux systèmes. Même une seule page nécessite le rendu des données de plusieurs services.

Les données sont partout, des CRM aux systèmes financiers, en passant par les plateformes SaaS et les bases de données. Chaque entreprise achète inévitablement une multitude de plates-formes SaaS, puis souhaite disposer d’une vue commerciale unifiée sur chacune d’entre elles. Il faut prendre cela de front et tout intégrer.

Une passerelle GraphQL combine les avantages d’une passerelle API traditionnelle avec GraphQL.

Nous commencerons par discuter des avantages d’une passerelle API, puis examinerons comment GraphQL s’intègre. Restez à la fin de l’article, où nous examinerons certains cadres pour créer notre propre passerelle API.

Avantages d’une passerelle API

Sécuriser nos API publiques contre les pirates informatiques est un travail à temps plein. Au fil du temps, les organisations ont évolué pour créer de nombreuses API, depuis SOA aux microservices. Au lieu de mettre ces API directement sur Internet, les organisations préfèrent ajouter une couche de sécurité supplémentaire devant toutes ces API et garantir que l’accès aux données suit toujours les mêmes règles d’authentification.

Ils le font avec une passerelle API.

Des produits tels que Kong ou Appelez-le exposez les API internes à partir d’un emplacement central. Ils agissent comme un proxy inverse avec des fonctionnalités telles que la gestion des clés API, la limitation du débit et la surveillance.

La passerelle API nous permet de contrôler qui et quoi a accès à chaque service, en surveillant les connexions et en enregistrant l’accès.

Plus récemment, les applications ont dû combiner les données d’une passerelle API et d’autres fournisseurs SaaS externes. Cela signifie que l’ancien outil centralisé – qui garantissait le respect de nos règles – est désormais régulièrement contourné.

Imaginez que nous construisons une application Web pour notre entreprise. Nous avons pour tâche de créer la page de profil utilisateur. Pendant le processus de connexion, nous devons combiner les données de nombreux systèmes :

• CRM Salesforce: contient les données générales du client telles que le prénom et le nom.
• Ordres: les commandes récentes sont dans un système de commande au sein de l’organisation.
• Service de notifications: les paramètres de notification et les messages récents se trouvent dans une base de données spécifique à l’application connectée à un service Node.js.

Le client devra faire trois demandes distinctes pour obtenir les données, comme représenté dans l’image ci-dessous.

Dans l’image ci-dessus, le client Web envoie trois requêtes API distinctes et doit ensuite combiner les résultats dans le code frontend. L’envoi de plusieurs requêtes affecte les performances de l’application et la combinaison de ces données augmente la complexité du code. De plus, s’il existe plusieurs applications, toutes les applications doivent désormais connaître tous les backends, et une seule modification d’API dans un service peut entraîner des mises à jour de toutes nos applications.

Nous pouvons faire mieux. Idéalement, nous souhaitons réduire les requêtes de trois à une seule récupération. Nous pourrions créer un nouveau service pour ce faire – un service qui orchestre les requêtes adressées aux services backend. Cette idée a un nom : le Modèle BFF.

Le Modèle d’architecture backend pour frontend (BFF) permet une seule requête depuis le frontend.

Mais comment ça fonctionne? Examinons ce modèle plus en détail.

Les avantages du modèle BFF

Avec le modèle BFF, une application envoie une seule requête à 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, renvoyant uniquement les données nécessaires au front-end, réduisant ainsi les données envoyées par fil.

Comme illustré dans l’image ci-dessus, nous avons introduit une couche supplémentaire dans la pile pour orchestrer la requête.

Le point de terminaison du profil utilisateur renvoie les données nécessaires à cette application sur la page de profil. La réduction de nos trois requêtes à une seule requête a résolu notre précédent problème de performances.

Mais nous n’avons pas encore fini.

L’entreprise a décidé de lancer une application mobile. L’application mobile dispose également d’une page de profil, mais cet écran affiche beaucoup moins d’informations de profil.

À ce stade, l’équipe mobile dispose de deux options. L’équipe pourrait réutiliser le point de terminaison de l’équipe Web, ce qui signifierait que nous extrairions les données (en récupérant plus de données que nécessaire pour l’application mobile). L’alternative est que l’équipe mobile crée son propre BFF.

Sans surprise, l’équipe mobile décide de créer son propre BFF, car elle souhaite de bonnes performances pour son application.

Comme l’illustre l’image ci-dessus, les choses commencent à se compliquer, et nous sommes désormais confrontés à deux nouveaux problèmes :

• Chaque équipe doit créer un nouveau service BFF pour chaque application qu’elle crée, ce qui ralentit chaque équipe et rend difficile la standardisation.
• Chaque BFF doit être testé pour garantir sa sécurité.

Comment pouvons-nous résoudre ces problèmes ?

Nous avons besoin d’une solution dans laquelle chaque application peut sélectionner les données dont elle a besoin, et il doit s’agir d’une API unique utilisée par toutes les applications de l’entreprise.

À mesure que les BFF ont mûri, de nombreux développeurs ont commencé à expérimenter GraphQL au lieu de REST.

Voyons comment cette technologie peut aider.

Les avantages de GraphQL pour une meilleure amie

GraphQL possède de nombreux atouts qui en font une technologie idéale pour un BFF :

• Récupération efficace des données. GraphQL permet aux clients de demander exactement les données dont ils ont besoin et rien de plus. Cela améliore les performances en réduisant les données transférées depuis l’API.
• Point de terminaison unique. Au lieu d’exposer plusieurs points de terminaison via la passerelle, GraphQL utilise un seul point de terminaison pour toutes les requêtes. Cela simplifie la maintenance et le besoin de versionner.
• Requêtes flexibles. Les clients peuvent créer des requêtes en combinant des champs et des relations en une seule requête. Cela permet aux développeurs frontend d’optimiser la récupération de données, augmentant ainsi les performances. De plus, si les exigences du frontend changent, celui-ci peut être mis à jour pour récupérer différentes données sans altérer le backend de quelque manière que ce soit.

Les frontends peuvent désormais sélectionner uniquement les données dont ils ont besoin pour chaque requête.

Nous pouvons désormais connecter nos deux applications au même serveur GraphQL, réduisant ainsi le besoin d’un deuxième service BFF.

Nous pouvons désormais partager le BFF pour n’importe quelle application de l’organisation. Nous avons également un seul point de terminaison qui doit être testé.

Mais encore une fois, nous avons introduit un nouveau problème ! Nous devons encore gérer deux systèmes : la passerelle API et le GraphQL BFF.

Et si nous combinions les deux dans une passerelle GraphQL ?

Voyons ensuite comment fonctionne une passerelle GraphQL.

Qu’est-ce qu’une passerelle GraphQL ?

Une passerelle GraphQL combine une passerelle API avec une API GraphQL pour tirer le meilleur parti des deux technologies.

Récapitulons les avantages :

• Les développeurs disposent d’un seul point de terminaison d’API à partir duquel demander des données. Cela réduit la surextraction ou la sous-extraction, car chaque application sélectionne uniquement les données dont elle a besoin.
• La passerelle GraphQL est partagée par de nombreuses applications au sein de l’organisation. Cela signifie que nous avons réduit notre exposition à la sécurité à un seul point de terminaison d’API.
• Nous n’avons plus qu’un seul service à gérer, maintenant que le BFF est associé à la passerelle.

Le diagramme ci-dessous montre comment la requête API de profil utilisateur fonctionne avec une passerelle GraphQL.

Dans l’image ci-dessus, le client envoie une seule requête à la passerelle GraphQL, demandant les données dont elle a besoin. La passerelle envoie des requêtes individuelles à chaque service et combine les résultats. Nous n’avons désormais qu’un seul service à gérer et à déployer.

J’espère que vous êtes prêt à essayer cela par vous-même. Voyons ensuite comment créer une passerelle GraphQL.

Construire une passerelle GraphQL

Lors du choix d’un framework de passerelle, nous souhaitons rechercher certaines fonctionnalités clés :

• Plusieurs sources. La passerelle doit se connecter à de nombreuses sources de données – des bases de données au SaaS – et nous devrions pouvoir créer nos connexions.
• Routage. La passerelle doit pouvoir demander directement des données aux services sous-jacents.
• Traitement par lots. Plusieurs requêtes au même service sont envoyées par lots, réduisant ainsi le nombre de requêtes.
• Sécurité. L’authentification et l’autorisation doivent contrôler qui peut accéder aux données connectées.
• Filtrage inter-sources de données. Des filtres puissants doivent être disponibles pour ne pas surcharger les données nécessaires au client.
• Extensible. Les développeurs doivent pouvoir étendre le code avec un middleware ou des fonctions pour répondre à leurs besoins.

Il existe de nombreux frameworks parmi lesquels choisir, mais voici les trois principaux que je recommande d’explorer davantage.

rencontré

rencontré a gagné en popularité au fil des années, initialement en tant que serveur GraphQL-over-Postgres. Cependant, il a ajouté la possibilité de se connecter à des systèmes externes.

Nous pouvons connecter un « Remote Schema », qui combine GraphQL d’autres serveurs.

Cette approche présente certains inconvénients. La première est que nous devons créer et gérer notre schéma distant dans un service distinct, et ce service doit être un point de terminaison GraphQL. Cela nous amène au deuxième problème : nous ne pouvons pas connecter directement la source de données.

De plus, Hasura ne nous permet pas de filtrer les données d’une source de données en fonction des valeurs d’une autre. Cela peut sembler académique, mais il est en fait assez courant que nous souhaitions exprimer quelque chose comme : « Donnez-moi des commandes dont le nom du client est « ABC ». »

Cela offre de la flexibilité, mais au détriment de l’exécution de plusieurs services. Regardons une option qui se connectera directement.

StepZen

StepZen nous permet de nous connecter à la source de données directement depuis le serveur GraphQL. Cela réduit le besoin d’exécuter plusieurs services pour créer une passerelle.

Pour connecter Stepzen à une source de données, nous créons un fichier de schéma GraphQL comme celui-ci :

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"
         }
      }
    """
    )
}

Dans cet exemple, nous connectons le serveur à une base de données à l’aide du schéma personnalisé.

Il existe une autre option que vous préférerez peut-être, à savoir une approche basée uniquement sur le code. Voyons cela ensuite.

Graphweaver

Depuis quelques années, je travaille sur un produit open source appelé Graphweaverqui peut être utilisé comme passerelle GraphQL.

Il se connecte directement à nos sources de données et crée une API GraphQL instantanée. Cette API inclut toutes les opérations CRUD que nous pourrions nous attendre à créer, lire, mettre à jour et supprimer. Il génère automatiquement des filtres, des arguments de tri et de pagination, ce qui permet de gagner du temps. Nous pouvons étendre les opérations intégrées avec notre code pour une flexibilité totale.

Graphweaver dispose de connecteurs de données prêts à l’emploi pour les bases de données telles que Postgres et Mysql et les fournisseurs SaaS comme Xero et Contentful.

Apporter des modifications ou connecter des sources de données implique d’écrire du code Typescript, nous offrant une personnalisation complète.

Si vous souhaitez créer votre propre API GraphQL, je vous recommande vivement jetez un œil au code GitHub de Graphweaver.

Conclusion

Dans cet article, nous avons vu comment remplacer notre passerelle API et notre modèle BFF actuels par une seule passerelle GraphQL.

Nous avons examiné les avantages d’une passerelle API et pourquoi les organisations les utilisent. Le contrôle de version, la limitation de débit et la gestion des accès en sont quelques-unes.

Nous avons également examiné le modèle BFF et la manière dont il orchestre les requêtes API pour les applications frontales.

Enfin, nous avons examiné GraphQL et en quoi il s’agit d’une technologie bénéfique pour les meilleures amies.

En fin de compte, cela nous a conduit à créer une passerelle GraphQL et nous avons examiné trois options pour créer la nôtre : Hasura, StepZen et le produit sur lequel j’ai travaillé, Graphweaver.

J’espère que cet article vous a convaincu d’essayer votre propre passerelle GraphQL et, si tel est le cas, que vous envisagerez d’essayer Graphweaver.