Utformet arkitekturen for en lagdelt maritim plattform som skiller en Next.js PWA‑frontend, et Go‑API (Huma/Fiber) og et funksjonslag i PostgreSQL, med all forretningslogikk i databasen.

Situasjon. Produktet skulle bli en maritim plattform — profesjonell nettverksbygging, omtaler av selskaper, sponset opplæring — og det var et ungt produkt, som er en høflig måte å si på at kravene kom til å flytte seg mye. Det man ville unngå, var en arkitektur der en endret forretningsregel betydde å røre frontenden, API‑et og databasen på én gang. I en liten kodebase som vokser raskt, er det den typen kobling som gjør en endring på to linjer om til en hel ettermiddag.

Oppgave. I arkitektrollen var beslutningen som måtte tas i forkant, hvor hver type logikk skulle ligge, med grenser som var tydelige nok til å holde under press i stedet for å viskes ut første gang noen hadde dårlig tid.

Handling. Det endte med tre lag, med én jobb hver. Next.js‑frontenden tar seg av presentasjon og interaktivitet og ingenting annet. Go‑API‑et — Huma over Fiber — er bevisst tynt: det ruter, validerer forespørselen, anvender sikkerhetsfiltreringen og orkestrerer, men det inneholder ingen forretningslogikk i det hele tatt. All forretningslogikken ligger i PostgreSQL‑funksjoner, som setter sammen hele resultatet og gir det tilbake slik at API‑et kan videresende det. Når en regel endres, endres den derfor i ett lag, i SQL, og de to andre trenger ikke å vite om det. Grensene ble skrevet ned og deretter håndhevet i kodegjennomgangen, fordi en konvensjon som ingen passer på, slutter å være en.

Resultat. Det hele forble lett å holde i hodet. Forretningslogikken ligger på ett sted du faktisk kan revidere, API‑et er en kjedelig adapter i god forstand, og frontenden bryr seg ikke når skjemaet endres under den. Det skillet er det som gjorde at nye funksjoner kunne fortsette å bli hengt på produktet uten at arkitekturen i det stille råtnet.