Ruby på Rails (Rails, RoR) er en velkjent nett applikasjonsrammeverk skrevet i Ruby programmeringsspråk. Pub/Sub er et kort navn på programvaredesignmønstre som kalles Publiser-abonnement. Jeg skal forklare hvordan kommunikasjon mellom programvarekomponenter i Rails kan håndteres av Pub/Sub.

Hva er Pub/sub?

Pub/sub er et programvaredesignmønster som muliggjør tjeneste-til-tjeneste-kommunikasjon. Tjeneste
innebærer en av de to rollene: utgiver (som produserer) eller mottaker (som konsumerer). Hva er
som skal konsumeres, bestemmes som en hendelse eller en melding eller et varsel. I
I denne artikkelen brukes de om hverandre for å referere til det samme.
Tjenesten som produserer, vet ikke hvem som forbruker. Tjenesten som forbruker vet ikke
vet hvor meldingen kommer fra. De kan forbli ukjente for hverandre. Det er forskjellig fra
meldingskøer, der komponenten som sender meldingen ofte kjenner destinasjonen
- Denne meldingsformen gjør det mulig å sende meldinger hvor som helst. Denne mekanismen er en sentral
av Pub/sub og det betyr at de er frakoblet.

For å uttrykke sine felles interesser må de ha en felles forståelse. Derfor må de ha en felles forståelse,
Begge rollene har en implisitt mekanisme hvor produsenten av en melding og mottakeren av
forbruker av meldingen møtes. Denne mekanismen kalles emne, abonnement eller topic. Den er
er ansvarlig for å kategorisere meldinger til subjekter, og er i hovedsak et tilstandsløst meldingsfilter.
Emner fungerer som kringkastingsstasjoner. En publisher produserer meldingen til emnet,
abonnenter mottar umiddelbart meldingen fra emnet. På grunn av den frikoblede
tjenester, er den mest effektive måten å utveksle meldinger på å håndtere dem asynkront.

Rails uten Pub/Sub

Som standard er det ingen Rails-overhead for programvaredesignmønstre for overføring av meldinger mellom komponenter. Utviklere bruker standard objektorientert programmering (OOP) paradigmet: sende parametere til funksjoner, be om klasser om verdier.

Når applikasjonen er ganske ukomplisert, kan det være nok. Når applikasjonen vokser, for eksempel når noen operasjoner må utføres asynkront, kan prosjekt trenger en abstraksjon som løser det data arbeidsflyt. I stedet for å finne opp hjulet på nytt, kan utviklere implementere Pub/sub for å fylle denne mangelen på abstraksjon.

Fordeler med Pub/Sub med Rails

• Unngå tilbakekallinger av aktive poster.
• Ved å legge til asynkron parallellprosessering i et system kan ytelse, pålitelighet og skalerbarhet er forbedret.
• Meldinger kan sendes asynkront til ulike deler av systemet.
• Gjør det mulig å sende meldinger asynkront til ulike deler av et system.
• Frikobling - å legge til eller endre en funksjonalitet vil ikke påvirke noe fordi Pub/Sub
  kan du endre hvordan alt samhandler.
• Meldingskonsumenten trenger ikke lenger å se etter oppdateringer eller nye
  informasjon. Det reduserer leveringsforsinkelsen som kan være spesielt problematisk i systemer som
  uten toleranse for forsinkelser.
• Det finnes ingen grense for hvor mange abonnenter systemet kan håndtere, fordi det kan endre seg,
  oppgradere, formere seg eller forsvinne når som helst.

Ulemper med Pub/Sub med Rails

• Den største ulempen med Pub/sub-systemer er at de er frikoblet fra publisher og
  abonnent.

Rails Pub/Sub introdusere

Eksempler på kildekode i Rails ble skrevet ved hjelp av biblioteket
Pub/Sub på Rails (i Rubys nomenklatur kalles et bibliotek gem): Du finner flere detaljer i gems readme. Implementasjonen består av moduler:

1. Domene,
2. Arrangement,
3. Hendelsesbehandler,
4. Utgiver av arrangementet,
5. Abonnement.

Domene

Beskriver forretningslogikk for å gi kontekst for Pub/Sub og dermed gjøre den ren kode.

 modul Notifications
   extend PubSub::Domain
 end

 modul Rapporter
   extend PubSub::Domain
 end

Arrangement

Det er en klasse som beskriver hva som har skjedd. Deklarer klassenavnet så selvbeskrivende med det som skjedde som mulig, for eksempel: kansellert, endret, opprettet, ødelagt, sendt, oppdatert. Hendelsesnavn kan se slik ut: ProfitAndLossStatementCreatedEvent, som betyr at det ble opprettet et regnskap.

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

Utgiver av arrangementet

Klasse som kan sende ut hendelser. Eksempelet viser oppretting av en tjenesterapport. Når rapporten er opprettet, sendes hendelsen for opprettelse av rapporten ut.

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

Hendelsesbehandler

Denne klassen skal kjøres som svar på håndtering av en hendelse.

modul Notifications
 class ReportsProfitAndLossStatementCreatedHandler < PubSub::DomainEventHandler
   def call
     ReportMailer.resultat_og_tap_oppstilling(resultat_og_tap_oppstilling).deliver_now
   end

   private

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

Abonnement

Hendelser er knyttet til håndtererne sine gjennom abonnementer.

notifications:
 rapporter__overskudd_og_underskudd_oppstilling_opprettet: async

Eksempler på brukstilfeller:

• "Følg"-funksjonen i sosiale nettverk,
• Tingenes internett,
• Mailing,
• Varsling om genererte filer.

Lignende mønstre

1. EventBus - komponenter kan sende hendelser til EventBus uten å vite hvem som vil plukke dem opp eller hvor mange respondenter som vil reagere,
2. Observatør - opprettholder subjektet en liste over avhengige personer, kalt observatører, og varsler dem når tilstanden deres endres,
3. Sammenslåing - Ved polling spør klientene systemet med jevne mellomrom om det finnes nye hendelser eller data.

Edelstener

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

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

• https://github.com/stevo/pubsubpåskinner

Sammendrag

Pub/sub er ikke en vanlig tilnærming i Ruby in Rails. Som introdusert i artikkelen, kan dette mønsteret gi mange fordeler for prosjektet - det kan gjøre koden ren, frakoble tjenester og gjøre dem enkelt skalerbare.