Comment structurer vos applications sans serveur à l’aide d’une passerelle d’API partagée | de EJ Ozyazgan | janvier 2023

Le cas des piles séparées

1. What is a Shared API Gateway?
2. Why use a Shared API Gateway?
3. Implementing a Shared API Gateway
4. Deploying the Shared API Gateway
5. Conclusion

Une passerelle API partagée est lorsque plusieurs services utilisent une seule passerelle API. Ces services peuvent être des API entièrement distinctes ou, plus communément, des composants plus petits d’une API plus grande.

Les passerelles d’API partagées présentent quelques avantages. La principale consiste à diviser les grandes API en composants plus petits et plus faciles à gérer. En divisant les API plus grandes en composants plus petits, il y a beaucoup moins de surcharge lors de la mise à jour de ces composants.

Avec de grandes bases de code monolithiques, pour mettre à jour une seule fonction lambda, par exemple, l’intégralité de l’API devrait être redéployée. Cela crée des frais généraux inutiles en augmentant les temps de déploiement et la complexité.

À l’aide de passerelles d’API partagées, un seul composant peut être mis à jour et redéployé sans redéployer l’intégralité de l’API.

Un autre avantage de diviser une API en composants plus petits est la flexibilité de la sécurité des terminaux. En utilisant des API distinctes, la sécurité peut être implémentée différemment par API. Par exemple, une API d’authentification qui gère l’inscription, la confirmation par e-mail et la déconnexion n’aurait pas nécessairement besoin de points de terminaison sécurisés. Alors qu’une API utilisateur renvoyant des données utilisateur aurait besoin de points de terminaison sécurisés.

En ayant des composants séparés pour les API d’authentification et d’utilisateur, la sécurité pourrait être implémentée uniquement sur l’API utilisateur au lieu d’être inutilement implémentée sur les API utilisateur et d’authentification avec une API monolithique plus traditionnelle.

Cette mise en œuvre sera décomposée en trois volets suivants. Le référentiel de code sera fourni à la fin de l’article.

1. Shared API Gateway
2. Auth API
2. User API

Passerelle API partagée

Il s’agit du fichier principal sans serveur avec la passerelle API. L’ajout de sorties est la principale différence par rapport à une passerelle API traditionnelle. Les sorties permettent de transmettre des variables entre la passerelle d’API partagée et d’autres composants d’API. Les principales variables nécessaires aux autres composantes sont les RestApiId et RootResourceId.

service: shared-api-gateway
frameworkVersion: '3'
provider:
name: aws
runtime: nodejs16.x
region: us-east-1
resources:
Resources:
SharedAPIGateway:
Type: AWS::ApiGateway::RestApi
Properties:
Name: SharedAPIGateway
Outputs:
apiGatewayRestApiId:
Value:
Ref: SharedAPIGateway
Export:
Name: SharedAPIGateway-restApiId
apiGatewayRestApiRootResourceId:
Value:
Fn::GetAtt:
- SharedAPIGateway
- RootResourceId
Export:
Name: SharedAPIGateway-rootResourceId

API d’authentification

Il s’agit d’un exemple de composant pour une API d’authentification qui pourrait faire partie d’une API plus large. Par rapport à une implémentation lambda sans serveur traditionnelle, la principale différence est de passer le RestApiId et RootResourceId au sein du prestataire. Cela se fait à l’aide du apiGateway paramètre.

service: shared-api-gateway-auth
provider:
name: aws
runtime: nodejs16.x
region: us-east-1
apiGateway:
restApiId:
"Fn::ImportValue": SharedAPIGateway-restApiId
restApiRootResourceId:
"Fn::ImportValue": SharedAPIGateway-rootResourceId
httpApi:
cors: true
disableDefaultEndpoint: true
functions:
signUp:
handler: authHandler.signUp
events:
- http:
path: auth/sign-up
method: post
signIn:
handler: authHandler.signIn
events:
- http:
path: auth/sign-in
method: post
confirmEmail:
handler: authHandler.confirmEmail
events:
- http:
path: auth/confirm-email
method: post

API utilisateur

Comme pour l’API d’authentification, il s’agit d’un exemple de composant pour une API utilisateur qui pourrait faire partie d’une API plus large. Cette implémentation est la même que l’API d’authentification concernant la transmission du RestApiId et RootResourceId au sein du fournisseur en utilisant le apiGateway paramètre.

service: shared-api-gateway-user
provider:
name: aws
runtime: nodejs16.x
region: us-east-1
apiGateway:
restApiId:
"Fn::ImportValue": SharedAPIGateway-restApiId
restApiRootResourceId:
"Fn::ImportValue": SharedAPIGateway-rootResourceId
httpApi:
cors: true
disableDefaultEndpoint: true
functions:
getUser:
handler: userHandler.getUser
events:
- http:
path: user/get-user
method: getDeploying the Sahred API Gateway

Un déploiement sans serveur standard peut être utilisé pour déployer la passerelle d’API partagée et d’autres composants d’API. La passerelle d’API partagée doit être déployée en premier, dans un premier temps. Cependant, seul le composant modifié doit être déployé pour les déploiements futurs.

Déployez à l’aide de la commande sans serveur suivante, serverless deploydans le répertoire respectif de l’API en cours de déploiement (passerelle partagée ou composants).

Dans le référentiel fourni, un script de déploiement déploiera la passerelle partagée avec les composants d’authentification et d’utilisateur.

Les passerelles d’API partagées sont un excellent moyen de diviser des API plus volumineuses en composants plus petits et de rationaliser le développement et la maintenance.

J’espère que cet article a été une bonne introduction aux avantages et aux possibilités offerts par les passerelles d’API partagées. Comme mentionné, le code complet de cette implémentation peut être trouvé ci-dessous.

Restez à l’écoute pour plus d’articles concernant la mise en œuvre de la sécurité dans les passerelles d’API partagées.