Kafka pour distribuer les évènements (il s'est passé "ça" sur "cette ressource", de manière ultra simple)
des APIs pour aller chercher l'info complémentaire, à partir d'un identifiant
J'ai pas encore de bonne vision de Kafka, mais j'ai cru comprendre qu'une gestion fine des permissions pouvait être un peu complexe, là où les APIs s'appuient sur le mécanisme "naturel" des applications. D'où l'intérêt de ne pas publier trop de trucs. Le défaut, c'est que potentiellement, avec cette approche, si le consommateur prend trop de temps à aller chercher les données, il peut rater des états intermédiaires.
app "source" publie l'info sur l'objet X qui a le statut 1
app "cible" reçoit le message, mais est en train de prendre le thé
app "source" publie l'info sur l'objet X qui a le statut 2
app "cible" reçoit le message, mais touille le sucre
app "source" public l'info sur l'objet X qui a le statut 3
app "cible" se réveille, traite les 3 messages, appelle l'API 3 fois, et récupère 3 fois le statut 3 et a perdu les étapes intermédiaires
Evidemment, si on envoie aussi l'état intermédiaire dans le message, et que l'application source garde tous les états, c'est pas grave, mais c'est le type de situation où il est préférable d'envoyer plus de données dans l'évènement.
En entreprise, ce que j'ai souvent vu, c'est du MQ (donc du message point à point) où on balance l'ensemble des informations nécessaire pour le destinataire. C'est pas très beau d'un point de vue architecture, mais ça marche, et l'infra est adaptée pour supporter des gros volumes de gros messages. Moins de contraintes pour l'émetteur. Du vrai couplage faible.
[^] # Re: Broker de messages
Posté par Dring . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 2.
Une architecture possible c'est :
J'ai pas encore de bonne vision de Kafka, mais j'ai cru comprendre qu'une gestion fine des permissions pouvait être un peu complexe, là où les APIs s'appuient sur le mécanisme "naturel" des applications. D'où l'intérêt de ne pas publier trop de trucs. Le défaut, c'est que potentiellement, avec cette approche, si le consommateur prend trop de temps à aller chercher les données, il peut rater des états intermédiaires.
Evidemment, si on envoie aussi l'état intermédiaire dans le message, et que l'application source garde tous les états, c'est pas grave, mais c'est le type de situation où il est préférable d'envoyer plus de données dans l'évènement.
En entreprise, ce que j'ai souvent vu, c'est du MQ (donc du message point à point) où on balance l'ensemble des informations nécessaire pour le destinataire. C'est pas très beau d'un point de vue architecture, mais ça marche, et l'infra est adaptée pour supporter des gros volumes de gros messages. Moins de contraintes pour l'émetteur. Du vrai couplage faible.