Har arkitekteret en lagdelt maritim platform, der adskiller en Next.js PWA‑frontend, et Go (Huma/Fiber) API og et PostgreSQL‑funktionslag og holder al forretningslogik i databasen.

Situation. NextMariner skulle være en maritim platform — professionelt netværk, virksomhedsanmeldelser, sponsoreret uddannelse — og det var et ungt produkt, hvilket er en pæn måde at sige, at kravene ville flytte sig en hel del. Det, der skulle undgås, var en arkitektur, hvor en ændret forretningsregel betød, at man skulle røre frontenden, API’et og databasen på én gang. På en lille kodebase, der vokser hurtigt, er det den slags kobling, der gør en to‑linjers ændring til en hel eftermiddag.

Opgave. Som arkitekt var beslutningen på forhånd, hvor hver slags logik boede, med grænser tydelige nok til at holde under pres, i stedet for at blive udvisket første gang nogen havde travlt.

Handling. Det landede på tre lag, ét job hver. Next.js‑frontenden står for præsentation og interaktivitet og intet andet. Go‑API’et — Huma oven på Fiber — er bevidst tyndt: det router, validerer requesten, laver sikkerhedsfiltreringen og orkestrerer, men det rummer slet ingen forretningslogik. Forretningslogikken bor i PostgreSQL‑funktioner, som samler det fulde resultat og giver det tilbage, som API’et videresender. Så når en regel ændrer sig, ændrer den sig i ét lag, i SQL, og de to andre behøver ikke vide det. Grænserne blev skrevet ned og håndhævet i review, for en konvention, ingen holder øje med, holder op med at være en.

Resultat. Tingen forblev nem at holde i hovedet. Forretningslogikken sidder ét sted, man faktisk kan revidere, API’et er en kedelig adapter på den gode måde, og frontenden er ligeglad, når skemaet flytter sig under den. Den adskillelse er det, der lod produktet blive ved med at skrue funktioner på, uden at arkitekturen stille og roligt rådnede.