Serverside programmering — sproget der kører bag kulissen

Serverside programmering er den kode, der kører på en server frem for i brugerens browser. Det er her, forretningslogikken bor: at tjekke om en bruger må se en side, at hente og gemme data i databasen, og at levere svar til frontend. Bekendtgørelsen for webudvikleruddannelsen kræver, at eleven selvstændigt kan arbejde med serverside programmering i forhold til fremstilling af webløsninger og koblingen til datakilder og bagvedliggende systemer.

§Sproget betyder mindre, end man tror

Der findes mange sprog og miljøer til serverside-udvikling — for eksempel JavaScript i et server-miljø, PHP, Python, Java og C#. De adskiller sig i syntaks og økosystem, men løser stort set de samme grundopgaver: modtage en forespørgsel, tale med en database, anvende forretningsregler og sende et svar tilbage. At have forstået principperne i ét sprog gør det langt lettere at sætte sig ind i et andet, når arbejdspladsen kræver det.

§HTTP er statsløst — derfor findes sessioner

HTTP, protokollen bag stort set al webtrafik, er statsløs: serveren husker som udgangspunkt intet fra én forespørgsel til den næste. Uden noget ekstra ville en server derfor ikke vide, om to forespørgsler kommer fra samme indloggede bruger. Løsningen er at lade serveren udstede noget, browseren sender med tilbage hver gang — typisk en session-cookie eller en token — som serveren kan slå op og genkende. Sådan holdes en bruger 'logget ind', selvom hver enkelt HTTP-forespørgsel i virkeligheden står alene.

• 01Session: serveren gemmer tilstanden og giver klienten kun et referencenummer
• 02Token (fx en signeret adgangsnøgle): tilstanden ligger i selve tokenet, som serveren kan verificere uden opslag
• 03Begge dele skal beskyttes mod at blive stjålet eller gættet, og skal kunne udløbe

§Miljøvariabler og hemmeligheder

En server skal ofte kende hemmeligheder: adgangskoden til databasen, nøgler til eksterne tjenester, den værdi der bruges til at signere sessioner. De hører aldrig hjemme direkte i kildekoden eller i versionsstyringen, hvor de kan læses af alle med adgang til repoet. I stedet sættes de som miljøvariabler på den server, koden kører på, uden for det, der committes til Git — den samme tankegang, artiklen om GDPR og web-sikkerhed lægger vægt på.

§Webserverens ydeevne

Bekendtgørelsen kræver også kendskab til webservere, herunder ydeevne og funktionalitet. En webserver skal kunne håndtere mange samtidige forespørgsler uden at gå i knæ. Det, der typisk afgør ydeevnen, er, hvor hurtigt hver forespørgsel besvares (fx hvor effektive databaseopslagene er), om svar, der ikke ændrer sig ofte, caches i stedet for at genberegnes hver gang, og om serveren kan skalere ved at køre flere eksemplarer parallelt, når belastningen stiger.

§Fra kode til kørende tjeneste

Serverside-kode er ikke færdig, før den rent faktisk kører et sted, brugerne kan nå. Det kræver, at koden pakkes, sættes op med de rigtige miljøvariabler og overvåges, så fejl opdages, før brugerne selv finder dem — emnet, den næste artikel om deployment og drift går videre med.

“Frontend er det, brugeren ser. Backend er det, der afgør, om det, brugeren ser, overhovedet er sandt og sikkert.”

— Almindelig læreregel i webudvikling