Har du noen gang sittet og ventet på en viktig e-post, bare for å oppdage at du oppdaterer innboksen hvert femte sekund? 🤔 Jepp, det har vi også (på et vis!)

I Snøkam har vi utviklet en TV-app som står og ruller på skjermene på kontoret. Tidligere sto disse og bombarderte API-ene våre, hvert minutt, for å sjekke om:

1. Det var noen pågående arrangementer, for å vise programmet for kvelden, eller bildene deltakerne har lastet opp 📸
2. Om det var noen nye filmer som skulle vises på skjermen. (yes, det kan vi også trigge fra systemene våre 😎 - hvem vil vel ikke mulighet til å vise Rick Astley på TV-en når vi har kjørt lønn)
3. Om partyspaken var aktiv! 🍻 Det er jo gøy med litt Tomorrowland i bakgrunnen når det er fest 🎉

Å manuelt kalle API-er på et gitt intervall er en rimelig ineffektiv og elendig måte å løse problemet på, og Kristoffer (økonomiansvarlig) begynte å rynke på nesen når vi fikk en faktura forrige måned.

Men, vet du hva? Det finnes en smartere måte å gjøre det på, slik at vi kan holde økonomiansvarlig blid og fornøyd 😃 Eller bare fordi det er grisefett med teknologi og arkitektur 🤓 Vi har herved sagt farvel til polling i Snøkam og innført meldings- og køsystemer i internsystemet. La oss snakke litt om hvorfor det gir mening.

Polling: Den gamle måten

Polling er som å stå utenfor døren til posten og spørre postmannen hvert minutt om det har kommet noe nytt. Rimelig slitsomt å stå der hele dagen og banke på døra. Vi brukte REST-APIer til å hente data med jevne mellomrom, noe som førte til mye unødvendig trafikk og høyere belastning på serverne våre.

Publisering: Den nye, kule måten

Så, hva gjør vi nå? Vi har innført meldings- og køsystemer som Azure Service Bus og Azure Web PubSub. I stedet for å sjekke kontinuerlig, kan vi nå bare lytte etter nye meldinger. Det er som å ha en personlig assistent som gir deg en vennlig dytt når det er noe nytt å vite!

Det vi har gjort i praksis, for å kickstarte den nye arkitekturen, er å sette opp en Webhook i Sanity, som vil si at Sanity sier ifra når noen gjør endringer i databasen vår, og det kan vi dytte videre i på en kø på Azure og reagere på når det skjer noe vi ønsker å ta stilling til i appene våre.

Noen fordeler

1. Lynraskt: Meldinger blir sendt og mottatt i sanntid, som betyr at applikasjoner kan reagere umiddelbart.
2. Pålitelighet: Meldinger vil aldri gå tapt så lenge de blir sendt. Om en tjeneste er nede vil meldingen ligge på lur til den fungerer igjen, og dermed blir håndtert.
3. Løs-kobling: Komponentene i systemet trenger ikke å vite om hverandre. Dette reduserer avhengigheter og gjør det enklere å vedlikeholde og oppdatere systemet uten å påvirke andre deler.
4. Feilhåndtering: Systemene har innebygde mekanismer for feilhåndtering, som dead letter queues, som hjelper til med å håndtere meldinger som ikke kan behandles, slik at de kan prosesseres på nytt.

Et annet eksempel

— som vi faktisk planlegger å implementere nå som dette er på plass!

Si at noen oppretter en ny ansatt i Sanity. Da vil denne meldingen bli broadcastet, og resten av appene våre, som f.eks power-office-function (timeføringssystemet vårt), kan lytte på meldingen og opprette en bruker. Og si cv-partner-function gjør det samme? Vipps, så er vi godt i gang med en automatisert onboardingsprosess.

Azure Service Bus fungerer knallbra internt i et selskap, hvor ulike systemer kan sende og lytte på meldinger mellom hverandre.

Men, det fungerer ikke ut av boksen til nettleseren til brukeren, så det har Azure løst ved innføringen av Azure Web PubSub, som kan sende live-oppdateringer og push-varsler rett til browseren. Det åpner opp en hel verden av muligheter. Rimelig smooth, sa du?

Så, neste gang du har laget et system og spammer F5 av en eller annen grunn, tenk på denne artikkelen.