Comment faire en sorte que GraphQL et DynamoDB jouent bien ensemble

Les architectures sans serveur, les API GraphQL et les bases de données DynamoDB forment une combinaison puissante pour le développement de sites Web. Bien que SERVERS et GraphQL soient très populaires, DynamoDB est souvent mal compris ou évité, parfois à tort rejeté comme bénéfique à des échelles massives.

Initialement, j'ai partagé cette idée fausse, préférant les bases de données SQL pour mes projets sans serveur. Cependant, après avoir acquis de l'expérience avec DynamoDB, j'ai découvert ses avantages à travers différentes tailles de projet. Pour illustrer, construisons une exemple d'API à partir de zéro, en contournant les cadres complexes ORMS ou GraphQL pour révéler les mécanismes sous-jacents. Cette approche pratique pourrait modifier votre point de vue sur la valeur de DynamoDB.

Répondre aux préoccupations communes

Le principal obstacle à l'adoption de DynamoDB est sa courbe d'apprentissage abrupte, bien que ses capacités soient rarement contestées. Bien que la courbe d'apprentissage soit importante, les bases de données SQL ne sont pas idéales pour les applications sans serveur. Les défis du déploiement et de la gestion des connexions de la base de données SQL dans un environnement sans serveur sont substantiels. DynamoDB, étant intrinsèquement sans serveur, adapté à un serveur, offre un avantage à long terme en atténuant les futures complexités de mise à l'échelle. L'investissement initial dans l'apprentissage DynamoDB permet finalement d'économiser des maux de tête considérables.

L'adéquation de l'appariement GraphQL avec DynamoDB est plus complexe. Une grande partie de la documentation GraphQL, des tutoriels et des exemples existants supposent des bases de données relationnelles. Même Alex Debrie, un expert DynamoDB et auteur de "The DynamoDB Book", conseille cette combinaison, principalement en raison de la pratique courante d'écrire des résolveurs GraphQL en tant qu'appels de base de données indépendants séquentiels, conduisant à des lectures excessives.

Un autre problème potentiel est la préférence de DynamoDB pour les modèles d'accès prédéfinis. La force de GraphQL réside dans sa capacité à gérer plus facilement les requêtes arbitraires que le repos. Cela devient plus problématique avec les API publiques où les utilisateurs peuvent créer des requêtes imprévisibles. Cependant, GraphQL est fréquemment utilisé pour les API privés, où le contrôle sur le client et le serveur permet de gérer et de contrôler les modèles de requête. Sans conception minutieuse, les requêtes GraphQL peuvent facilement surcharger une base de données.

Un modèle de données simple

Cet exemple d'API modélisera une organisation avec des équipes, des utilisateurs et des certifications. Les relations sont représentées dans le diagramme de la relation entité ci-dessous. Chaque équipe a plusieurs utilisateurs et chaque utilisateur peut posséder plusieurs certifications.

Représentation de la base de données relationnelle

Bien que notre cible soit un modèle DynamoDB, une représentation de la base de données SQL ressemblerait au diagramme suivant: (le diagramme serait là, montrant des tables et des relations)

Pour gérer la relation plusieurs à plusieurs entre les utilisateurs et les certifications, une table intermédiaire appelée "Contalitude" est introduite. La date d'expiration sert d'attribut unique dans ce tableau. Pour plus de simplicité, d'autres attributs sont omis.

Modèles d'accès

La modélisation des données de DynamoDB efficace dépend de la compréhension des modèles d'accès. Les bases de données relationnelles commencent par des données normalisées et utilisent des jointures pour la récupération des données. DynamoDB manque de jointures; Par conséquent, le modèle de données doit s'aligner sur les méthodes d'accès prévues. Ceci est un processus itératif. Prioriser les modèles d'accès fréquents. Beaucoup se givront directement aux requêtes GraphQL, tandis que d'autres pourraient être utilisées en interne pour l'authentification ou l'autorisation. Les opérations peu fréquentes (par exemple, les contrôles administratifs hebdomadaires) ne nécessitent pas une conception optimisée; Les méthodes inefficaces (comme les scanneurs de table) peuvent suffire.

Accès haute fréquence:

• Utilisateur par identifiant ou nom
• Équipe par identifiant ou nom
• Certification par identifiant ou nom

Accès fréquent:

• Tous les utilisateurs d'une équipe (par équipe d'équipe)
• Toutes les certifications pour un utilisateur
• Toutes les équipes
• Toutes les certifications

Accès peu fréquent:

• Toutes les certifications d'utilisateurs au sein d'une équipe
• Tous les utilisateurs possédant une certification spécifique
• Tous les utilisateurs avec une certification au sein d'une équipe

Conception de table à table DynamoDB

Le manque de jointures de DynamoDB nécessite une interrogation en fonction de la clé primaire ou des index prédéfinis. La base de données n'applique pas un schéma, permettant divers types d'articles dans une seule table. La meilleure pratique consiste à stocker tous les articles dans une seule table pour un accès efficace aux données colocalisées. Le schéma ci-dessous reflète cette approche, s'alignant avec les modèles d'accès identifiés précédemment. (Les détails du schéma seraient là, montrant la clé primaire, la clé de tri et les index)

La clé principale est un composite de la clé de partition (PK) et de la clé de tri (SK). La récupération des éléments nécessite de spécifier la clé de partition et soit une valeur de clé de tri unique ou une plage. Les index (GSI1PK, GSI1SK, etc.) sont utilisés pour un accès flexible à différents types d'articles. Le symbole "#" agit comme un espace réservé pour les clés de tri vides.

Implémentation du schéma de base de données (Code Snippet)

Le schéma de la base de données est appliqué dans l'application. L'API de DynamoDB est puissante mais complexe. De nombreux développeurs utilisent des ORM pour la simplification. Ici, nous allons accéder directement à la base de données à l'aide des fonctions d'assistance pour définir le schéma d'élément d'équipe. (Code Snippet pour DB_MAP, y compris les fonctions Get, Put et analyse pour l'équipe, serait ici)

Pour ajouter une nouvelle équipe, vous appelleriez: DB_MAP.TEAM.put({teamId:"t_01",teamName:"North Team"})

Cela génère l'index et les valeurs de clé pour l'API de la base de données. La méthode parse convertit les éléments de la base de données au modèle d'application.

Schéma GraphQL (Code Snippet)

(Définition du schéma GraphQL pour l'équipe, l'utilisateur, la certification, les informations d'identification et la requête seraient là.)

Connexion GraphQL et DynamoDB avec Resolvers

Resolvers Exécuter des requêtes GraphQL. Les résolveurs sont essentiels pour construire notre API. Chaque requête du schéma GraphQL a un résolveur racine correspondant (seuls les résolveurs d'équipe sont affichés ici). Ces résolveurs renvoient une promesse ou un objet contenant des résultats de requête partielle.

Si une requête renvoie un type Team , l'exécution passe au résolveur de type Team . Ce résolveur a une fonction pour chaque attribut Team . Si un résolveur est manquant (par exemple, pour id ), il vérifie si le résolveur racine a fourni la valeur.

Une requête prend quatre arguments: root (objet parent), args (arguments de requête), context (données d'application, ici y compris la référence de la base de données) et info (détails de la requête, non utilisés ici).

Les résolveurs ci-dessous utilisent ctx.db.singletable pour accéder à la table DynamoDB. Les méthodes get et query interagissent directement avec la base de données, et DB_MAP.TEAM... traduit le schéma à l'aide des fonctions d'assistance. La méthode parse convertit les données au format de schéma GraphQL. (Code Snippet pour ResolverMap, y compris Resolvers pour Query.team, Query.teambyName, Query.AllTeams, Team.name, Team.members, User.Name, User.Credentials serait là)

Tracez l'exécution de la requête suivante: Le résolveur de racine de l'équipe lit l'équipe par ID, l'ID et le nom de retour. Le résolveur de type Team récupère alors tous les membres de l'équipe. Le résolveur de type User obtient des informations d'identification et des certifications pour chaque utilisateur. Avec cinq membres et cinq informations d'identification chacune, cela se traduit par sept lectures de base de données. Bien que cela puisse sembler excessif par rapport à une base de données SQL (potentiellement quatre appels), les sept lectures DynamoDB pourraient être plus rapides et moins chères en fonction de divers facteurs.

 Query {Team (id: "t_01") {
  identifiant
  nom
  membres {
    identifiant
    nom
    informations d'identification{
      identifiant
      certification {
        identifiant
        nom
      }
    }
  }
}}

Excessif et le problème n 1

L'optimisation d'une API GraphQL implique de nombreux compromis. Deux considérations clés lors du choix entre DynamoDB et SQL sont excessives et le problème N 1. Ce sont souvent des forces opposées. La surclassement se produit lorsqu'un résolveur demande plus de données que nécessaire. Cela se produit lorsqu'un résolveur racine ou de type (par exemple, members du résolveur Team ) tente de récupérer des données excessives dans un seul appel de base de données. Si la requête n'a pas demandé l'attribut name , la récupérer est un gaspillage.

Le problème N 1 est le contraire. Pousser toutes les lectures vers le résolveur de niveau le plus bas signifie des demandes de base de données minimales ou non à des niveaux plus élevés. Au lieu d'un appel pour obtenir les cinq membres, cinq lectures distinctes sont faites. Cela peut conduire à de nombreuses autres lectures. En pratique, des outils comme DatalOader lancent ces demandes, réduisant le nombre d'appels de base de données. Ces demandes atomiques plus petites sont cruciales pour un lot efficace.

Pour SQL, les petits résolveurs de bas niveau avec DatalOader sont généralement les meilleurs. Pour DynamoDB, les résolveurs de niveau supérieur "plus intelligents" qui s'alignent sur la conception unique sont plus efficaces. La surclassement est souvent le moindre mal dans ce contexte.

Déploiement (résumé)

Cet exemple peut être déployé rapidement à l'aide d'architectes, un outil open-source pour créer des applications sans serveur sur AWS. Le référentiel GitHub fournit le code. Après le clonage et l'exécution npm install , l'application (y compris une base de données locale) peut être lancée localement. Le déploiement en production sur AWS (y compris DynamoDB) est également simple.

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!