Comment nous avons créé une application Web sans serveur pour la console Stax

Cet article a été initialement publié sur le site Web de Stax .

Construire une console Web pour un produit aussi complexe que Stax a présenté un certain nombre de défis. Notre plate-forme sans serveur API-first offre une gamme diversifiée de fonctionnalités pour les entreprises qui souhaitent gérer et optimiser leur écosystème AWS.

Avec une telle base axée sur les développeurs, nous devions fournir aux clients une application Web performante et réactive, avec une expérience utilisateur intuitive qui ne cache pas la puissance et les fonctionnalités de notre API. L'accès aux données via notre console devait également être conçu selon le même niveau élevé de sécurité et de conformité que le reste de notre produit.

Cet article couvrira ce que nous avons entrepris de réaliser lors de la construction de la console Stax, notre expérience de la construction d'un serveur sans serveur GraphQL API pour l'alimenter, et les leçons que nous avons apprises en cours de route.

Serverless by Design

Nous voulions produire une solution sans serveur dès le départ, pour correspondre à l'architecture que nous utilisons pour le reste du produit. L'un des plus grands avantages que nous ayons constatés en optant pour les architectures sans serveur chez Stax est la disponibilité et la fiabilité. Éviter de compter sur un serveur qui peut devenir un point de défaillance unique nous permet de respecter notre accord de niveau de service et de garantir que les clients peuvent accéder à la plate-forme pendant les périodes de pointe. L'utilisation de AWS Lambda signifie que les requêtes de notre front-end évoluent horizontalement et il y a toujours suffisamment de ressources de calcul pour traiter les demandes.

L'utilisation de produits sans serveur améliore également la sécurité pendant le développement, car des services comme AWS Lambda fournissent une intégration conformité et niveaux de service prêts à l'emploi. Permettre à Amazon de gérer les mises à niveau et les correctifs de l'infrastructure sur laquelle s'exécute notre code nous permet de nous concentrer sur la création de logiciels plutôt que sur la gestion du matériel.

La surcharge minimale de l'infrastructure lors du passage sans serveur a permis à notre équipe de s'approprier pleinement le déploiement et la surveillance de notre API GraphQL. Par exemple, les développeurs peuvent ajouter de nouvelles fonctionnalités Networks en utilisant des fonctions Lambda distinctes à celles utilisées pour récupérer les données de compte, minimisant ainsi le rayon d'explosion de pousser une nouvelle modification à la production.

Early Days

La première itération de notre console avait une architecture Web assez traditionnelle. Une application à page unique (SPA) React appelée directement API REST Stax, qui est une solution sans serveur utilisant AWS API Gateway et AWS Lambda devant une base de données relationnelle. AWS Cognito gère l'authentification et la connexion des utilisateurs pour la console et l'API REST.

Nous avons rencontré quelques problèmes techniques avec cette approche:

1. Tooling . Les frameworks frontaux modernes évoluent rapidement. La consommation des données des API REST avec React était complexe et il était difficile de gérer l'état.
2. Stabilité . Le couplage étroit de notre SPA frontal à l'API REST back-end était efficace, mais le contrat entre les systèmes changeait constamment à mesure que des fonctionnalités se développaient, ce qui risquait de casser notre interface utilisateur.
3. Mises à jour en temps réel . Nous aurions besoin de créer notre propre implémentation WebSocket pour pousser les données vers notre SPA frontal afin de fournir des mises à jour en temps réel. Cela aurait été complexe à implémenter à la fois dans le front-end et le back-end.

Il est également devenu évident qu'au fur et à mesure que Stax se développait en tant que produit, la console devait s'intégrer à d'autres services back-end que notre API REST, tels que les données de coût et de conformité pour les comptes et notre service de support client. L'interfaçage avec plusieurs API et protocoles, tous avec des mécanismes d'authentification différents, nous a conduit à envisager un modèle Back End pour Front End avec une seule API GraphQL.

Our Console Architecture Now

L'architecture se concentre sur une couche API GraphQL qui agit comme un proxy entre nos services frontaux et back-end. GraphQL est un langage de requête pour les API; il permet aux développeurs de définir les types de données dans un système (le schéma) et de câbler des fonctions pour récupérer des données à partir de différentes sources (résolveurs). Les relations entre les données peuvent être développées dans une seule requête GraphQL. Par exemple, une seule requête peut résoudre une Stax Workload et l'utilisateur qui l'a déployée en une seule fois.

Une des principales raisons pour lesquelles GraphQL a répondu à nos besoins est que les données peuvent être extraites de n'importe quelle source par un résolveur et être présenté à un frontal comme une interface unique. Cela signifie qu'à mesure que Stax se développe, nous pouvons refactoriser et optimiser les services back-end avec un impact minimal pour nos développeurs front-end et nos clients. L'authentification est également massivement simplifiée. Le front-end s'authentifie auprès de notre API GraphQL en un seul endroit, qui gère les connexions à diverses API REST et GraphQL et à des sources d'événements dans les coulisses.

Chez Stax, nous sommes étroitement associés à AWS et essayons d'utiliser des solutions AWS natives dans la mesure du possible dans le cadre de notre philosophie de développement. Nous avons choisi d'utiliser AWS AppSync une implémentation GraphQL sans serveur entièrement gérée comme cœur de notre service.

AWS AppSync implémente les principales directives GraphQL, y compris les abonnements GraphQL qui gèrent les connexions WebSocket entre les clients et votre API GraphQL . AWS Lambda récupère et transforme les données dans les fonctions de résolution GraphQL, AWS DynamoDB est utilisé pour les magasins de données sans serveur et AWS EventBridge déclenche les fonctions Lambda en réponse aux événements système.

Construit avec Stax

Stax est un produit basé sur l'API, nous avons donc exploité l'API Stax REST disponible publiquement pour créer la majorité des console client. En consommant ( dogfooding vraiment) notre propre API REST signifie que nous pouvons tester les fonctionnalités et améliorer notre documentation avant que la fonctionnalité ne soit mise à disposition des clients, agissant comme notre propre contrôle qualité. Avoir une API GraphQL qui proxy notre back-end nous permet également d'introduire de nouvelles fonctionnalités dans la console avant qu'elles ne soient rendues publiques aux clients dans l'API Stax REST. Nous pouvons simplement le connecter à AppSync et l'ajouter dans la console en tant que fonctionnalité «bêta».

Notre API GraphQL communique avec le back-end Stax en partageant les informations d'authentification d'AWS Cognito entre les services. Cela garantit que les données utilisateur restent strictement séparées par l'organisation d'un client à chaque étape du processus et maintient une piste d'audit liée à l'utilisateur spécifique qui a lancé une action. Le fait d'avoir une seule API GraphQL pour notre frontal nous permet également d'appliquer le contrôle d'accès basé sur les rôles ce qui signifie que nous pouvons appliquer des restrictions pour les actions des utilisateurs en fonction de leur rôle au niveau de la requête.

L'API AppSync est également connecté au bus d'événements Stax pour écouter les événements système générés par les services back-end, comme le statut des étapes de configuration de compte individuel ). Nous utilisons GraphQL Subscriptions pour améliorer les fonctionnalités fournies par le bus d'événements Stax et envoyer les mises à jour vers la console sans que les clients aient besoin d'actualiser leur page.

Embracing the Limitations

L'authentification pose souvent un défi avec le sans serveur architectures, car les informations d'authentification des utilisateurs doivent être partagées avec chaque service ou API impliqué dans la satisfaction d'une demande. Une seule requête GraphQL peut entraîner l'appel de plusieurs services en aval, par exemple, pour afficher un réseau, le compte dans lequel il est déployé et l'utilisateur qui l'a créé.

AWS AppSync facilite l'abstraction de l'authentification par en utilisant AppSync Pipeline Resolvers mais il est toujours important de garantir que les appels aux services avec des limites de débit strictes comme AWS Cognito sont minimisés. Nous avons abordé cela en faisant abstraction des interactions avec Cognito dans un service dédié, mais il est possible d'améliorer cela avec la mise en cache.

En tant qu'offre de produit relativement nouvelle, AWS AppSync présentait quelques limitations dans son implémentation GraphQL que nous devions surmonter. AppSync impose un délai d'expiration strict de 30 secondes pour toutes les requêtes, ce qui signifie que les grandes listes paginées de données avec des relations imbriquées doivent être traitées avec soin. AppSync permet également le traitement par lots des fonctions Lambda lorsqu'il s'agit de relations un-à-plusieurs, mais a actuellement une limite de lot de 5, ce qui est trop faible pour être utile en pratique. Le déploiement de notre propre implémentation GraphQL nous aurait permis d'éviter ces problèmes, mais les avantages de l'utilisation d'une solution sans serveur entièrement gérée l'emportaient sur les points faibles.

Étapes suivantes

L'avenir de notre API GraphQL se concentrera sur l'amélioration des performances grâce à la mise en cache des données et sur l'extension des mises à jour en temps réel à tous les composants Stax. La mise en cache des données permettra aux clients de gérer leurs environnements Stax et d'afficher les données même lorsque les services en aval ne sont pas disponibles.

Au fur et à mesure que la plate-forme Stax continue d'évoluer, nous continuerons d'ajouter de nouvelles fonctionnalités à notre console, afin de rendre la tâche aussi simple que possible. votre organisation pour gérer tous les aspects de son écosystème AWS à partir d'un seul endroit. Mais comme nous utilisons une approche sans serveur, nous n'avons pas besoin de consacrer des efforts à la maintenance des serveurs. Au lieu de cela, nous pouvons nous concentrer sur la création d'expériences plus étonnantes pour nos clients tout en restant sécurisés et conformes, même si la plate-forme devient de plus en plus sophistiquée.

Si vous souhaitez en savoir plus sur Stax et comment il pourrait s'intègre dans l'écosystème AWS de votre organisation, contactez-nous et nous organiserons une démonstration .