(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s), dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-5LHNRP9'); thecodest, Autore presso The Codest - Pagina 7 di 9

Rubino su Rotaie (Rails, RoR) è un noto web di applicazioni scritte nel linguaggio Rubino linguaggio di programmazione. Pub/Sub è un nome abbreviato di modelli di progettazione del software chiamati Pubblicare-sottoscrivere. Spiegherò come la comunicazione tra componenti software in Rails possa essere gestita da Pub/Sub.

Che cos'è Pub/sub?

Pub/sub è un modello di progettazione del software che prevede la comunicazione da servizio a servizio. Servizio
comporta uno dei due ruoli: editore (chi produce) o destinatario (chi consuma). Che cosa è
prodotto da consumare è determinato come un evento o un messaggio o una notifica. Nella
Nel contesto di questo articolo, i due termini sono usati in modo intercambiabile per indicare la stessa cosa.
Il servizio che produce non sa chi consuma. Il servizio che consuma non
conoscere l'origine del messaggio. Possono rimanere sconosciuti l'uno all'altro. È diverso da
code di messaggi, in cui il componente che invia il messaggio spesso conosce la sua destinazione
- Questo stile di messaggistica consente di inviare messaggi ovunque. Questo meccanismo è un elemento fondamentale
di Pub/sub e significa che sono disaccoppiati.

Per esprimere i loro interessi reciproci, devono condividere una comprensione comune. Pertanto,
entrambi i ruoli hanno un meccanismo implicito di bastone dove il produttore di un messaggio e il
consumatore del messaggio incontrato. Questo meccanismo è chiamato soggetto, sottoscrizione o argomento. È
responsabile della categorizzazione dei messaggi ai soggetti, è essenzialmente un filtro di messaggi senza stato.
I temi agiscono come stazioni di trasmissione. Un editore produce il messaggio per l'argomento,
gli abbonati ricevono immediatamente il messaggio dall'argomento. A causa del disaccoppiamento
il modo più efficiente di scambiare messaggi è quello di gestirli in modo asincrono.

Rails senza Pub/Sub

Per impostazione predefinita, non esiste un overhead di Rails per i modelli di progettazione del software per il passaggio dei messaggi tra i componenti. Gli sviluppatori usano lo standard programmazione orientata agli oggetti (OOP): passaggio di parametri alle funzioni, richiesta di classi sui valori.

Quando l'applicazione è piuttosto semplice, potrebbe essere sufficiente. Quando l'applicazione cresce, ad esempio, alcune operazioni devono essere eseguite in modo asincrono, allora l'opzione progetto ha bisogno di un'astrazione che risolva il problema dati flusso di lavoro. Invece di reinventare la ruota, gli sviluppatori possono implementare Pub/sub per colmare questa mancanza di astrazione.

Pro di Pub/Sub con Rails

Contro di Pub/Sub con Rails

Rails Pub/Sub introduce

Gli esempi di sorgente in Rails sono stati scritti utilizzando la libreria
Pub/Sub su Rails (nella nomenclatura di Ruby, una libreria è chiamata gemma): Maggiori dettagli si trovano nel readme della gemma. L'implementazione è composta da moduli:

  1. Dominio,
  2. Evento,
  3. Gestore dell'evento,
  4. Editore dell'evento,
  5. Abbonamento.

Dominio

Descrive la logica di business per fornire un contesto a Pub/Sub e, quindi, per rendere più pulito il sistema. codice.

 modulo Notifiche
   estendere PubSub::Domain
 fine
 modulo Rapporti
   estendere PubSub::Domain
 fine

Evento

È una classe che descrive ciò che è accaduto. Il nome della classe deve essere il più possibile autodescrittivo dell'evento, ad esempio: cancellato, modificato, creato, distrutto, inviato, aggiornato. I nomi degli eventi possono essere simili a: ProfitAndLossStatementCreatedEvent, che significa che è stato creato un rendiconto finanziario.

 class Reports::ProfitAndLossStatementCreatedEvent < PubSub::DomainEvent
   attributo :profit_and_loss_statement_id, Types::Strict::Integer
 fine

Editore dell'evento

Classe in grado di emettere eventi. L'esempio mostra la creazione di un rapporto di servizio. Quando il report è stato creato con successo, emette l'evento di creazione del report.

classe Reports::ProfitAndLossStatementService
   include PubSub::Emit
    def eseguire
     emit(:report_profit_and_loss_statement_created, profit_and_loss_statement_id: id) if result.ok?
   fine
 fine

Gestore dell'evento

Questa classe deve essere eseguita in risposta alla gestione di un evento.

modulo Notifiche
 classe ReportsProfitAndLossStatementCreatedHandler < PubSub::DomainEventHandler
   def chiama
     ReportMailer.profit_and_loss_statement(profit_and_loss_statement).deliver_now
   fine

   privato

   def dichiarazione_profitto_e_perdita
     ProfitAndLossStatement.find(event_data.profit_and_loss_statement_id)
   fine
 fine
fine

Abbonamento

Gli eventi sono legati ai loro gestori tramite sottoscrizioni.

notifiche:
 reports__profit_and_loss_statement_created: async

Esempi di casi d'uso:

Modelli simili

  1. EventoBus - I componenti possono inviare eventi a EventBus senza sapere chi li raccoglierà o quanti rispondono reagire,
  2. Osservatore - il soggetto mantiene un elenco di persone dipendenti, chiamate osservatori, e le notifica ogni volta che il loro stato cambia,
  3. Messa in comune - In fase di polling, i client chiedono periodicamente al sistema se ci sono nuovi eventi o dati.

Gemme

Sintesi

Pub/sub non è un approccio comune in Ruby in Rails. Come introdotto nell'articolo, questo pattern può portare molti vantaggi al progetto: può rendere il codice pulito, disaccoppiare i servizi e renderli facilmente scalabili.

banner di cooperazione
it_ITItalian