thecodest, Författare på The Codest

Ruby på Räls (Rails, RoR) är en välkänd webb applikationsramverk som är skrivet i Ruby programmeringsspråk. Pub/Sub är ett kort namn på designmönster för programvara som kallas Publicera och prenumerera. Jag ska förklara hur kommunikation mellan programvarukomponenter i Rails kan hanteras med Pub/Sub.

Vad är Pub/sub?

Pub/sub är ett designmönster för programvara som möjliggör kommunikation mellan tjänster. Tjänst
innebär en av de två rollerna: utgivare (som producerar) eller mottagare (som konsumerar). Vad är
som ska konsumeras bestäms som en händelse eller ett meddelande eller en notifiering. I
i denna artikel används de synonymt för att referera till samma sak.
Tjänsten som producerar vet inte vem som konsumerar. Tjänsten som konsumerar vet inte
känna till meddelandets ursprung. De kan förbli okända för varandra. Det skiljer sig från
meddelandeköer, där den komponent som skickar meddelandet ofta känner till dess destination
- Den här typen av meddelanden gör att du kan skicka meddelanden var som helst. Denna mekanism är en central
av Pub/sub och det betyder att de är frikopplade.

För att kunna uttrycka sina ömsesidiga intressen måste de ha en gemensam förståelse. Det är därför,
båda rollerna har en implicit pinnmekanism där producenten av ett meddelande och mottagaren av
konsument av meddelandet möts. Denna mekanism kallas ämne, prenumeration eller topic. Den är
ansvarar för att kategorisera meddelanden till ämnen, är det i huvudsak ett statlöst meddelandefilter.
Ämnen fungerar som sändningsstationer. En utgivare producerar meddelandet till ämnet,
prenumeranterna omedelbart får meddelandet från ämnet. På grund av den frikopplade
är det mest effektiva sättet att utbyta meddelanden att hantera dem asynkront.

Rails utan Pub/Sub

Som standard finns det ingen Rails-overhead för mjukvarudesignmönster för att skicka meddelanden mellan komponenter. Utvecklare använder standard objektorienterad programmering (OOP) paradigm: skicka parametrar till funktioner, fråga efter klasser om värden.

När applikationen är ganska okomplicerad kan det räcka. När applikationen växer, t.ex. när vissa operationer måste utföras asynkront, kan projekt behöver en abstraktion som löser det data arbetsflöde. Istället för att uppfinna hjulet på nytt kan utvecklare implementera Pub/sub för att fylla denna brist på abstraktion.

Fördelar med Pub/Sub med Rails

Undvik återkallelser i Active Record.
Genom att lägga till asynkron parallellbearbetning i ett system förbättras prestanda, tillförlitlighet och Skalbarhet är förbättrade.
Meddelanden kan sändas asynkront till olika delar av systemet.
Gör det möjligt att sända meddelanden asynkront till olika delar av ett system.
Frikoppling - att lägga till eller ändra en funktion påverkar inte något annat eftersom Pub/Sub
kan du ändra hur allt samverkar.
Meddelandekonsumenten behöver inte längre regelbundet kontrollera om det finns uppdateringar eller nya
information. Det minskar leveransfördröjningen som kan vara särskilt problematisk i system
med ingen tolerans för förseningar.
Det finns ingen gräns för hur många abonnenter systemet kan hantera eftersom det kan ändras,
uppgraderas, mångfaldigas eller försvinna när som helst.

Nackdelar med Pub/Sub med Rails

Den största nackdelen med Pub/sub-system är att de inte kopplar ihop utgivare och
abonnent.

Rails Pub/Sub införa

Exempel på källkod i Rails skrevs med hjälp av biblioteket
Pub/Sub på Rails (i Rubys nomenklatur kallas ett bibliotek för gem): Du hittar mer information i gemens readme. Implementeringen består av moduler:

Domän,
Händelse,
Händelsehanterare,
Utgivare av evenemang,
Prenumeration.

Domän

Beskriver affärslogiken för att ge Pub/Sub ett sammanhang och därmed göra den ren kod.

 modul Meddelanden
   extend PubSub::Domän
 avsluta

 modul Rapporter
   extend PubSub::Domän
 avsluta

Händelse

Det är en klass som beskriver vad som hände. Deklarera klassnamnet så självbeskrivande med vad som hände som möjligt, till exempel: cancelled, changed, created, destroyed, sent, updated. Händelsenamn kan se ut som: ProfitAndLossStatementCreatedEvent, vilket innebär att en finansiell rapport skapades.

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

Utgivare av evenemang

Klass som kan avge händelser. Exemplet visar hur man skapar en servicerapport. När rapporten har skapats, emitterar du händelsen för att skapa rapporten.

class Reports::Vinst-och-förlustredovisningService
   inkluderar PubSub::Emit
    def exekvera
     emit(:report_profit_and_loss_statement_created, profit_and_loss_statement_id: id) if result.ok?
   end
 slut

Händelsehanterare

Denna klass bör exekveras som svar på hanteringen av en händelse.

modul Notifieringar
 class ReportsProfitAndLossStatementCreatedHandler < PubSub::DomainEventHandler
   def anrop
     ReportMailer.vinst_och_förlustutlåtande(vinst_och_förlustutlåtande).deliver_now
   slut

   privat

   def vinst_och_förlust_uttalande
     ProfitAndLossStatement.find(event_data.profit_and_loss_statement_id)
   slut
 slut
slut

Prenumeration

Händelser kopplas till sina hanterare genom prenumerationer.

meddelanden:
 rapporter__vinst_och_förlust_uträkning_skapad: async

Exempel på användningsområden:

"Följ"-funktionen i sociala nätverk,
Sakernas internet,
Mailing,
Meddelande om genererade filer.

Liknande mönster

EventBus - komponenter kan skicka evenemang till EventBus utan att veta vem som ska hämta dem eller hur många som kommer att reagera,
Observatör - upprätthåller subjektet en lista över beroende parter, så kallade observatörer, och meddelar dem när deras tillstånd ändras,
Poolning - Vid polling frågar klienterna regelbundet systemet om det finns några nya händelser eller data.

Ädelstenar

Sammanfattning

Pub/sub är inte ett vanligt tillvägagångssätt i Ruby in Rails. Som introduceras i artikeln kan detta mönster ge många fördelar för projektet - det kan göra koden ren, frikoppla tjänster och göra dem lätt skalbara.