En savoir plus sur Ruby on Rails avec Pub/Sub

Ruby on Rails (Rails, RoR) est un framework d'application web bien connu, écrit en langage Rubis langage de programmation. Pub/Sub est un nom abrégé des modèles de conception de logiciels appelés Publier-abonner. Je vais expliquer comment la communication entre les composants logiciels dans Rails pourrait être gérée par Pub/Sub.

Qu'est-ce que Pub/sub ?

Pub/sub est un modèle de conception logicielle permettant la communication entre services. Service
implique l'un des deux rôles suivants : éditeur (qui produit) ou récepteur (qui consomme). Qu'est-ce qui est
Le produit à consommer est déterminé comme un événement, un message ou une notification. Dans le
Dans le contexte de cet article, ces termes sont utilisés de manière interchangeable pour désigner la même chose.
Le service qui produit ne sait pas qui consomme. Le service qui consomme ne sait pas
connaître l'origine du message. Ils peuvent rester inconnus l'un de l'autre. C'est différent de
les files d'attente de messages, où le composant qui envoie le message connaît souvent sa destination
- ce type de messagerie permet d'envoyer des messages n'importe où. Ce mécanisme est un élément central de la
de Pub/sub et cela signifie qu'ils sont découplés.

Pour exprimer leurs intérêts mutuels, ils doivent partager une compréhension commune. C'est pourquoi,
les deux rôles ont un mécanisme implicite du bâton où le producteur d'un message et le destinataire de ce message ont un rôle à jouer.
consommateur du message rencontré. Ce mécanisme est appelé sujet, abonnement ou thème. Il est
chargé de classer les messages en fonction des sujets, il s'agit essentiellement d'un filtre de messages sans état.
Les thèmes agissent comme des stations de diffusion. Un éditeur produit le message pour le sujet,
reçoivent immédiatement le message du sujet. En raison du découplage des
la manière la plus efficace d'échanger des messages est de les traiter de manière asynchrone.

Rails sans Pub/Sub

Par défaut, il n'y a pas de surcharge Rails pour les modèles de conception de logiciels pour le passage de messages entre les composants. Les développeurs utilisent des la programmation orientée objet (OOP) : passer des paramètres aux fonctions, demander des classes sur les valeurs.

Lorsque l'application est relativement simple, cela peut suffire. Lorsque l'application se développe, par exemple, certaines opérations doivent être effectuées de manière asynchrone, alors l'option projet a besoin d'une abstraction qui résout ce flux de données. Plutôt que de réinventer la roue, les développeurs peuvent mettre en œuvre le système Pub/sub pour combler ce manque d'abstraction.

Avantages de Pub/Sub avec Rails

• Éviter les rappels d'enregistrements actifs.
• L'ajout d'un traitement parallèle asynchrone à un système permet d'améliorer les performances, la fiabilité et l'évolutivité.
• Les messages peuvent être diffusés de manière asynchrone à différentes parties du système.
• Permet de diffuser des messages de manière asynchrone à différentes parties d'un système.
• Découplage - l'ajout ou la modification d'une fonctionnalité n'aura pas d'incidence sur quoi que ce soit parce que Pub/Sub
  vous permet de modifier la façon dont tout interagit.
• Le consommateur de messages n'aura plus besoin de vérifier périodiquement s'il y a des mises à jour ou de nouveaux messages.
  l'information. Il réduit le temps de latence qui peut s'avérer particulièrement problématique dans les systèmes
  sans aucune tolérance pour les retards.
• Il n'y a pas de limite au nombre d'abonnés que le système peut prendre en charge, car il peut changer,
  s'améliorer, se multiplier ou disparaître à tout moment.

Inconvénients de Pub/Sub avec Rails

• Le principal inconvénient des systèmes Pub/sub est leur découplage de l'éditeur et de l'utilisateur.
  abonné.

Rails Pub/Sub introduire

Les exemples de sources dans Rails ont été écrits à l'aide de la bibliothèque
Pub/Sub sur Rails (dans la nomenclature Ruby, une bibliothèque est appelée gem) : Vous trouverez plus de détails dans le readme de la gem. L'implémentation est composée de modules :

1. Domaine,
2. Événement,
3. Gestionnaire d'événements,
4. Éditeur de l'événement,
5. Abonnement.

Domaine

Décrit la logique d'entreprise afin de fournir un contexte pour Pub/Sub et, par conséquent, de rendre propre la logique d'entreprise. code.

 module Notifications
   extend PubSub::Domaine
 fin

 module Rapports
   extend PubSub::Domaine
 fin

Événement

Il s'agit d'une classe qui décrit ce qui s'est passé. Le nom de la classe doit décrire lui-même ce qui s'est passé, par exemple : annulé, modifié, créé, détruit, envoyé, mis à jour. Les noms d'événements peuvent ressembler à ce qui suit : ProfitAndLossStatementCreatedEvent, qui signifie qu'un état financier a été créé.

 class Reports::ProfitAndLossStatementCreatedEvent < PubSub::DomainEvent
   attribut :profit_and_loss_statement_id, Types::Strict::Integer
 end

Éditeur d'événements

Classe capable d'émettre des événements. L'exemple montre la création d'un rapport de service. Lorsque le rapport a été créé avec succès, l'événement de création de ce rapport est émis.

class Reports::ProfitAndLossStatementService
   include PubSub::Emit
    def execute
     emit(:report_profit_and_loss_statement_created, profit_and_loss_statement_id : id) if result.ok ?
   end
 end

Gestionnaire d'événements

Cette classe doit être exécutée en réponse au traitement d'un événement.

module Notifications
 class ReportsProfitAndLossStatementCreatedHandler < PubSub::DomainEventHandler
   def call
     ReportMailer.profit_and_loss_statement(profit_and_loss_statement).deliver_now
   end

   private

   def profit_et_loss_statement
     ProfitAndLossStatement.find(event_data.profit_and_loss_statement_id)
   end
 end
end

Abonnement

Les événements sont liés à leurs gestionnaires par le biais d'abonnements.

notifications :
 reports__profit_and_loss_statement_created : async

Exemples de cas d'utilisation :

• Fonction "Suivre" dans les réseaux sociaux,
• Internet des objets,
• Courrier,
• Notification des fichiers générés.

Modèles similaires

1. EventBus - peuvent envoyer des événements à EventBus sans savoir qui les prendra ou combien de personnes y réagiront,
2. Observateur - le sujet tient à jour une liste de dépendants, appelés observateurs, et les informe de tout changement d'état,
3. Mise en commun - lors de l'interrogation, les clients demandent périodiquement au système s'il y a de nouveaux événements ou de nouvelles données.

Pierres précieuses

• https://github.com/edisonywh/rocketman

• https://github.com/krisleech/wisper

• https://github.com/stevo/pubsubsurrails

Résumé

Pub/sub n'est pas une approche courante dans Ruby in Rails. Comme présenté dans l'article, ce modèle peut apporter de nombreux avantages au projet - il peut rendre le code propre, découpler les services et les rendre facilement évolutifs.