mail

L'API Gateway d'AWS propose un modèle pour interagir avec des clients à travers des websockets. Cet article décrit une application exemple qui fournit 2 lambda en Go: la première interagit avec les clients connectés en websocket et maintien les informations de connexion dans dynamodb ; l'autre permet d'envoyer un message à tous les clients qui sont connectés. L'application propose également un ensemble de manifests terraform pour créer toutes les ressources...

TL;DR: le projet complet est disponible sur carnage-sh/lambda-go-websocket. Il contient tout le nécessaire pour créer un exemple complet et fonctionnel.

Généralités

Le projet et constitué des ressources ci-dessous :

architecture

Les composants principaux sont :

  • Une table dynamodb database qui stocke les utilisateurs connectés à l'aide de websocket ainsi que les canaux associés
  • La section RX en haut du schéma est constituée d'une API Gateway qui gère les websockets ainsi que la logique associée implémentée dans une lambda Go
  • La section HTTP est constituée d'une API Gateway qui gère les interactions avec un utilisateurs privilégié qui peut envoyer des messages sur toutes les websockets ouvertes.

Manifests Terraform

Les ressources AWS peuvent être créées avec terraform et les manifests associés sont situées dans le répertoire terraform, Pour les appliquer, cela suppose que vous ayez configuré les fichiers provider.tf et variables.tf selon vos besoins :

  • vérifiez que la région AWS est bien dans le fichier provider.tf
  • vérifiez variables.tf et modifiez les valeurs de variables selon vos besoins :

    • lambda_table nomme la table dynamodb qui sera utilisée
    • rx et http nomme les Gateways API et les lambda selon les sections du schéma
    • rx_artifact et http_artifact nomme les artefacts Go qui seront utilisés comme fonctions

Le fichier Makefile à la racine du projet génère les artefacts lorsque vous lancez un simple make. Ils sont stockés dans le réperoire terraform/bin. De plus:

  • data.tf contient les data utilisées dans les autres manifests
  • dynamo.tf contient la table dynamodb un index et la policy associée
  • rx-apigw.tf et rx-lambda.tf contiennent l'API Gateway et la lambda associée à la section RX
  • http-apigw.tf et http-lambda.tf contiennent l'API Gateway et la lambda associée à la section HTTP

Pour utiliser le projet, construisez les artefacts avec la commande make puis déployez-les à l'aide de la commande terraform apply. Les manifests contiennent 2 outputs:

  • wscat fournit la syntaxe wscat pour interagir avec la section RX du projet qui offre un service de type echo
  • curl fournit un exemple de commande curl qui permet d'interagir avec les websockets établies, c'est à dire qui sont ouvertes, par exemple avec la commande wscat lancé et ouverte dans une autre session.

Le code

Le code GO permet de créer 2 artefacts séparés :

  • ws-linux-amd64 est construit à partir de cmd/websocket et gère l'API Gateway et . Il gère les connexions dans la table dynamodb. Il retourne également tout message envoyé sur la websocket pour agit comme un service echo
  • http-linux-amd64 est construit à partir de cmd/http. Lorsqu'ill reçoit un message envoyé avec un POST http, il liste les connexions établies dans la table dynamodb et envoie le message sur toutes les websockets.

Le Go code est situé dans le répertoire racine du projet :

  • dynamodb.go fournit le code qui interagit avec la table dynamodb
  • events.go fournit les réponses type pour les lambda
  • handlers.go fournit les codes qui gèrent les réponses aux appels

Pour continuer

Le projet offre des blocs de base pour utiliser des websocket dans un projet serverless avec Go, des lambda AWS et dynamodb. Il peut servir pour de nombreux cas d'usage. Si vous avez une quelconque difficultée, n'hésitez pas à ouvrir une issue.