Pour faire suite à mon post précédent introduisant le déploiement d’une application Laravel Serverless en quelques minutes avec Bref, je vais maintenant poursuivre en vous montrant comment stocker vos sessions dans DynamoDB.

Le code de mon précédent post est visible ici : https://github.com/pmayet/laravel-lambda-5min/tree/master

Configuration

On repart donc du master.

On va d’abord ajouter le AWS SDK PHP, qui contient notamment les class permettant de manipuler des données au sein de DynamoDB.

Ensuite, dans la config du cachestore DynamoDB, on va ajouter une ligne de config pour le token qui est hérité par la Lambda.

En effet, le store utilisé pour les sessions dans Laravel, se base sur le cachestore, au même principe que si on utilisait Redis.

Et pour finir, la configuration de DynamoDB.

D’abord, on donne les permissions à la Lambda les droits de lecture/écriture à notre table DynamoDB.

Et on indique le SESSION_DRIVER, le CACHE_DRIVER, le CACHE_STORE et enfin le nom de la table DynamoDB.

Ensuite, pour les besoins de la démo, on provisionne notre table DynamoDB par le biais du serverless.yml. En environnement de Production, je vous conseille plutôt de faire le provisionning de vos ressources de ce type via Terraform, CloudFormation ou autre.

Enfin, pour montrer le bon fonctionnement, on modifie la vue utilisée par notre route pour indiquer le datetime courant ainsi que le session ID et vérifier ainsi le bon fonctionnement.

Le code est accessible ici : https://github.com/pmayet/laravel-lambda-5min/tree/dynamodb-session

Le résultat est visible ici : https://3c3fygo941.execute-api.eu-west-1.amazonaws.com/

Vous verrez alors un enregistrement par session dans votre table DynamoDB

Dans la description de notre ressource DynamoDB, vous verrez la définition d’un TTL, ce qui permet à DynamoDB de supprimer de manière automatique l’enregistrement après l’expiration du timestamp. Dans les faits cela se fait 5 à 10 min après. En activant le stream, cela nous fera un nouveau cas d’usage dans un futur post, comme par exemple déterminer le nombre de users connectés en simultané.

Conclusion

Point d’importance avant de stocker les sessions dans DynamoDB dans un environnement de Production, pensez bien à stresser votre application afin de déterminer comme il faut le provisionning de votre table DynamoDB en configurant le ReadCapacity et le WriteCapacity, bien sûr vous pouvez appliquer de l’autoscaling, mais sur des sessions, le temps de l’autoscale risque d’être problématique.

Je vous propose de poursuivre mes posts sur les sujets suivants :

• Traitements de queue SQS au sein de la même application
• Traitements de queue SQS entre applications tierces (micro-services)
• Gérer des évènements asynchrones avec un délai supérieur à 15min (limite de SQS)
• Déploiement via Gitlab CI
• Analyse d’email via SES
• Gestion des migrations de base de données
• Connexion à RDS
• Indexation Elastic en asynchrone via Laravel Scout

N’hésitez pas à m’indiquer quels cas d’architecture vous souhaiteriez que j’aborde.

A vos commentaires et critiques !