Test local d'une API sans serveur (API Gateway et Lambda) —

Cet article s'adresse à toute personne ayant des difficultés à tester les services cloud localement, et en particulier aux personnes souhaitant tester localement une API qui utilise API Gateway et Lambda, avec le framework Serverless, sur AWS. Une fois, j'avais désespérément besoin de ces connaissances et mon collègue Joseph Jaffe m'a aidé à mettre cette solution en place.

Une solution API très populaire et rapide utilise Serverless avec API Gateway et Lambda. Si vous ne l'avez jamais fait auparavant, vous pouvez en savoir plus ici. Si vous avez déjà de l'expérience et que vous cherchez des moyens créatifs de tester localement, continuez à lire. Bonus si vous aimez 🌮🌮 !

Le problème

Lors de la configuration d'une API à l'aide du framework Serverless, il y a des choix importants à faire. Certains sont extrêmement importants : ils peuvent vous faciliter la vie lorsque vous créez votre API, ou vous causer d'énormes maux de tête à l'avenir. Par exemple, lorsque j'ai démarré mon API pour la première fois, je configurais chaque point de terminaison dans son propre dossier de projet Serverless. Ainsi, chaque point de terminaison avait des URL uniques. C'est une mauvaise pratique pour une solution API qui a besoin d'une URL de base avec plusieurs points de service. Nous avons modifié la solution pour que tous les points de terminaison soient dans le même projet sans serveur, ce qui nous a permis d'utiliser un aspect pratique supplémentaire de Lambda : les couches. Les couches Lambda sont un moyen de partager du code entre les points de terminaison d'API, réduisant ainsi la quantité de code répété dans le projet d'API. Vous pouvez lire en savoir plus sur les couches Lambda icimais je m'éloigne du sujet. Revenons au problème : les tests locaux !

Lorsque vous créez un nouveau point de terminaison d'API, vous devez déployer l'intégralité de l'API pour inclure la nouvelle ressource dans API Gateway et obtenir l'URL correspondante. Une fois cela fait, vous pouvez déployer des ressources individuelles.

Le déploiement pour Serverless prend du temps. Beaucoup de temps. Par exemple, consultez ces temps de déploiement moyens pour l'un de nos derniers projets :

• Déploiement d'un seul point de terminaison : ~7 secondes 🙂
• Déploiement de l'API complète (~12 ressources) : ~24 secondes 😔
• Déploiement des couches (2 couches) : ~32 secondes 💀

Bien que ces temps ne semblent pas trop mauvais à première vue, imaginez essayer de tester rapidement et de manière itérative les modifications dans votre API. Avoir chaque déploiement de plus d'une minute est une énorme perte de temps et tuera votre élan. Étendez cela sur des semaines de développement et vous comprendrez pourquoi nous avons tous besoin d'une solution pour tester les fonctions Lambda localement.

Notre solution

Afin d'éliminer rapidement les erreurs évidentes, nous avons besoin de tests locaux. Afin de tester localement, nous avons constaté que serverless invoke local nous permet de le faire de la manière la plus simple. Cela nous permet non seulement d'exécuter des scripts Lambda localement, mais nous pouvons également ajouter des points d'arrêt à l'aide du mode de débogage dans Visual Studio Code. Si vous n'avez jamais joué avec, Le mode de débogage dans VSC est vraiment utile.

L'aspect le plus important des tests locaux est la rétroaction instantanée. Plus besoin d'attendre que des couches, des fonctions ou des API entières soient déployées ! Des tonnes de temps économisé lors de la construction initiale et votre (patience ainsi que votre) directeur de programme vous aimera pour cela !

Données

Le dernier projet d'API sans serveur sur lequel nous avons travaillé a stocké toutes les données dans des fichiers JSON hébergés sur AWS seaux S3. Vous pouvez lire les données à partir d'une base de données, vous devez donc vous assurer que vous pouvez toujours accéder aux données tout en exécutant localement. Une façon serait de configurer la base de données localement sur votre machine. En fin de compte, chaque projet est unique et vous oblige à penser de manière créative pour une solution qui répond à vos besoins.

Environment Variables

Afin que nous sachions si nous fonctionnons localement ou non, nous avons créé une variable d'environnement à transmettre notre invocation locale. La variable est nommée LOCAL_DEV et est utilisée pour vérifier si nous devons charger les données depuis S3 ou depuis un dossier du système de fichiers local, comme ceci :

const data =
  process.env.LOCAL_DEV === "true"
  ? exiger(`./data/tacos.json`)
  : //gérer le chargement/définir les données comme vous le feriez régulièrement

Notez ci-dessus que la valeur booléenne de true est entre guillemets. Les variables d'environnement apparaissent toujours sous forme de chaînes, alors soyez prêt à gérer cette réalité.

Nous avons un instantané des données stockées sur S3 sur nos ordinateurs locaux, donc lorsque nous sommes en mode de développement local, nous utilisons ces données locales. afin d'exécuter et de tester le code localement.

De plus, si vous utilisez des couches dans Lambda, vous devrez pointer directement sur le code au lieu de vous y référer par son nom, en haut de votre fichier Lambda :[19659027]const apiCommon = process.env.LOCAL_DEV === "true"
? exiger("../layers/apicommon/nodejs/node_modules/apicommon/index")
: require("apicommon");

Invocation locale

Une fois que tout le code est en place pour permettre à la fonction Lambda de s'exécuter correctement localement, vous pouvez essayer d'appeler la fonction. Voici un exemple d'invocation d'un point de terminaison appelé tacos (🌮🌮) qui obtient tous les tacos d'une API alimentaire. Parce que je ❤️ 🌮🌮. Le code de cet exemple peut être trouvé sur Github.

Ceci est copié et collé à partir d'un raccourci de commande que j'ai défini dans mon fichier package.json. Cette commande nécessite que vous mettiez des marqueurs littéraux devant tous les guillemets. Voici cette commande de package.json dans son intégralité :

"scripts": {
"local-tacos": "serverless invoke local --function tacos --data '{ "queryStringParameters": {"type": "breakfast", "filling1": "egg", "filling2": "bacon", "filling3": "fromage", "tortilla": "farine", "salsa": "Salsa Doña"}} ' -e LOCAL_DEV=true > output.json"
}

Ok, regardons maintenant cette commande et ce que fait chaque partie. Je supprime tous les marqueurs littéraux pour une lisibilité plus facile. ": "bacon", "filling3": "fromage", "tortilla": "farine", "salsa": "Salsa Doña"}}' -e LOCAL_DEV=true > output.json

Tout d'abord, la partie de base :

serverless invoke local --function tacos

L'élément ci-dessus dit d'invoquer localement le point de terminaison de l'API "tacos" (local 🌮🌮 sont les meilleurs, n'est-ce pas ?) qui obtient un ensemble de tacos filtrés par les paramètres de la chaîne de requête vous l'envoyez. Ensuite, examinons la deuxième partie.

--data '{ "queryStringParameters": {"type": "breakfast", "filling1": "egg", "filling2": "bacon", "filling3": "cheese", "tortilla": "farine", "salsa": "Salsa Doña"}}'

C'est ici que nous pouvons définir les paramètres de chaîne de requête que nous transmettons au point de terminaison de l'API. Pour cet exemple, nous passons au point de terminaison de l'API tous les attributs qui décrivent le ou les tacos que nous recherchons. Dans notre cas, nous recherchons des tacos aux œufs, au bacon et au fromage sur une tortilla à la farine avec de la Salsa Doña.

Note : Toute hypothèse quant à l'endroit où se trouve le taco décrit ci-dessus (avec Salsa Doña) peut être trouvé à Austin, Texas, États-Unis? Si vous le savez, veuillez répondre dans les commentaires !

Si vous avez besoin de tester un tas de paramètres, vous pouvez les enregistrer dans un ou plusieurs fichiers testing/query.json afin de pouvoir faire quelque chose comme :

yarn local-taco query-success fil local-taco query-fail

Cela pourrait être un bon début pour un environnement de test API!

La troisième partie de l'appel sert à définir les variables d'environnement.

-e LOCAL_DEV=true

Cela indique très clairement à notre code Lambda que nous exécutons cette fonction localement et pour nous en assurer et nous y préparer en extrayant également toutes les ressources localement.

Enfin, je redirige les résultats. dans un fichier JSON.

> output.json

À partir de là, je peux facilement vérifier si les résultats sont corrects ou si une erreur a été renvoyée.

Conclusion

Cela résume! Si vous n'avez pas vu le lien plus tôt, j'ai un exemple de projet écrit que vous pouvez essayer par vous-même, en utilisant le framework Serverless, la passerelle API des services AWS et Lambda.

Aussi, si vous avez des idées sur la façon d'améliorer cette solution, ou d'autres solutions alternatives, j'aimerais entendre vos commentaires/conseils/expériences dans les commentaires ci-dessous.

Autres lectures sur Smashing Magazine

🎧 Bonus  : Smashing Podcast Episode 22 With Chris Coyier : What Is Serverless ? (animé par Drew McLellan)

(vf, yk, il)