Modifier

Partager via

Serveurs principaux pour le modèle Frontends

Azure

Dissociez les services principaux des implémentations front-end pour adapter les expériences pour différentes interfaces clientes. Ce modèle est utile lorsque vous souhaitez éviter de personnaliser un back-end qui sert plusieurs interfaces. Ce modèle est basé sur Pattern : Backends For Frontends décrit par Sam Newman.

Contexte et problème

Considérez une application initialement conçue avec une interface utilisateur web de bureau et un service back-end correspondant. À mesure que les exigences métier ont changé au fil du temps, une interface mobile a été ajoutée. Les deux interfaces interagissent avec le même service principal, mais les fonctionnalités d’un appareil mobile diffèrent considérablement d’un navigateur de bureau, en termes de taille d’écran, de performances et de limitations d’affichage.

diagramme architectural montrant le contexte et le problème des back-ends pour les modèles Frontends.

Le service back-end fait souvent face à des demandes concurrentes provenant de différents serveurs frontaux, ce qui entraîne des changements fréquents et des goulots d’étranglement potentiels dans le processus de développement. Les mises à jour conflictuelles et la nécessité de maintenir la compatibilité entraînent un travail excessif sur une ressource déployable unique.

Avoir une équipe distincte gérer le service back-end peut créer une déconnexion entre les équipes frontend et back-end, ce qui entraîne des retards dans l’obtention d’un consensus et d’exigences d’équilibrage. Par exemple, les modifications demandées par une équipe front-end doivent être validées avec d’autres équipes frontend avant l’intégration.

Solution

Introduisez une nouvelle couche qui gère uniquement les exigences spécifiques à l’interface. Cette couche appelée service backend-for-frontend (BFF), se trouve entre le client frontal et le service back-end. Si l’application prend en charge plusieurs interfaces, créez un service BFF pour chaque interface. Par exemple, si vous disposez d’une interface web et d’une application mobile, vous créez des services BFF distincts pour chacun d’eux.

Ce modèle adapte l’expérience client pour une interface spécifique, sans affecter d’autres interfaces. Il ajuste également les performances au mieux aux besoins de l’environnement front-end. Étant donné que chaque service BFF est plus petit et moins complexe, l’application peut bénéficier d’avantages d’optimisation à un certain degré.

Les équipes frontales disposent d’une autonomie sur leur propre service BFF, ce qui permet une flexibilité dans la sélection du langage, la cadence de publication, la hiérarchisation des charges de travail et l’intégration des fonctionnalités sans compter sur une équipe de développement back-end centralisée.

Bien que de nombreuses fonctions BFF s’appuient sur des API REST, les implémentations GraphQL deviennent une alternative, ce qui supprime la nécessité de la couche BFF, car le mécanisme d’interrogation ne nécessite pas de point de terminaison distinct.

diagramme architectural montrant les back-ends pour le modèle frontends.

Pour plus d’informations, consultez Pattern : Backends For Frontends.

Problèmes et considérations

  • Évaluez le nombre optimal de services pour vous, car cela aura des coûts associés. La maintenance et le déploiement de services supplémentaires signifient une surcharge opérationnelle accrue. Chaque service individuel a son propre cycle de vie, ses besoins en matière de déploiement et de maintenance et ses besoins en matière de sécurité.

  • Passez en revue les objectifs de niveau de service (SLA) lors de l’ajout d’un nouveau service. Une latence accrue peut se produire, car les clients ne contactent pas directement vos services et le nouveau service introduit un tronçon réseau supplémentaire.

  • Lorsque différentes interfaces effectuent les mêmes requêtes, évaluez si les requêtes peuvent être consolidées dans un seul service BFF. Le partage d’un seul service BFF entre plusieurs interfaces peut entraîner des exigences différentes pour chaque client, ce qui peut compliquer la croissance et la prise en charge du service BFF.

    La duplication de code est un résultat probable de ce modèle. Évaluez le compromis entre la duplication de code et une expérience mieux adaptée pour chaque client.

  • Le service BFF ne doit gérer que la logique spécifique au client liée à une expérience utilisateur spécifique. Les fonctionnalités croisées, telles que la surveillance et l’autorisation, doivent être abstraites pour maintenir la lumière du service BFF. Les fonctionnalités courantes qui peuvent apparaître dans le service BFF sont gérées séparément avec de contrôle de contrôle, limitation de débit, routage, etc.

  • Tenez compte de l’impact sur l’équipe de développement lors de l’apprentissage et de l’implémentation de ce modèle. La création de nouveaux back-ends nécessite du temps et des efforts, ce qui peut entraîner une dette technique tout en conservant le service principal existant.

  • Évaluez si vous avez besoin de ce modèle du tout. Par exemple, si votre organisation utilise GraphQL avec des résolveurs spécifiques au serveur frontal, BFF peut ne pas ajouter de valeur à vos applications.

    Un autre exemple est l’application qui combine passerelle d’API avec des microservices. Cette approche peut être suffisante pour certains cas où les FBF ont été précédemment recommandées.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

  • Un service principal à usage général ou partagé doit être maintenu avec une charge de développement importante.

  • Vous souhaitez optimiser le back-end pour les exigences des interfaces clientes spécifiques.

  • Les personnalisations sont effectuées sur un serveur principal à usage général pour prendre en charge plusieurs interfaces.

  • Un langage de programmation est mieux adapté au serveur principal d’une interface utilisateur spécifique, mais pas toutes les interfaces utilisateur.

Ce modèle peut ne pas convenir :

  • Lorsque les interfaces effectuent les mêmes requêtes ou les demandes similaires au serveur principal.

  • Quand une seule interface est utilisée pour interagir avec le serveur principal.

Conception de la charge de travail

Un architecte doit évaluer la façon dont les serveurs principaux pour le modèle Frontends peuvent être utilisés dans la conception de leur charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Par exemple:

Pilier Comment ce modèle soutient les objectifs des piliers.
Les décisions relatives à la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à s’assurer qu’elle retrouve un état de fonctionnement optimal après une défaillance. Avoir des services distincts exclusifs à une interface frontale spécifique contient des dysfonctionnements, de sorte que la disponibilité d’un client peut ne pas affecter la disponibilité de l’accès d’un autre client. En outre, lorsque vous traitez différents clients différemment, vous pouvez hiérarchiser les efforts de fiabilité en fonction des modèles d’accès clients attendus.

- RE :02 Flux critiques
- RE :07 Auto-conservation
Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. En raison de la séparation des services introduite dans ce modèle, la sécurité et l’autorisation dans la couche de service qui prennent en charge un client peuvent être adaptées aux fonctionnalités requises par ce client, ce qui peut réduire la surface d’exposition d’une API et un mouvement latéral entre différents back-ends susceptibles d’exposer différentes fonctionnalités.

- SE :04 Segmentation
- SE :08 Ressources de renforcement
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes grâce à des optimisations de la mise à l’échelle, des données, du code. La séparation du back-end vous permet d’optimiser de manière à ce qu’elle ne soit pas possible avec une couche de service partagé. Lorsque vous gérez des clients individuels différemment, vous pouvez optimiser les performances pour les contraintes et fonctionnalités d’un client spécifique.

- PE :02 Planification de la capacité
- flux critiques PE :09

Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.

Exemple :

Cet exemple montre un cas d’usage pour le modèle dans lequel vous avez deux applications clientes distinctes : une application mobile et une application de bureau. Les deux clients interagissent avec une gestion des API Azure (passerelle de plan de données), qui agit comme une couche d’abstraction, qui gère les préoccupations croisées courantes telles que :

  • d’autorisation : s’assurer que seules les identités vérifiées avec les jetons d’accès appropriés peuvent appeler des ressources protégées à l’aide de la gestion des API Azure (APIM) avec l’ID Microsoft Entra.

  • surveillance : capture et envoi de détails de demande et de réponse à des fins d’observabilité à Azure Monitor.

  • mise en cache des requêtes : optimisation des requêtes répétées en servant les réponses du cache à l’aide des fonctionnalités intégrées APIM.

  • routage & agrégation : diriger les requêtes entrantes vers les services principaux appropriés pour le serveur frontal (BFF).

Chaque client dispose d’un service BFF dédié s’exécutant en tant que fonction Azure qui sert d’intermédiaire entre la passerelle et les microservices sous-jacents. Ces BFF spécifiques au client garantissent une expérience personnalisée pour la pagination entre autres fonctionnalités. Bien que le mobile soit plus sensible à la bande passante et la mise en cache améliore les performances, le bureau agrège plusieurs pages dans une seule requête, en optimisant pour une expérience utilisateur plus riche.

Diagramme montrant l’architecture Azure BFF avec Gestion des API Azure qui gère les problèmes de coupe croisée ; récupération de données mobiles et de bureau à l’aide de BFF Azure Functions propres au client.

Flux A : Client mobile – première demande de page

  1. Le client mobile envoie une demande de GET pour la page 1 y compris le jeton OAuth 2.0 dans l’en-tête d’autorisation.
  2. La requête atteint la passerelle APIM Azure, qui l’intercepte et :
    1. Vérifie l’état de l’autorisation : APIM implémente la défense en profondeur, afin qu’elle vérifie la validité du jeton d’accès.
    2. Diffusez en continu l’activité de la demande en tant que journaux d’activité vers Azure Monitor : les détails de la demande sont enregistrés pour l’audit et la surveillance.
  3. Les stratégies sont appliquées, puis Azure APIM achemine la requête vers azure Function Mobile BFF.
  4. Azure Function Mobile BFF interagit ensuite avec les microservices nécessaires pour extraire une page unique et traiter les données demandées pour fournir une expérience légère.
  5. La réponse est retournée au client.

Flux B : client mobile – première demande mise en cache de page

  1. Le client mobile envoie la même demande de GET pour la page 1 à nouveau, y compris le jeton OAuth 2.0 dans l’en-tête d’autorisation.
  2. La passerelle AZURE APIM reconnaît que cette requête a été effectuée avant et :
    1. Les stratégies sont appliquées et, après cela, elles identifient une réponse mise en cache correspondant aux paramètres de la requête.
    2. Retourne immédiatement la réponse mise en cache, ce qui élimine la nécessité de transférer la requête à Azure Function Mobile BFF.

Flux C : client de bureau – première requête

  1. Le client de bureau envoie une demande de GET pour la première fois, y compris le jeton OAuth 2.0 dans l’en-tête d’autorisation.
  2. La requête atteint la passerelle AZURE APIM, où des problèmes de coupe croisée similaires sont traités :
    1. Autorisation : la validation des jetons est toujours requise.
    2. Diffuser en continu l’activité de la demande : les détails de la demande sont enregistrés pour l’observabilité.
  3. Une fois que toutes les stratégies ont été appliquées, Azure APIM achemine la requête vers azure Function Desktop BFF, qui est responsable de la gestion du traitement des applications lourdes sur les données. Desktop BFF agrège plusieurs requêtes à l’aide d’appels de microservices sous-jacents avant de répondre au client avec une réponse à plusieurs pages.

Conception

  • Microsoft Entra ID sert de fournisseur d’identité basé sur le cloud, en émettant des revendications d’audience personnalisées pour les clients mobiles et de bureau, qui sont ensuite exploitées pour l’autorisation.

  • Gestion des API Azure agit comme proxy entre les clients et leurs bbFs ajoutant un périmètre. Il est configuré avec des stratégies pour valider les jetons web JSON (JWTs), rejeter les demandes qui arrivent sans jeton ou les revendications ne sont pas valides pour le BFF ciblé. En outre, il diffuse tous les journaux d’activité vers Azure Monitor.

  • Azure Monitor fonctionne comme solution de supervision centralisée, en agrégeant tous les journaux d’activité pour garantir une observabilité complète et de bout en bout.

  • Azure Functions est une solution serverless qui expose en toute transparence la logique BFF sur plusieurs points de terminaison, ce qui simplifie le développement, réduit la surcharge de l’infrastructure et réduit les coûts opérationnels.

Étapes suivantes