Programmation d'Amazon DynamoDB avec JavaScript

Ce guide fournit une orientation aux programmeurs souhaitant utiliser Amazon DynamoDB avec. JavaScript Découvrez les couches d'abstraction disponibles AWS SDK for JavaScript, la configuration des connexions, la gestion des erreurs, la définition des politiques de nouvelle tentative, la gestion du maintien en vie, etc.

À propos AWS SDK for JavaScript

AWS SDK for JavaScript Permet d'accéder à Services AWS l'utilisation de scripts de navigateur ou de Node.js. Cette documentation se concentre sur la dernière version du SDK (V3). La AWS SDK for JavaScript V3 est maintenue par AWS un projet open source hébergé sur. GitHub Les problèmes et les demandes de fonctionnalités sont publics et vous pouvez y accéder sur la page des problèmes du GitHub référentiel.

JavaScript La V2 est similaire à la V3, mais contient des différences de syntaxe. La version 3 est plus modulaire, ce qui facilite l'expédition de petites dépendances, et offre un support de premier ordre TypeScript . Nous vous recommandons d'utiliser la dernière version du SDK.

Utilisation de la AWS SDK for JavaScript V3

Vous pouvez ajouter le SDK à votre application Node.js à l'aide du Node Package Manager. Les exemples ci-dessous montrent comment ajouter les packages SDK les plus courants pour travailler avec DynamoDB.

• npm install @aws-sdk/client-dynamodb

• npm install @aws-sdk/lib-dynamodb

• npm install @aws-sdk/util-dynamodb

L'installation de packages ajoute des références à la section de dépendance de votre fichier de projet package.json. Vous avez la possibilité d'utiliser la nouvelle syntaxe du module ECMAScript. Pour plus de détails sur ces deux approches, consultez la section Considérations.

Accès à JavaScript la documentation

Commencez par consulter la JavaScript documentation à l'aide des ressources suivantes :

• Accédez au guide du développeur pour accéder à la JavaScript documentation de base. Les instructions d'installation se trouvent dans la section Configuration.

• Accédez à la documentation de référence de l'API pour explorer toutes les classes et méthodes disponibles.

• Le SDK pour JavaScript prend en charge de nombreuses Services AWS autres solutions que DynamoDB. Utilisez la procédure suivante pour localiser la couverture d'API spécifique pour DynamoDB :

  1. Dans Services, sélectionnez DynamoDB et Bibliothèques. Cela documente le client de bas niveau.

  2. Choisissez lib-dynamodb. Cela documente le client de haut niveau. Les deux clients représentent deux couches d'abstraction différentes que vous avez le choix d'utiliser. Consultez la section ci-dessous pour plus d'informations sur les couches d'abstraction.

Couches d'abstraction

Le SDK pour JavaScript V3 possède un client de bas niveau (DynamoDBClient) et un client de haut niveau (). DynamoDBDocumentClient

Rubriques

• Client de bas niveau () DynamoDBClient

• Client de haut niveau (DynamoDBDocumentClient)

Client de bas niveau () DynamoDBClient

Le client de bas niveau ne fournit aucune abstraction supplémentaire par rapport au protocole filaire sous-jacent. Cela vous donne un contrôle total sur tous les aspects de la communication, mais comme il n'y a pas d'abstractions, vous devez notamment fournir des définitions d'éléments à l'aide du format DynamoDB JSON.

Comme le montre l'exemple ci-dessous, avec ce format, les types de données doivent être indiqués explicitement. Un S indique une valeur de chaîne et un N une valeur numérique. Les numéros sur le fil sont toujours envoyés sous forme de chaînes étiquetées sous forme de types numériques pour éviter toute perte de précision. Les appels d'API de bas niveau ont un modèle de dénomination tel que PutItemCommand etGetItemCommand.

L'exemple suivant utilise un client de bas niveau Item défini à l'aide de DynamoDB JSON :

const { DynamoDBClient, PutItemCommand } = require("@aws-sdk/client-dynamodb");

const client = new DynamoDBClient({});

async function addProduct() {
  const params = {
    TableName: "products",
    Item: {
      "id": { S: "Product01" },
      "description": { S: "Hiking Boots" },
      "category": { S: "footwear" },
      "sku": { S: "hiking-sku-01" },
      "size": { N: "9" }
    }
  };

  try {
    const data = await client.send(new PutItemCommand(params));
    console.log('result : ' + JSON.stringify(data));
  } catch (error) {
    console.error("Error:", error);
  }
}
addProduct();

Client de haut niveau (DynamoDBDocumentClient)

Le client de documents DynamoDB de haut niveau offre des fonctionnalités pratiques intégrées, telles que l'élimination de la nécessité de rassembler manuellement les données et l'autorisation de lectures et d'écritures directes à l'aide d'objets standard. JavaScript La documentation de lib-dynamodb fournit la liste des avantages.

Pour instancier leDynamoDBDocumentClient, créez un niveau inférieur, DynamoDBClient puis enveloppez-le avec un. DynamoDBDocumentClient La convention de dénomination des fonctions diffère légèrement entre les deux packages. Par exemple, les utilisations de bas niveau PutItemCommand tandis que les utilisations de haut niveau. PutCommand Les noms distincts permettent aux deux ensembles de fonctions de coexister dans le même contexte, ce qui vous permet de combiner les deux dans le même script.

const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const { DynamoDBDocumentClient, PutCommand } = require("@aws-sdk/lib-dynamodb");

const client = new DynamoDBClient({});

const docClient = DynamoDBDocumentClient.from(client);

async function addProduct() {
  const params = {
    TableName: "products",
    Item: {
      id: "Product01",
      description: "Hiking Boots",
      category: "footwear",
      sku: "hiking-sku-01",
      size: 9,
    },
  };

  try {
    const data = await docClient.send(new PutCommand(params));
    console.log('result : ' + JSON.stringify(data));
  } catch (error) {
    console.error("Error:", error);
  }
}

addProduct();

Le modèle d'utilisation est cohérent lorsque vous lisez des éléments à l'aide d'opérations d'API telles que GetItemQuery, ouScan.

Utilisation de la fonction utilitaire Marshall

Vous pouvez utiliser le client de bas niveau et centraliser ou désinstaller vous-même les types de données. Le package utilitaire, util-dynamodb, possède une fonction marshall() utilitaire qui accepte le JSON et produit DynamoDB JSON, ainsi qu'une fonction qui effectue l'inverse. unmarshall() L'exemple suivant utilise le client de bas niveau avec le marshaling des données géré par l'marshall()appel.

const { DynamoDBClient, PutItemCommand } = require("@aws-sdk/client-dynamodb");
const { marshall } = require("@aws-sdk/util-dynamodb");

const client = new DynamoDBClient({});

async function addProduct() {
  const params = {
    TableName: "products",
    Item: marshall({
      id: "Product01",
      description: "Hiking Boots",
      category: "footwear",
      sku: "hiking-sku-01",
      size: 9,
    }),
  };

  try {
    const data = await client.send(new PutItemCommand(params));
  } catch (error) {
    console.error("Error:", error);
  }
}
addProduct();

Objets de lecture

Pour lire un seul élément depuis DynamoDB, vous devez utiliser GetItem l'opération API. Comme pour la PutItem commande, vous avez le choix d'utiliser le client de bas niveau ou le client Document de haut niveau. L'exemple ci-dessous montre comment utiliser le client Document de haut niveau pour récupérer un élément.

const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const { DynamoDBDocumentClient, GetCommand } = require("@aws-sdk/lib-dynamodb");

const client = new DynamoDBClient({});

const docClient = DynamoDBDocumentClient.from(client);

async function getProduct() {
  const params = {
    TableName: "products",
    Key: {
      id: "Product01",
    },
  };

  try {
    const data = await docClient.send(new GetCommand(params));
    console.log('result : ' + JSON.stringify(data));
  } catch (error) {
    console.error("Error:", error);
  }
}

getProduct();

Utilisez l'opération Query API pour lire plusieurs éléments. Vous pouvez utiliser le client de bas niveau ou le client Document. L'exemple ci-dessous utilise le client Document de haut niveau.

const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");
const {
  DynamoDBDocumentClient,
  QueryCommand,
} = require("@aws-sdk/lib-dynamodb");

const client = new DynamoDBClient({});

const docClient = DynamoDBDocumentClient.from(client);

async function productSearch() {
  const params = {
    TableName: "products",
    IndexName: "GSI1",
    KeyConditionExpression: "#category = :category and begins_with(#sku, :sku)",
    ExpressionAttributeNames: {
      "#category": "category",
      "#sku": "sku",
    },
    ExpressionAttributeValues: {
      ":category": "footwear",
      ":sku": "hiking",
    },
  };

  try {
    const data = await docClient.send(new QueryCommand(params));
    console.log('result : ' + JSON.stringify(data));
  } catch (error) {
    console.error("Error:", error);
  }
}

productSearch();

Écritures conditionnelles

Les opérations d'écriture DynamoDB peuvent spécifier une expression de condition logique qui doit être définie sur true pour que l'écriture puisse se poursuivre. Si la condition n'est pas vraie, l'opération d'écriture génère une exception. L'expression de condition peut vérifier si l'article existe déjà ou si ses attributs correspondent à certaines contraintes.

ConditionExpression = "version = :ver AND size(VideoClip) < :maxsize"

Lorsque l'expression conditionnelle échoue, vous pouvez l'utiliser ReturnValuesOnConditionCheckFailure pour demander que la réponse d'erreur inclue l'élément qui ne satisfaisait pas aux conditions afin de déduire l'origine du problème. Pour plus de détails, consultez Gérer les erreurs d'écriture conditionnelles dans les scénarios de haute simultanéité avec Amazon DynamoDB.

try {
      const response = await client.send(new PutCommand({
          TableName: "YourTableName",
          Item: item,
          ConditionExpression: "attribute_not_exists(pk)",
          ReturnValuesOnConditionCheckFailure: "ALL_OLD"
      }));
  } catch (e) {
      if (e.name === 'ConditionalCheckFailedException') {
          console.log('Item already exists:', e.Item);
      } else {
          throw e;
      }
  }

Des exemples de code supplémentaires illustrant d'autres aspects de l'utilisation du JavsScript SDK V3 sont disponibles dans la documentation du JavaScript SDK V3 et dans le référentiel DynamoDB-SDK-Examples. GitHub

Pagination

Rubriques

• Utilisation de la méthode paginateScan pratique

Les demandes de lecture telles que Scan ou Query renverront probablement plusieurs éléments dans un ensemble de données. Si vous effectuez un Scan ou Query avec un Limit paramètre, une fois que le système aura lu autant d'éléments, une réponse partielle sera envoyée et vous devrez paginer pour récupérer des éléments supplémentaires.

Le système ne lira qu'un maximum de 1 mégaoctet de données par demande. Si vous incluez une Filter expression, le système lira toujours un mégaoctet, au maximum, de données sur le disque, mais renverra les éléments de ce mégaoctet qui correspondent au filtre. L'opération de filtrage peut renvoyer 0 élément pour une page, mais nécessite tout de même une pagination supplémentaire avant que la recherche ne soit épuisée.

Vous devez rechercher LastEvaluatedKey dans la réponse et l'utiliser comme ExclusiveStartKey paramètre dans une demande ultérieure pour poursuivre la récupération des données. Cela sert de signet, comme indiqué dans l'exemple suivant.

Note

L'exemple transmet une valeur nulle lastEvaluatedKey ExclusiveStartKey lors de la première itération, ce qui est autorisé.

Exemple utilisant LastEvaluatedKey :

const { DynamoDBClient, ScanCommand } = require("@aws-sdk/client-dynamodb");

const client = new DynamoDBClient({});

async function paginatedScan() {
  let lastEvaluatedKey;
  let pageCount = 0;

  do {
    const params = {
      TableName: "products",
      ExclusiveStartKey: lastEvaluatedKey,
    };

    const response = await client.send(new ScanCommand(params));
    pageCount++;
    console.log(`Page ${pageCount}, Items:`, response.Items);
    lastEvaluatedKey = response.LastEvaluatedKey;
  } while (lastEvaluatedKey);
}

paginatedScan().catch((err) => {
  console.error(err);
});

Utilisation de la méthode paginateScan pratique

Le SDK fournit des méthodes pratiques appelées paginateScan et paginateQuery qui font cela à votre place et qui font les demandes répétées en arrière-plan. Spécifiez le nombre maximum d'éléments à lire par demande à l'aide du Limit paramètre standard.

const { DynamoDBClient, paginateScan } = require("@aws-sdk/client-dynamodb");

const client = new DynamoDBClient({});

async function paginatedScanUsingPaginator() {
  const params = {
    TableName: "products",
    Limit: 100
  };

  const paginator = paginateScan({client}, params);

  let pageCount = 0;

  for await (const page of paginator) {
    pageCount++;
    console.log(`Page ${pageCount}, Items:`, page.Items);
  }
}

paginatedScanUsingPaginator().catch((err) => {
  console.error(err);
});

Note

Il n'est pas recommandé d'effectuer régulièrement des analyses complètes du tableau, sauf si le tableau est petit.

Spécification de la configuration

Rubriques

• Config pour les délais

• Config pour keep-alive

• Config pour les nouvelles tentatives

Lors de la configuration duDynamoDBClient, vous pouvez spécifier différentes remplacements de configuration en transmettant un objet de configuration au constructeur. Par exemple, vous pouvez spécifier la région à laquelle vous connecter si le contexte d'appel ne la connaît pas déjà ou si l'URL du point de terminaison à utiliser ne la connaît pas déjà. Cela est utile si vous souhaitez cibler une instance locale de DynamoDB à des fins de développement.

const client = new DynamoDBClient({
  region: "eu-west-1",
  endpoint: "http://localhost:8000",
});

Config pour les délais

DynamoDB utilise le protocole HTTPS pour les communications client-serveur. Vous pouvez contrôler certains aspects de la couche HTTP en fournissant un NodeHttpHandler objet. Par exemple, vous pouvez ajuster les principales valeurs de délai d'expiration connectionTimeout etrequestTimeout. connectionTimeoutIl s'agit de la durée maximale, en millisecondes, pendant laquelle le client attendra en essayant d'établir une connexion avant d'abandonner.

requestTimeoutdéfinit le temps pendant lequel le client attendra une réponse après l'envoi d'une demande, également en millisecondes. La valeur par défaut pour les deux est zéro, ce qui signifie que le délai d'attente est désactivé et qu'il n'y a aucune limite quant au temps d'attente du client si la réponse n'arrive pas. Vous devez définir les délais d'attente à un niveau raisonnable afin qu'en cas de problème réseau, la demande soit erronée et qu'une nouvelle demande puisse être initiée. Par exemple :

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { NodeHttpHandler } from "@smithy/node-http-handler";

const requestHandler = new NodeHttpHandler({
  connectionTimeout: 2000,
  requestTimeout: 2000,
});

const client = new DynamoDBClient({
  requestHandler
});

Note

L'exemple fourni utilise l'import Smithy. Smithy est un langage de définition de services et de SDK, open source et maintenu par. AWS

Outre la configuration des valeurs de délai d'expiration, vous pouvez définir le nombre maximum de sockets, ce qui permet d'augmenter le nombre de connexions simultanées par origine. Le guide du développeur contient des informations détaillées sur la configuration du maxSockets paramètre.

Config pour keep-alive

Lorsque vous utilisez le protocole HTTPS, la première demande nécessite toujours une certaine back-and-forth communication pour établir une connexion sécurisée. HTTP Keep-Alive permet aux requêtes suivantes de réutiliser la connexion déjà établie, ce qui les rend plus efficaces et réduit le temps de latence. HTTP Keep-Alive est activé par défaut avec JavaScript la version 3.

Il y a une limite à la durée pendant laquelle une connexion inactive peut être maintenue en vie. Envisagez d'envoyer des demandes périodiques, peut-être toutes les minutes, si vous avez une connexion inactive mais que vous souhaitez que la prochaine demande utilise une connexion déjà établie.

Note

Notez que dans l'ancienne version V2 du SDK, keep-alive était désactivé par défaut, ce qui signifie que chaque connexion était fermée immédiatement après utilisation. Si vous utilisez la version V2, vous pouvez annuler ce paramètre.

Config pour les nouvelles tentatives

Lorsque le SDK reçoit une réponse d'erreur et que l'erreur peut être reprise comme indiqué par le SDK, par exemple une exception de limitation ou une exception de service temporaire, il réessaie. Cela se produit de manière invisible pour vous en tant qu'appelant, sauf que vous remarquerez peut-être que la demande a mis plus de temps à aboutir.

Le SDK pour JavaScript V3 effectuera 3 requêtes au total, par défaut, avant d'abandonner et de transmettre l'erreur au contexte d'appel. Vous pouvez ajuster le nombre et la fréquence de ces nouvelles tentatives.

Le DynamoDBClient constructeur accepte un maxAttempts paramètre qui limite le nombre de tentatives possibles. L'exemple ci-dessous augmente la valeur de 3 par défaut à 5 au total. Si vous le définissez sur 0 ou 1, cela indique que vous ne souhaitez pas de nouvelles tentatives automatiques et que vous souhaitez gérer vous-même les erreurs reprenant dans votre bloc catch.

const client = new DynamoDBClient({
  maxAttempts: 5,
});

Vous pouvez également contrôler le calendrier des nouvelles tentatives à l'aide d'une stratégie de relance personnalisée. Pour ce faire, importez le package util-retry utilitaire et créez une fonction de sauvegarde personnalisée qui calcule le temps d'attente entre les tentatives en fonction du nombre de tentatives actuel.

L'exemple ci-dessous indique d'effectuer un maximum de 5 tentatives avec des délais de 15, 30, 90 et 360 millisecondes en cas d'échec de la première tentative. La fonction d'annulation personnalisée calcule les délais en acceptant le numéro de nouvelle tentative (commence par 1 pour la première tentative) et renvoie le nombre de millisecondes à attendre pour cette demande. calculateRetryBackoff

const { ConfiguredRetryStrategy } = require("@aws-sdk/util-retry");

const calculateRetryBackoff = (attempt) => {
  const backoffTimes = [15, 30, 90, 360];
  return backoffTimes[attempt - 1] || 0;
};

const client = new DynamoDBClient({
  retryStrategy: new ConfiguredRetryStrategy(
    5, // max attempts.
    calculateRetryBackoff // backoff function.
  ),
});

Programmes d'attente

Le client DynamoDB inclut deux fonctions de serveur utiles qui peuvent être utilisées lors de la création, de la modification ou de la suppression de tables lorsque vous souhaitez que votre code attende jusqu'à ce que la modification des tables soit terminée. Par exemple, vous pouvez déployer une table, appeler la waitUntilTableExists fonction et le code bloquera jusqu'à ce que la table soit active. Le serveur interroge en interne le service DynamoDB toutes les 20 secondes. describe-table

import {waitUntilTableExists, waitUntilTableNotExists} from "@aws-sdk/client-dynamodb";

… <create table details>

const results = await waitUntilTableExists({client: client, maxWaitTime: 180}, {TableName: "products"});
if (results.state == 'SUCCESS') {
  return results.reason.Table
}
console.error(`${results.state} ${results.reason}`);

La waitUntilTableExists fonctionnalité ne renvoie le contrôle que lorsqu'elle peut exécuter une describe-table commande indiquant le statut ACTIF de la table. Cela garantit que vous pouvez waitUntilTableExists attendre la fin de la création, ainsi que des modifications telles que l'ajout d'un index GSI, dont l'application peut prendre un certain temps avant que la table ne revienne au statut ACTIF.

Gestion des erreurs

Dans les premiers exemples présentés ici, nous avons identifié toutes les erreurs de manière générale. Cependant, dans les applications pratiques, il est important de distinguer les différents types d'erreurs et de mettre en œuvre une gestion plus précise des erreurs.

Les réponses aux erreurs DynamoDB contiennent des métadonnées, notamment le nom de l'erreur. Vous pouvez détecter les erreurs puis les comparer aux noms de chaîne possibles des conditions d'erreur afin de déterminer la marche à suivre. Pour les erreurs côté serveur, vous pouvez utiliser l'instanceofopérateur avec les types d'erreur exportés par le @aws-sdk/client-dynamodb package pour gérer efficacement la gestion des erreurs.

Il est important de noter que ces erreurs ne se manifestent qu'une fois toutes les tentatives épuisées. Si une erreur est réessayée et est finalement suivie d'un appel réussi, du point de vue du code, il n'y a pas d'erreur, juste une latence légèrement élevée. Les nouvelles tentatives apparaîtront dans les CloudWatch graphiques Amazon sous forme de demandes infructueuses, telles que les demandes d'accélération ou d'erreur. Si le client atteint le nombre maximal de tentatives, il abandonne et génère une exception. C'est la façon dont le client dit qu'il ne va pas réessayer.

Vous trouverez ci-dessous un extrait permettant de détecter l'erreur et de prendre des mesures en fonction du type d'erreur renvoyé.

import {
  ResourceNotFoundException
  ProvisionedThroughputExceededException,
  DynamoDBServiceException,
} from "@aws-sdk/client-dynamodb";

try {
  await client.send(someCommand);
} catch (e) {
    if (e instanceof ResourceNotFoundException) {
      // Handle ResourceNotFoundException
    } else if (e instanceof ProvisionedThroughputExceededException) {
      // Handle ProvisionedThroughputExceededException
    } else if (e instanceof DynamoDBServiceException) {
      // Handle DynamoDBServiceException
    } else {
      // Other errors such as those from the SDK
      if (e.name === "TimeoutError") {
        // Handle SDK TimeoutError.
      } else {
        // Handle other errors.
      }
    }
}

Consultez le Gestion des erreurs avec DynamoDB Guide du développeur de DynamoDB pour les chaînes d'erreur les plus courantes. Les erreurs exactes possibles avec un appel d'API particulier se trouvent dans la documentation de cet appel d'API, telle que la documentation de l'API Query.

Les métadonnées des erreurs incluent des propriétés supplémentaires, en fonction de l'erreur. Pour a TimeoutError, les métadonnées incluent le nombre de tentatives effectuées ettotalRetryDelay, comme indiqué ci-dessous.

{
  "name": "TimeoutError",
  "$metadata": {
    "attempts": 3,
    "totalRetryDelay": 199
  }
}

Si vous gérez votre propre politique de nouvelles tentatives, vous devez faire la différence entre les limitations et les erreurs :

• Un accélérateur (indiqué par un ProvisionedThroughputExceededException ouThrottlingException) indique un service en bonne santé qui vous informe que vous avez dépassé votre capacité de lecture ou d'écriture sur une table ou une partition DynamoDB. Chaque milliseconde qui passe, un peu plus de capacité de lecture ou d'écriture est disponible. Vous pouvez donc réessayer rapidement, par exemple toutes les 50 ms, pour tenter d'accéder à cette capacité nouvellement libérée.

  Avec les accélérateurs, vous n'avez pas particulièrement besoin d'un ralentissement exponentiel, car les accélérateurs sont légers pour que DynamoDB les réactive et ne vous facturent aucun frais par demande. Le retard exponentiel affecte des délais plus longs aux threads clients qui ont déjà attendu le plus longtemps, ce qui étend statistiquement les p50 et p99 vers l'extérieur.

• Une erreur (indiquée par un InternalServerError ou unServiceUnavailable, entre autres) indique un problème temporaire avec le service, peut-être avec la table entière ou simplement avec la partition sur laquelle vous lisez ou sur laquelle vous écrivez. En cas d'erreur, vous pouvez faire une pause plus longue avant de réessayer, par exemple 250 ms ou 500 ms, et utiliser l'instabilité pour échelonner les nouvelles tentatives.

Journalisation

Activez la journalisation pour obtenir plus de détails sur le fonctionnement du SDK. Vous pouvez définir un paramètre sur le DynamoDBClient comme indiqué dans l'exemple ci-dessous. D'autres informations de journal apparaîtront dans la console et incluent des métadonnées telles que le code d'état et la capacité consommée. Si vous exécutez le code localement dans une fenêtre de terminal, les journaux y apparaissent. Si vous exécutez le code et que vous avez configuré Amazon CloudWatch Logs, la sortie de la console y sera écrite. AWS Lambda

const client = new DynamoDBClient({
  logger: console
});

Vous pouvez également vous connecter aux activités internes du SDK et effectuer une journalisation personnalisée lorsque certains événements se produisent. L'exemple ci-dessous utilise celui du client middlewareStack pour intercepter chaque demande au fur et à mesure qu'elle est envoyée par le SDK et l'enregistre au fur et à mesure qu'elle se produit.

const client = new DynamoDBClient({});

client.middlewareStack.add(
  (next) => async (args) => {
    console.log("Sending request from AWS SDK", { request: args.request });
    return next(args);
  },
  {
    step: "build",
    name: "log-ddb-calls",
  }
);

MiddlewareStackIl fournit un puissant crochet pour observer et contrôler le comportement du SDK. Consultez le blog Présentation de Middleware Stack in Modular AWS SDK for JavaScript pour plus d'informations.

Considérations

Lorsque vous l' AWS SDK for JavaScript implémentez dans votre projet, voici d'autres facteurs à prendre en compte.

Systèmes de modules

Le SDK prend en charge deux systèmes de modules, CommonJS et ES (ECMAScript). CommonJS utilise la require fonction, tandis que ES utilise le import mot clé.

1. JS commun — const { DynamoDBClient, PutItemCommand } = require("@aws-sdk/client-dynamodb");

2. ES (ECMAScript) — import { DynamoDBClient, PutItemCommand } from "@aws-sdk/client-dynamodb";

Le type de projet dicte le système de modules à utiliser et est spécifié dans la section type de votre fichier package.json. La valeur par défaut est CommonJS. "type": "module"À utiliser pour indiquer un projet ES. Si vous avez un projet Node.JS existant qui utilise le format de package CommonJS, vous pouvez toujours ajouter des fonctions avec la syntaxe d'importation plus moderne du SDK V3 en nommant vos fichiers de fonctions avec l'extension .mjs. Cela permettra au fichier de code d'être traité comme ES (ECMAScript).

Opérations asynchrones

Vous verrez de nombreux exemples de code utilisant des rappels et des promesses pour gérer le résultat des opérations DynamoDB. Avec la modernité, JavaScript cette complexité n'est plus nécessaire et les développeurs peuvent tirer parti de la syntaxe async/await plus succincte et plus lisible pour les opérations asynchrones.

Temps d'exécution du navigateur Web

Les développeurs Web et mobiles qui créent avec React ou React Native peuvent utiliser le SDK JavaScript dans leurs projets. Avec la version V2 antérieure du SDK, les développeurs Web devaient charger le SDK complet dans le navigateur, en faisant référence à une image du SDK hébergée sur https://sdk.amazonaws.com/js/.

Avec la V3, il est possible de regrouper uniquement les modules clients V3 requis et toutes les JavaScript fonctions requises dans un seul JavaScript fichier à l'aide de Webpack, et de l'ajouter dans une balise <head> de script dans vos pages HTML, comme expliqué dans la section Commencer à utiliser un script de navigateur de la documentation du SDK.

Opérations du plan de données DAX

Le SDK pour la JavaScript V3 ne prend actuellement pas en charge les opérations du plan de données Amazon DynamoDB Streams Accelerator (DAX). Si vous demandez le support DAX, pensez à utiliser le SDK pour la JavaScript V2 qui prend en charge les opérations du plan de données DAX.