Intégration Lambda vs Proxy Lambda: Avantages et inconvénients
Selon vous, quels sont les avantages et les inconvénients de l'utilisation de l'intégration Lambda avec et sans la fonctionnalité de proxy dans AWS API Gateway (et plus précisément, lors de l'utilisation de la structure sans serveur)? Voici ce que je pense jusqu'à présent:
Intégration Lambda avec Proxy
- Pro : On peut rapidement prototyper et coder sans se soucier de tous les détails de configuration nécessaires (et réinventer quelques roues comme les mappages de modèles génériques, etc.).
- Pro : Il est très facile de renvoyer n'importe quel code d'état et en-têtes personnalisés, tout en offrant un moyen générique de lire le corps, les en-têtes, les paramètres de la demande.
- Con : Tout est fait dans le code, la génération automatique de la documentation est donc un peu plus difficile. Les dépendances (en-têtes, modèles, codes d’état retournés) sont "masquées" dans le code.
Intégration Lambda sans proxy
- Con : implique beaucoup de travail pour la configurer et cette configuration peut être dupliquée dans différentes ressources.
- Pro : Il permet de découpler ce que le lambda reçoit et renvoie, et comment il est mappé sur différents codes de statut HTTP, en-têtes et charges utiles.
- Pro : Très utile car il indique à l’avance ce qu’il retourne et ce qu’il a besoin en termes d’en-têtes et de charges utiles.
- Pro : Le travail acharné lors de la configuration de tout est utile à long terme, car tout peut être exporté vers Swagger, ce qui permet aux autres utilisateurs de l'utiliser pour générer différents SDK.
Quelles sont vos pensées? Utilisez-vous généralement des intégrations Lambda Proxy ou Lambda? Que préférez-vous et pourquoi?
EDIT: Jusqu'à présent, je suis enclin à toujours choisir de ne pas utiliser les fonctions de proxy pour les raisons évoquées (découplage et énonciation de dépendances - en-têtes, codes d'état, etc.).
Pas de proxy.
J'ai plusieurs déploiements SLS en production, certains générant des revenus, d'autres en tant qu'outils internes. Je n'utilise exclusivement aucun proxy. Je ne veux pas compter sur les structures d'AWS pour mon application. Par conséquent, si nous cessons d'être des amis, je peux migrer sans trop de peine.
En ce qui concerne les avantages de la procuration, je les considérerais comme des inconvénients, car ils estiment que vous en avez aussi, et comme un avantage. J'ai tout vu auparavant "on bouge super vite". Oui, nous devons être agiles et agir rapidement, mais pas au détriment de la réflexion. Cela arrive tout le temps à mes ingénieurs, c’est une chose d’être peu documenté/concepteur, c’est dire un peu moins que de dire: «La planification laisse à désirer, il suffit de coder». C’est comme ça que vous vous retrouvez, peu importe à quelle vitesse vous arrivez sur le marché. En l'absence de proxy (et d'une planification précoce de la structure de votre projet et peut-être d'une bonne idée de DDD), il est assez simple de migrer hors d'AWS si le monde brûlait.
De plus, il m'est très difficile de familiariser de nouveaux corps avec AWS. Une fois que vous savez que tout est joué, mais les développeurs sont des développeurs, pas des ingénieurs en infrastructure (ceux d'entre nous qui faisons les deux sont étonnamment rares). Abstraire aide les gens à être productifs au début de leur difficile parcours en bas du rabithole. Je préfère mon code de codeur que le besoin de me déranger à propos de CFN toutes les 20 minutes.
Il semble que AWS recommande de choisir Lambda Proxy Integration pour le développement de nouvelles API .
Remarque
L'intégration personnalisée Lambda, anciennement appelée intégration Lambda, est une technologie héritée. Nous vous recommandons d'utiliser l'intégration du proxy Lambda pour toute nouvelle API. Pour plus d'informations, voir Créer une API de passerelle d'API avec l'intégration du proxy Lambda.
Je comprends qu'il est beaucoup "plus rapide" (à court terme) de créer un noeud final d'API et une intégration lambda à l'aide d'une intégration proxy plutôt que d'une intégration personnalisée, mais je suis surpris que ce soit la recommandation pour tous Développement API/Lambda:
- J'ai imaginé API Gateway comme étant responsable du traitement des "détails HTTP". L'utilisation de l'intégration proxy force (au moins un sous-ensemble de) cette responsabilité sur la fonction Lambda. (savoir interpréter et décider des en-têtes HTTP, des paramètres de requête, des codes d’état, etc.)
- En faisant cela, j’ai le sentiment qu’il confondu relève de la responsabilité de la fonction Lambda de support - Lambda doit à la fois gérer la logique "métier" à laquelle il est appelé et interpréter les valeurs HTTP entrantes et décidez des valeurs de réponse HTTP sortantes.
- Cela dit, vous pouvez implémenter une couche de fonction Lambda supplémentaire pour extraire les détails HTTP, mais n’est-ce pas ce que l’API Gateway est censée faire?
- Cela réduit la possibilité de réutiliser une fonction Lambda donnée dans un contexte autre que le traitement des demandes HTTP, à moins que des clients non HTTP ne formulent la demande comme s'il s'agissait d'une demande HTTP.
Nous avons également commencé avec Proxy, car il était très rapide de disposer de nombreuses fonctions. Nous nous sommes vite rendu compte que nous avions créé un couplage assez étroit avec la façon dont le proxy nous oblige à lire et écrire des entrées et que notre fonction ne devrait pas en être informée et devrait avoir des interfaces plus claires et plus simples. Et ensuite, nous voulions commencer à orchestrer quelques-unes de ces fonctions avec AWS Step Functions et nous nous sommes rendus compte que nous avions créé des fonctions qui ne fonctionnaient réellement qu'avec l'intégration de proxy . Pas avec Step Functions, et ils ne sont certainement pas facilement migrés.
Plus de proxy.