Gjentatte ganger tilbaketrekking av programvareutvikling

Av | mars 19, 2022

Jeg trengte å legge til en funksjon i nettapplikasjonen vår, som krevde å ringe til en leverandørs eksterne nettjeneste. Denne samtalen måtte foretas kort tid etter at webapp-brukeren foretok et kjøp, inne i appen – men trengte ikke å skje med en gang.

I denne situasjonen vil du ikke foreta det eksterne API-kallet mens du håndterer brukerens nettforespørsel. Av alle mulige grunner.

Den «riktige» måten å gjøre dette på:

Sett opp en jobbkø, som asynkront vil sende den nettjenesteforespørselen.

Din webapp kan bare skyve oppgaven til denne køen, som er rask og pålitelig, og deretter raskt returnere svaret til kunden. Ikke ønsker å la dem vente, tross alt, spesielt når de nettopp ga deg penger.

Denne typen jobbkø er litt komplisert å sette opp, men ikke så verst. Og jeg hadde fire dager. God tid.

Så jeg begynte å gjøre det på «riktig måte» … og lang historie kort, det fungerte ikke.

Jeg opprettet en ny node som skulle være vert for Selleri – en Pythonic oppgavekø – støttet av RabbitMQ. Pluss et annet, ikke navngitt verktøy, som pakket inn denne noden i en fin microservice API.

Ukjent, for etter to dagers arbeid oppdaget jeg at dette verktøyet likte å feste CPU-en til 99 % hver eller annen time. Helt til jeg manuelt startet tjenesten på nytt.

Det viste seg at dette var en feil som oppstrøms hadde jobbet med i et ÅR. Jeg hadde ikke tenkt å løse det på egenhånd, på de to dagene jeg hadde igjen.

Jeg tenkte at på lang sikt var det bedre å sette opp den separate jobbkø-noden. Men jeg trengte å få utplassert denne funksjonen, og bestemte meg for å sette opp Celery sammen med Django, på samme node som webserveren kjørte på.

Jeg tenkte at det ville være raskt og enkelt. For vanligvis er det det.

Spoilervarsel: det var det ikke.

Faktisk, etter nok en hel dag, møtte jeg EN ANDEN show-stopper med den tilnærmingen. Jeg skal ikke engang kjede deg med å forklare hva det var – det var dumt og frustrerende. Men bunnlinjen, jeg kunne ikke gjøre det heller.

Så med bare noen få timer igjen … hva gjorde jeg?

Jeg satte opp en timebasert «cron»-jobb.

Hvis du ikke vet om Cron, er det et anlegg bakt inn i Linux (og Unix), som vil kjøre et skript for deg med jevne mellomrom. Den er enkel, bunnsolid, og jeg har brukt den en milliard ganger.

Så jeg skrev et raskt skript som ville sjekke hvem som kjøpte nylig, og lage API-en til den nettjenesten for hver av dem. Og jeg ba cron å kjøre den en gang i timen.

Fort og lett. Den har fungert bra i flere måneder nå, og gjør det den trenger å gjøre. Ingen problemer.

På et tidspunkt vil jeg gå tilbake og fikse min første tilnærming. Det er bedre hvis oppgaven kjører rett etter kjøpet, i stedet for en time senere, og vi vil til slutt trenge den separate oppgavekø-noden som kjører for andre ting, uansett.

Men jeg tror denne historien illustrerer noen praktiske aspekter ved å skrive programvare.

Noen ganger må vi gjøre taktiske retreater. Fordi å få implementert en ufullkommen løsning er ofte langt bedre enn en perfekt løsning sent. Og å være villig til å gjenkjenne når noe står i fare for å ikke fungere, og vi må endre tilnærmingen vår.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.