Har designet en JSON‑passthrough‑arkitektur

Situation. Normalt kommer data fra en database til en browser gennem et stafetløb af transformationer. Databasen giver API’et rækker, API’et unmarshaller dem til structs, omformer dem, serialiserer dem tilbage til JSON, og først derefter bliver de sendt ud. Hvert af de led er kode, man skriver, kode, man tester, og endnu et sted, hvor API’ets opfattelse af dataene og databasens kan glide fra hinanden.

Opgave. Idéen var at springe stafetløbet over. Hvis databasen kunne returnere det færdige svar, kunne API’et bare sende det videre, og frontenden kunne bygge direkte på databasens struktur i stedet for på en håndvedligeholdt kopi af den i Go.

Handling. Så det blev bygget som en ren passthrough. PostgreSQL‑funktionerne samler hele svaret som JSON — formgivningen er en SQL‑opgave og sker der, hvor dataene allerede ligger. Go‑handleren tager imod det som json.RawMessage og sender det videre uændret; den pakker det aldrig ud og koder det aldrig om. En lille QueryJSON‑helper gjorde mønstret til den letteste vej i stedet for noget, man skulle huske at gøre. Det, der faldt bort, var alt det mellemliggende maskineri, som et konventionelt lagdelt API samler på sig — DTO’erne, mapperne, svar‑structene.

Resultat. Handler‑koden blev markant kortere, og hvad der vejer tungere: frontenden holdt op med at være koblet til Go. Ændrer man, hvad en funktion returnerer, løber den nye struktur direkte igennem til klienten, uden at nogen retter en linje handler‑kode. Færre bevægelige dele, og en hel kategori af afvigelser mellem lagene findes simpelthen ikke her.