API pilotées par les événements dans les architectures de

microservices
Version Q4-2020

auteur

 Dakshitha Ratnayake, directrice associée - Technology Evangelism dakshitha@wso2.com @techieducky

Ce document se concentrera sur les API événementielles et leur gestion. Le concept piloté par les événements existe depuis longtemps,
mais les API pilotées par les événements sont un sujet plus récent, qui implique l’utilisation de l’architecture pilotée par les événements
pour prendre en charge la communication évolutive, en temps réel (ou quasi réel), basée sur la transmission dans les API publiées à des
tiers.

1.0 Introduction
Au fur et à mesure que les architectures et les technologies évoluaient pour permettre la « transformation numérique », les
applications monolithiques ont été décomposées en services à granularité grossière et maintenant en microservices plus fins
couplés et faiblement couplés qui peuvent être implémentés à l’aide d’une variété de technologies. Docker et Kubernetes ont
simplifié le déploiement conteneurisé et la mise à l’échelle des microservices dans différents environnements. Pour permettre la
consommation pour les clients, les partenaires et d’autres tiers, ces microservices ont été exposés via des API RESTful managées et
ils communiquent directement et de manière synchrone entre eux via HTTP. Les développeurs ont conçu des API basées sur les
ressources à l’aide d’actions CRUD. Et bien sûr, les plates-formes de gestion des API et les outils riches ont rendu l’expérience de
consommation d’autant plus facile et meilleure. La grande majorité des API qui composent le Web aujourd’hui sont des API
synchrones. Toutefois, les interactions synchrones demande/réponse se produisent une à la fois, dans une séquence préétablis, et
chaque interaction bloque la progression du processus jusqu’à son achèvement. Cela signifie que le temps de réponse à l’utilisateur
est une somme cumulative des temps de réponse des microservices. En outre, si un client souhaite connaître une mise à jour, il doit
continuellement appeler l’API pour vérifier les modifications de données. Ce modèle est appelé interrogation et a été une solution
courante pour les clients qui doivent prendre connaissance de nouvelles données ou être avertis des événements principaux. Et la
plupart de ces appels « d’interrogation » sont gaspillés parce que les données n’ont pas changé et que les ressources (CPU, réseau,
etc.) ont été utilisées inutilement. C’est ainsi que le terme de « folie des sondages » a été inventé. En outre, la limitation de débit
(principalement appliquée par les gestionnaires d’API) empêche les clients d’interroger suffisamment souvent pour prendre en
charge les besoins de la solution en matière de mises à jour d’événements.

Rendre les API pilotées par les événements ou asynchrones peut systématiquement résoudre ces problèmes et vraiment offrir
l’expérience (presque) en temps réel, et l’adoption d’une architecture pilotée par les événements au niveau du système peut
vraiment fournir des avantages importants et apporter confort aux utilisateurs finaux et efficacité au Web. Ce document traitera de
la façon dont.

1.1 Systèmes pilotés par les événements

Qu’est-ce que l’événementiel ? Une architecture pilotée par les événements (EDA) est centrée sur le concept d’événements. Un
événement peut être défini comme un changement d’état et peut représenter étroitement ce qui se passe dans le monde réel. Les
achats en ligne, les actions humaines, les instructions de commande et de contrôle, les lectures de capteurs, les fils d’actualité, les
ticks boursiers, les changements de taux d’intérêt, les alertes de processus, les notifications de flux de travail, la détection des
pannes et la détection des fraudes sont tous des incidents réels qui peuvent être capturés en tant qu’événements dans un système
axé sur les événements. Être axé sur les événements, c’est tirer parti des événements au fur et à mesure qu’ils se produisent; en
d’autres termes, il s’agit de détecter, de capturer et de répondre à ces événements en temps (presque) réel pour offrir une meilleure
qualité de service, offrir une meilleure expérience client et prendre des décisions commerciales plus éclairées.

Les expériences en temps réel (ou presque en temps réel) sont créées avec des architectures pilotées par les événements.

Il s’agit du pouvoir de pouvoir faire quelque chose à cet instant où cela se produit. Ce qui est en temps réel varie pour différentes
industries (généralement des millisecondes ou moins) avec leurs propres métriques. Sur les marchés des capitaux, 1 milliseconde
vaut 8 millions de dollars. Cela signifie que les applications doivent être très réactives pour changer. L’un des plus grands avantages
de l’EDA est qu’il optimise le temps qu’il faut entre la survenance d’un événement et la réaction de l’entreprise à cet événement.
Ainsi, au lieu de sonder, les consommateurs peuvent enregistrer leur intérêt (s’abonner) et réagir aux événements en temps réel.
Avec la transmission en temps réel d’événements (pushing au lieu d’interrogation) et les services exécutés en parallèle, tout interagit
efficacement les uns avec les autres. De meilleurs temps de réponse se traduisent par un meilleur engagement et une meilleure
satisfaction des utilisateurs et, par conséquent, par de meilleures affaires.

Les AED sont faiblement couplés et agiles.

Dans les architectures pilotées par les événements, les applications et les services sous-jacents sont faiblement couplés. Par
conséquent, les producteurs d’événements transmettent simplement des événements (et ne se soucient pas de savoir si quelqu’un
est intéressé). Ils tirent, généralement à un courtier, et oublient. Les applications et microservices consommateurs n’ont pas besoin
de savoir combien d’applications différentes ils consomment des données ; ils ne se préoccupent que des données. Ainsi, les
applications consommatrices sont inscrites auprès du broker pour recevoir les mises à jour de données qu’elles souhaitent. Le
découplage, comme nous le savons tous, offre de nombreux avantages. Étant donné que les choses sont traitées indépendamment,
les consommateurs peuvent être mis à l’échelle indépendamment de l’expéditeur. Cela signifie permettre à des millions d’appareils
de consommer des événements. En outre, les problèmes de goulot d’étranglement peuvent être plus facilement suivis jusqu’à un
seul composant en raison du découplage.

Il rend également les systèmes flexibles et agiles, de sorte que les nouveaux systèmes peuvent être facilement connectés à
l’architecture sans apporter de modifications aux systèmes sources ou avoir un impact sur d’autres systèmes, assurant ainsi
l’architecture à l’épreuve du temps. Il permet aux développeurs de passer moins de temps à se soucier des systèmes et plus à
propos de la logique métier, ce qui leur permet de créer des produits plus rapidement. Une architecture de microservices pilotée par
les événements signifie un délai de mise sur le marché plus rapide pour les fonctionnalités métier nouvelles et modifiées.

Devenir axé sur les événements crée des systèmes efficaces.

Les EDA améliorent non seulement la latence (afin que les utilisateurs n’aient pas à actualiser leurs interfaces utilisateur pour obtenir
les dernières mises à jour), mais prennent également en charge une livraison fiable. Avec la plupart des courtiers, si un service
échoue, le message peut être stocké par le courtier d’événements et peut être remis lorsque le service revient en ligne , une remise
fiable est une base pour une cohérence éventuelle et aucune perte de données. Un intermédiaire avec état avec les bonnes
capacités permet également une tolérance aux pannes supplémentaire, des incompatibilités de vitesse et une absorption des chocs
pendant les volumes de pointe.

Avec ces gains dus à l’EDA, un fournisseur d’API desservant les clients avec des événements peut non seulement les rendre plus
heureux, mais également réduire considérablement leur facture cloud sur le processeur et le réseau.

2.0 Architecture

2.1 Une architecture de microservices synchrone d’abord API

Il y a principalement trois composants dans l’architecture :

 Les applications grand public : tout ce qui peut consommer une API.
 La couche d’exposition de l’API : idéalement une passerelle API ou une micro passerelle, mais parfois aussi un équilibreur de
charge, un pare-feu de couche 7, un CDN ou toute autre application de couche 7 au-dessus du ou des services principaux.
 Les microservices : un microservice (un service principal ou un service d’intégration) encapsule essentiellement une logique.
 Figure 1: A Synchronous API-driven Microservice Architecture

Un appel d’API synchrone implique un thread unique pour traiter une demande et sa réponse. Comme le montre la figure 1, pour
chaque demande (REST, GraphQL, gRPC), une réponse suit. La communication synchrone est idéale pour de nombreux scénarios, en
particulier si vous avez besoin d’une réponse instantanée ; toutefois, dans d’autres cas, en particulier lorsque le traitement requis
pour la réponse se produit à un moment différent, la messagerie synchrone ordinaire devient délicate. Comme solution, les
développeurs ont eu recours à des techniques d’interrogation pour obtenir des mises à jour. Mais les données ne cessent d’évoluer.
Par exemple, une application de vente au détail souhaitant connaître les changements de prix devra interroger l’API en continu,
surchargeant ainsi le système principal. Comme dans la plupart des cas, si un système de gestion des API est présent, il limitera ces
demandes.
 Figure 2 : Envoi d’événements via des API asynchrones dans une application de vente au détail

Toutefois, si l’application de vente au détail est implémentée de manière événementielle, les modifications de prix sont envoyées au
client à la place. Tout d’abord, toute application intéressée par l’événement de changement de prix s’abonnera à l’événement.
Lorsqu’un changement de prix se produit, ces données sont distribuées aux applications abonnées. Une telle application n’aura plus
besoin d’interroger continuellement le prix car le dernier prix est dans son système; l’application peut conserver ces données dans
son cache ou les conserver persistantes. Pour de tels scénarios, il est plus judicieux de recevoir des événements push via des API «
asynchrones » que d’interroger via des API « sync », comme illustré à la figure 2.

2.2 Une architecture de microservices basée sur les événements en premier pour les API
Les langages d’application et les architectures principales s’appuyaient sur des événements antérieurs à la création de REST. À
l’époque, les industries financières avaient des événements allant des bourses aux fonds spéculatifs pour leur permettre de rester en
tête du marché en utilisant des réglages basés sur la propriété intellectuelle et des middlewares propriétaires. Depuis lors, les bus à
messages ont évolué vers des normes ouvertes adoptées en dehors du financement. Bien qu’EDA n’exige pas explicitement
l’utilisation d’intergiciels, l’utilisation d’un tel intermédiaire entre les producteurs d’événements et les consommateurs aide à mettre
en œuvre les modèles correspondants et à fournir des solutions plus faciles à gérer et évolutives. Nous appelons cet intergiciel
(middleware) le courtier d’événements. Quelques exemples notables de courtiers sont RabbitMQ, Apache Kafka, et Apache
ActiveMQ, parmi beaucoup d’autres sur le marché aujourd’hui. En outre, une architecture de microservices évolutive (MSA) est
l’architecture optimale pour les services backend complexes pilotés par les événements. Ces microservices pilotés par les
événements peuvent agir en tant qu’abonnés ou éditeurs d’événements afin de traiter les événements, de gérer les erreurs et de
conserver les états pilotés par les événements.

Contrairement aux API REST (qui sont généralement implémentées dans les scénarios d’interrogation), les API push ou de diffusion
en continu sont pilotées par les événements. Une API pilotée par les événements requiert deux fonctionnalités : un mécanisme
permettant à un consommateur de s’abonner (cela peut être contrôlé par l’utilisateur ou par programmation) et les moyens de
fournir des événements aux consommateurs abonnés. Les API et/ou services événementiels peuvent se connecter au broker et les
clients peuvent s’abonner à un canal d’intérêt. Finalement, lorsqu’un événement a lieu, il déclenche un flux de données vers un client
qui attend les données entrantes afin de les traiter en temps réel. En outre, en ce qui concerne la communication bidirectionnelle,
l’application cliente doit également être en mesure de publier des événements sur le serveur principal via l’API pilotée par les
événements.
 Figure 3: An Asynchronous API-driven Microservice Architecture

Pour être plus précis, un courtier d’événements, comme illustré à la figure 3, peut être utilisé pour :To be more specific, an event
broker, as shown in Figure 3, can be used to:

 Se comportent comme une dorsale principale ou la couche de distribution d’événements pour les microservices qui publient
et traitent des événements.
 Libérer les données des systèmes/friches industrielles existants. Cela peut être fait via un service bus d’entreprise ou des
outils de capture de données modifiées (CDC). Lorsque quelque chose change sur le macroordinateur, ils peuvent publier des
événements sur le broker.
 Être alimenté par des appareils IoT (alarmes, capteurs, appareils), des systèmes connectés (terminaux PoS), etc.
 Interagissez avec les passerelles API pour exposer les données en tant qu’événements à l’extérieur. Ces passerelles (ou micro
passerelles)peuvent prendre des données d’une requête/réponse et les transformer en événement ou peuvent même activer
des API REST existantes.

3.0 API pilotées par les événements

Recevoir des notifications sur quelqu’un qui aime une image ou qui réagit à une histoire sur Instagram, un nouveau message
Whatsapp, un ticker boursier ou un flux social affichant les dernières mises à jour sont tous rendus possibles grâce à différents
modes de communication asynchrone. Alors, comment devrions-nous effectuer exactement la communication asynchrone pilotée
par les événements dans le monde des API où la communication synchrone est prédominante et la plupart des pare-feu bloquent le
trafic non-HTTP? Il n’existe vraiment pas de solution universelle.

Le paysage technologique des API asynchrones est en plein essor. Les anciens protocoles tels que WS-Eventing et XMPP (un
protocole d’interrogation qui ouvre un thread HTTP et ne le ferme jamais) font maintenant place à des technologies plus récentes
(même si Whatsapp est toujours basé sur XMPP au moment de la rédaction de cet article). Depuis 2011, avec l’avènement des
réseaux sociaux et pour prendre en charge l’interface utilisateur réactive, le Web a normalisé les protocoles pour le trafic
bidirectionnel / peer-to-peer à faible volume(Websockets)et la poussée de serveur à client sur HTTP(Server-Sent Events). Pour les
appareils IoT à batterie limitée, on préférerait généralement utiliser MQTT. Les webhooks sont devenus populaires pour gérer les
événements à faible volume. Même si Kafka, qui est basé sur TCP, est idéal pour gérer la communication asynchrone entre les
microservices internes, il n’est pas optimisé pour être exposé pour fournir aux consommateurs d’API un accès facile aux données en
temps réel et il créera des problèmes avec les pare-feu.

Les charges utiles sont encore principalement JSON, mais Avro dans Kafka et les tampons de protocole dans gRPC sont de plus en
plus répandus. Dans les API REST synchrones, les requêtes peuvent être ajoutées à la chaîne d’URL qui adresse le point de
terminaison d’une API (une requête GET) ou empaqueter la même requête qu’une charge utile JSON à la place (une demande
POST). Les approches push/streaming peuvent être très différentes les unes des autres. Par exemple, les Websockets autorisent les
flux bidirectionnels tandis que les Webhooks et les événements côté serveur sont unidirectionnels. XMPP et SMPP diffèrent
considérablement, de sorte que XMPP est principalement basé sur des charges utiles XML tandis que SMPP s’appuie sur des
données binaires.

Un courtier de messages est généralement requis dans l’architecture principale pour capturer et filtrer les événements et gérer les
abonnements aux événements. De plus, les langages traditionnellement utilisés pour créer des couches applicatiques liées aux bases
de données ont également connu leur révolution événementielle avec des extensions réactives telles que RxJava largement
adoptées par la communauté Java. Et puis il y a AsyncAPI, qui est maintenant largement adopté pour documenter les API pilotées
par les événements.

Approfondissons quelques normes couramment utilisées et émergentes dans l’espace API piloté par les événements.

3.1 Définition d’API pilotées par les événements avec AsyncAPI

L’une des raisons pour lesquelles les plates-formes de gestion des API ont vraiment décollé est leur capacité à rationaliser le
développement et à favoriser l’adoption de leurs API via des portails de développeurs et des normes de définition d’API telles
qu’OpenAPI. Une fois que le fournisseur a défini l’interface API conformément à la spécification, les consommateurs peuvent passer
la définition d’interface dans une infrastructure de génération de code (telle que Swagger) pour générer de la documentation et du
code à exécuter sur une plateforme d’exécution. Cela a réduit au minimum la quantité d’efforts manuels et de communication requis
d’un point de vue de bout en bout.
Une spécification similaire pour normaliser les API pilotées par les événements est apparue assez récemment : AsyncAPI. AsyncAPI
est conçu le long des mêmes éléments d’OpenAPI et partage de nombreuses constructions communes pour simplifier l’adoption,
mais il est également livré avec des fonctionnalités supplémentaires pour prendre en charge les événements. Il prend en charge une
grande variété de protocoles de messagerie et de transports (tels que AMQP, MQTT, WebSockets, Kafka, JMS, STOMP, HTTP, etc.) et
de formats de schéma d’événement. Par conséquent, la définition d’API contiendra la définition de la charge utile de l’événement, le
nom du canal, les en-têtes d’application/transport, les protocoles et d’autres sémantiques d’événement pour se connecter, publier
et s’abonner à l’API.

3.2 Protocoles de messagerie asynchrones pour les API

Webhooks

Également appelées « API inverses », les API de webhook détachent complètement la requête et la réponse HTTP les unes des
autres.
 Figure 4 : API pilotées par les événements avec webhooks

Avec webhooks:

1. Un développeur d’API peut s’abonner à une API REST avec une clé API et fournir une URL de rappel (un point de terminaison
HTTP, également appelé webhook) via le portail des développeurs du fournisseur d’API.
2. Pendant l’exécution, l’application du développeur appellera l’API avec la clé API.
3. Pour une telle demande, une réponse 2xx sera envoyée en tant qu’accusé de réception.
4. Le fournisseur d’API « diffuse » vers le point de terminaison de rappel via une requête HTTP POST, lorsque le processus
attendu déclenche des événements qui doivent être signalés au consommateur.

Les webhooks sont plutôt faciles à mettre en œuvre. Toutefois, par rapport à d’autres mécanismes, les webhooks sont préférables
pour envoyer des notifications à un ou à un petit nombre de points de terminaison. Les webhooks ne conviennent pas pour envoyer
des événements directement aux applications clientes (c’est-à-dire les applications mobiles/de navigateur ou d’autres applications
privées hébergées à l’intérieur d’un pare-feu), car chaque client doit héberger un point de terminaison HTTP et être en possession
d’un nom de domaine adressable publiquement, et la sécurisation de ce réseau (généralement à l’aide de l’authentification de base
ou ssl mutuel), impliquerait une surcharge d’administration impossible à maintenir. Les clients sont presque toujours des serveurs
eux-mêmes.

La spécification OpenAPI 3.0.0 prend en charge les webhooks via un élément de rappel qui peut être utilisé pour définir un
webhook. Cependant, en général, il n’y a pas de normes formelles autour des webhooks.

WebSockets

Le protocole WebSocket permet une communication bidirectionnelle constante entre le serveur et le client, ce qui signifie que les
deux parties peuvent communiquer et échanger des données en cas de besoin. Les WebSockets sont des connexions point à point
modélisées sur des sockets TCP et ne prennent en charge aucun pub-sub natif.
 Figure 5 : API pilotées par les événements avec WebSockets

Les WebSockets n’utilisent pas de stratégie de demande/réponse où une connexion est ouverte au cours de la demande, puis
fermée après son exécution initiale. Dans le cas de WebSockets, la connexion reste ouverte jusqu’à ce qu’elle soit fermée
explicitement. Une connexion WebSocket est établie en effectuant un appel HTTP, puis en demandant une mise à niveau sur cette
connexion. Après cela, la communication a lieu sur une seule connexion TCP à l’aide du protocole WebSocket. En d’autres termes, au
lieu d’envoyer une demande à , la demande est envoyée à . http://<target>ws://<target>
L’utilisation d’une connexion TCP unique réduit l’utilisation des ressources en transférant uniquement les informations essentielles
(la surcharge d’en-tête HTTP est réduite) et optimise ainsi les performances. Pour utiliser WebSockets, le navigateur doit être
compatible. Toutefois, cette limitation est insignifiante car la majorité des navigateurs prennent aujourd’hui déjà en charge le
protocole WebSocket. L’interface WebSocket peut être définie avec la spécification AsyncAPI. Les WebSockets ont été combinés
avec MQTT, AMQP et des implémentations de protocole propriétaires pour fournir des communications pub-sub.

Événements envoyés par le serveur

Avec les événements envoyés par le serveur (SSE), un protocole ouvert, léger et d’abonnement uniquement, une application de
navigateur peut s’abonner à un flux d’événements ou de mises à jour de messages générés par un serveur. Tout d’abord, le client
crée un nouvel objet EventSource et passe l’URL d’un point de terminaison au serveur via une requête HTTP normale. Le client
attend ensuite une réponse avec un flux de messages d’événement. Le serveur laisse la réponse HTTP ouverte jusqu’à ce qu’il n’ait
plus d’événements à envoyer. Le serveur mettra fin à une connexion obsolète (si la connexion est ouverte depuis assez longtemps)
ou attendra que le client ferme explicitement la demande initiale.
 Figure 6 : API pilotées par les événements avec événements envoyés par le serveur

SSE est approprié si un protocole de communication unidirectionnel efficace (en raison d’une meilleure latence par rapport à
d’autres méthodes de diffusion en continu basées sur HTTP) qui n’ajoute pas de charge de serveur inutile (comme avec
l’interrogation longue HTTP) est nécessaire. SSE est également livré avec une norme prédéfinie pour la gestion des erreurs et est
largement utilisé dans l’industrie aujourd’hui pour diffuser des alertes de nouvelles, des scores sportifs en direct, des mises à jour du
cours des actions, parmi de nombreuses autres mises à jour générées par le serveur. La seule limitation majeure de SSE est
l’impossibilité de transmettre des informations à un serveur à partir d’un client, ce qui en fait un choix très populaire pour
implémenter la communication asynchrone de serveur à navigateur.

GraphQL

Il existe deux façons courantes d’effectuer des communications asynchrones à partir d’un serveur GraphQL : les abonnements et les
requêtes en direct. Facebook a développé des abonnements GraphQL en interne en 2015 et l’a utilisé pour alimenter des
fonctionnalités à l’échelle mondiale telles que les commentaires en direct et les réactions de streaming. Les requêtes en direct sont
entrées en scène beaucoup plus tard et ne sont pas encore aussi largement utilisées que les abonnements.

Les abonnements observent les événements; les requêtes en direct observent les données. Les deux sont des opérations de
demande/flux où le serveur répond à une demande du client avec un flux de réponses GraphQL, au format désigné par le document
de demande du client. Les abonnements sont des opérations GraphQL, définies dans la spécification. Les requêtes en direct ne sont
pas formellement définies dans la spécificationet sont généralement modélisées en ajoutant une directive spéciale à une opération
de requête.

Les deux méthodes sont indépendantes de la technologie. Dans la spécification, les abonnements spécifient uniquement des
algorithmes pour la création d’un flux, le contenu de chaque charge utile sur ce flux et la fermeture de ce flux. Il n’existe
intentionnellement aucune spécification pour les formats de sérialisation, le mécanisme de transport, l’accusé de réception des
messages, la mise en mémoire tampon, les demandes de renvoi ou tout autre détail de qualité de service (QoS). Ceux-ci sont laissés
à choisir par le service d’implémentation. Ainsi, ceux qui programment des abonnements GraphQL ou des requêtes en direct
peuvent utiliser une technologie de messagerie qui répond le mieux à leurs besoins. Les deux méthodes peuvent utiliser une variété
de protocoles (par exemple, MQTT, AMQP, RSocket, Redis, Socket.io et d’autres formats) et de transport (par exemple, WebSocket,
TCP, HTTP long-polling, SSE, etc.).

Les abonnements nécessitent un courtier de messages. Les requêtes en direct qui dépassent l’interrogation nécessiteront des
sources de données réactives (telles qu’une base de données qui permet de suivre une requête) et un modèle de programmation
associé (tel que Rx). Dans les deux cas, le serveur doit stocker chaque demande d’exécution d’opération, s’abonner aux flux sources
sous-jacents et maintenir un index des connexions de longue durée au client via une passerelle en temps réel.

Abonnements GraphQL

Les abonnements GraphQL sont un mécanisme de streaming intégré à GraphQL et sont conçus de manière à ce que la
communication HTTP synchrone et les interactions asynchrones pilotées par les événements soient disponibles à partir d’une seule
expérience d’API, c’est-à-dire qu’une API unique définie dans GraphQL peut prendre en charge un mélange de requêtes et de
mutations (commandes) ainsi que des notifications d’événements asynchrones. Les abonnements offrent la possibilité d’émettre des
messages (non bidirectionnels) de façon asynchrone hors de l’API GraphQL à partir de la logique d’exécution de requête ou de
mutation.
 Figure 7 : API pilotées par les événements avec abonnements GraphQL

Les abonnements sont pilotés par le client, ce qui signifie que les applications consommatrices définissent les données qui doivent
être incluses dans l’événement. Les clients peuvent indiquer une opération d’abonnement à l’aide du mot clé subscription, de sorte
que chaque fois que l’événement défini se produit, il exécute la sélection définie et envoie le résultat.

L’implémentation d’un abonnement GraphQL nécessite l’utilisation d’un courtier de messages. Apollo GraphQL Server utilise le
protocole WebSocket et est livré avec un courtier de messages installé par défaut. Sangria (une autre implémentation de GraphQL)
utilise des événements envoyés par le serveur. Bien que WebSockets soit le choix populaire, d’autres protocoles tels que AMQP ou
XMPP peuvent également être utilisés.

Requêtes graphQL en direct

 Figure 8 : API pilotées par les événements avec des requêtes en direct GraphQL

Une requête GraphQL peut être transformée en requête en direct en incluant une directive, telle que '@live'.

Les clients peuvent indiquer une opération d’abonnement à l’aide du mot clé subscription, de sorte que chaque fois que
l’événement défini se produit, il exécute la sélection définie et envoie le résultat. En bref, le client dit au serveur d’évaluer la sélection
définie et d’informer chaque fois que la « sélection » donnerait une réponse différente. Tout comme les abonnements, une requête
en direct est un flux push en lecture seule (non bidirectionnel). Il nécessite l’implémentation d’une couche de données réactive (par
exemple, RxJS) dans le serveur GraphQL (par exemple, pour terminer une requête). La couche de données réactive écoute les
modifications au niveau de la base de données, qui peuvent être transmises en continu au consommateur.
Hasura prend en charge les abonnements et les requêtes en direct, et le client Apollo peut se rapprocher du comportement d’une
requête en direct avec sa fonction d’interrogationintégrée.

gRPC

Bien qu’il soit largement utilisé pour la communication synchrone entre les microservices internes (microservices au sein d’une
organisation), gRPC, à l’insu de beaucoup, prend en charge la diffusion en continu bidirectionnelle en raison de ses liens avec
HTTP/2. En d’autres termes, il permet de définir une opération de service qui accepte un flux entrant ou émet un flux sortant, ou les
deux. Ceci est populaire pour les microservices qui sont créés avec gRPC et doivent être en mesure de communiquer dans les deux
sens.

gRPC est une norme qui tire parti de HTTP/2 et des tampons de protocole (au lieu de JSON) pour garantir des performances accrues
et une interopérabilité maximale. gRPC utilise des tampons de protocole (ou protobufs) comme format de sérialisation sur HTTP/2
et également pour créer la définition d’interface du service gRPC. En d’autres termes, le fichier .proto agit comme la définition de
service (au lieu d’un fichier Swagger) et peut être utilisé pour générer des stubs client et des squelettes côté serveur. Par rapport aux
API REST, les API gRPC sont plus rapides. Cependant, il existe une courbe d’apprentissage considérable et elle n’est pas toujours
aussi intuitive et facile à apprendre que REST.
 Figure 9 : API pilotées par les événements avec gRPC

Même si la communication externe basée sur gRPC est rare, il existe des méthodes pour le faire. Par exemple, un client Web gRPC,
qui est un client spécial pour les navigateurs, peut être utilisé pour les interactions client-serveur. Cependant, c’est compliqué. Par
conséquent, en règle générale, nous pouvons utiliser gRPC pour les communications synchrones et asynchrones entre les
microservices internes et dans les environnements B2B.

3.3 Gestion des API permettant les événements

Étant donné que l’accès dynamique aux données et la fédération des données entre les écosystèmes peuvent créer des
fonctionnalités révolutionnaires, les plateformes de gestion des API existantes ont également commencé à prendre en charge
plusieurs protocoles d’API asynchrones (les plus courants étant les webhooks et les WebSockets au moment de la rédaction de cet
article), facilitant ainsi une architecture événementielle de bout en bout. En tirant parti des spécifications OpenAPI et AsyncAPI pour
documenter et découvrir ces API pilotées par les événements, les entreprises et les sociétés SaaS ont pu produire des applications
en temps réel rationalisées, des produits API et des services pour leurs clients, les entreprises partenaires B2B et les unités
commerciales internes.

Une dorsale principale pilotée par les événements gérera le flux de données global en temps réel de manière sécurisée et à grande
échelle, tandis que les API asynchrones peuvent être gérées pour la consommation externe et interne avec une solution de gestion
des API traditionnelle fournie avec des fonctionnalités inhérentes ou étendues pour prendre en charge la sémantique pilotée par les
événements. Le gestionnaire d’API gérera les fonctionnalités de sécurité, de surveillance, d’audit, de limitation, de découverte et
d’outillage pour les API pilotées par les événements et fournira également des moyens d’activer les modèles commerciaux autour
des API.
 Figure 10 : Gestion des API pilotée par les événements

Alors que chaque protocole d’événements aura des besoins nuancés pour permettre la gestion des API, ils auront un ensemble de
besoins fondamentaux communs pour l’embarquement des utilisateurs, l’authentification, la journalisation, l’analyse, etc. En règle
générale, à un niveau élevé, le flux serait le suivant :

 Les développeurs d’API pointeront vers un point de terminaison de service existant (par exemple, WebSockets) ou une URL
de rubrique via un portail d’éditeur d’API. Ils peuvent définir un ou plusieurs chemins d’API en fournissant un accès HTTP,
HTTP/2 ou TCP. Le portail de l’éditeur est en fait un environnement de développement intégré qui permet aux développeurs
de créer les définitions d’interface d’API à l’aide d’OpenAPI (pour les webhooks) et d’AsyncAPI (pour les WebSockets) et
également de générer de la documentation qui permet aux consommateurs de découvrir et d’écrire des applications qui
utilisent le service. Le portail est également utilisé pour gérer le cycle de vie des API
 Les développeurs intéressés par l’API pilotée par les événements découvriront l’API et s’y abonneront via le portail des
développeurs. Ils devront fournir une URL de rappel dans le cas de webhooks. Cette demande est gérée dans le portail des
développeurs, qui génère les clés API requises.
 Sous le capot, via un proxy d’API dans la passerelle ou autrement, l’agent de messages sera configuré avec les listes de
contrôle d’accès correctes, les files d’attente internes, les abonnements et divers autres paramètres pour garantir la livraison
sécurisée des flux de produits de données sélectionnés via le broker et le proxy d’API au webhook du développeur ou
directement à l’application cliente. Pendant l’exécution, la passerelle API gère le proxy d’exécution des demandes et des
réponses de service et effectue l’authentification, la limitation, la journalisation, la médiation et la transformation en
communiquant avec d’autres composants clés tels que les composants de sécurité, de limitation et d’analyse du gestionnaire
d’API.
 Les composants de sécurité fourniront un ou plusieurs moyens aux consommateurs d’API de s’authentifier et d’accéder aux
API pilotées par les événements.
 Les outils d’analyse d’API continueront de comprendre comment les API sont consommées et comment les applications
utilisent les ressources d’API, et d’identifier les modèles liés à la consommation d’API dans les écosystèmes pour aider à créer
des modèles commerciaux. Ils vous aideront à visualiser tous les événements au sein d’une entreprise, quelle que soit
l’infrastructure sous-jacente.
  Les outils de monétisation des API (en conjonction avec les capacités d’analyse) permettent aux entreprises de générer des
revenus à partir de leurs API en mettant en œuvre différents modèles de monétisation des API tels que le paiement à
l’utilisation, l’utilisation basée sur l’abonnement, etc. Ils sont livrés avec la possibilité de facturer les utilisateurs directement
ou de s’intégrer à des systèmes de facturation externes.

Pour résumer, même si la plupart des organisations disposent d’une infrastructure de traitement des événements de base, beaucoup
n’ont pas les capacités nécessaires pour concevoir, développer, tester et gérer des API centrées sur les événements. La combinaison
des capacités traditionnelles de gestion des API, en particulier la gouvernance, le contrôle d’accès, la surveillance et l’analyse, avec
une architecture pilotée par les événements offre une valeur ajoutée considérable en termes d’expansion de la portée commerciale
et d’adoption en fournissant un accès géré.

4.0 Conclusion
Rendre les API asynchrones inverse le paradigme en permettant au serveur principal d’envoyer des flux d’événements au client
d’API. L’augmentation d’une API REST avec des fonctionnalités pilotées par les événements permet des expériences meilleures et
(presque) en temps réel, et augmente considérablement l’efficacité de l’utilisation du processeur et du réseau, même pour le trafic le
plus exigeant.

Les API permettant l’activation des événements comportent de nombreux défis. Il existe de multiples complexités à gérer, à
commencer par les frameworks et les protocoles réseau à choisir pour renforcer la fiabilité de la livraison et garantir l’évolutivité de
la solution à l’échelle du Web. Contrairement aux API rest-fashioned, qui suivent les mêmes modèles de base, il existe plusieurs
approches de push/streaming qui présentent des différences significatives les unes des autres. Les protocoles asynchrones
couramment utilisés aujourd’hui résolvent le problème de la communication (quasi) en temps réel, mais ils résolvent différents
aspects de ce problème de différentes manières, rendant ainsi certains protocoles servent des objectifs différents mieux que
d’autres. La gestion de ces API est un autre aspect crucial, car tout le monde qui gère des actifs physiques (des voitures aux
éoliennes) et d’autres systèmes événementiels essaie de gérer et de monétiser les flux de données générés par eux. Et cela nécessite
des outils de gestion d’API et des normes de définition d’API pour les API push/temps réel.
Les API pilotées par les événements ont été la pièce manquante pour réaliser une architecture pilotée par les événements de bout
en bout. Avec ceux-ci en place, l’ensemble de la chaîne - du plan de données, de l’API, du réseau, jusqu’aux frontaux - peut être
pilotée par les événements. Cela permet aux organisations, à leurs clients et à leurs partenaires de profiter véritablement des
avantages d’une architecture événementielle, notamment de la simplicité, de l’agilité et de l’efficacité qu’elle apporte à tous les
composants individuellement et collectivement. Cela dit, les applications clientes pilotées par les événements ont toujours besoin
d’une communication synchrone demande/réponse traditionnelle pour les interactions interactives et non pilotées par les
événements entre le client et le serveur principal. La combinaison d’API pilotées par les événements (soutenues par une architecture
pilotée par les événements) avec la conception traditionnelle des demandes/réponses apporte le meilleur des deux mondes pour
créer des applications clientes réactives qui ravissent les clients et fonctionnent correctement.

5.0 Références
[1] Emmelyn Wang - Un stratège d’API explore les API pilotées par les événements

[2] Luis Weir - Stratégies d’API pilotées par les événements: des WebHooks aux abonnements GraphQL

[3] Chris Wood - Qu’est-ce qu’une API de style Push Webhooks et comment fonctionne-t-elle?

[4] Bob Reselman - Comment créer une API de streaming à l’aide d’abonnements GraphQL

[5] Ably.io - Événements envoyés par le serveur (SSE) : une analyse approfondie conceptuelle

[6] Robert Zhu - Abonnements GraphQL vs requêtes en direct

[7] Kasun Indrasiri - Créer des microservices réels avec gRPC

[8] Kristopher Sandoval - 7 protocoles bons pour documenter avec AsyncAPI

[9] Ricardo Gomez-Ulmke et Florian Geiger - Apporter la messagerie asynchrone dans un monde RESTful avec Solace et Apigee
[10] Meshvi Patel - Pourquoi les API RESTful ne peuvent pas rivaliser avec l’approche événementielle des microservices

[11] Arshardh Ifthikar - Présentation des API WebSocket avec WSO2 API Manager

[12] Documentation wso2 API Manager - Créer et publier une API WebSocket