Hvad er en server? En guide på almindeligt sprog for app-byggere

En server er en computer, eller et program, der kører på en, og som venter på anmodninger og svarer på dem. Når du åbner et website, sender din browser (klienten) en anmodning over internettet, og en server et sted sender siden, billederne eller dataene tilbage. Alle apps, du bruger, fra e-mail til netbank, er afhængige af servere, der gør dette millioner af gange om dagen.

Hvorfor servere betyder noget, når du bygger med AI

Når en AI-builder laver en app til dig, kører en del af koden i besøgendes browser, og en del kører typisk på en server. Serverdelen gør de ting, browseren ikke kan stoles på med, eller ikke selv kan gøre:

• Gemme og hente data fra en database.
• Holde hemmeligheder, fx betalings- eller AI-udbyderes API-nøgler, som aldrig må nå browseren.
• Kontrollere rettigheder, så en bruger kun kan se og ændre sine egne poster.
• Tale med andre tjenester: opkræve et kort, sende en e-mail, kalde en AI-model.

Når du ved, hvad serveren gør, forstår du, hvor din apps regler reelt bor, hvorfor nogle ændringer kræver en publicering igen, og hvad du betaler for, når du hoster en app. Om opdelingen mellem de to halvdele, se frontend vs. backend.

En hverdagsanalogi

En server er som ekspedienterne ved et posthus. De går ikke rundt og leder efter kunder; de venter. En kunde (klienten) kommer hen til disken med en anmodning: "send denne pakke", "har jeg post?" Ekspedienten håndterer det og rækker et resultat tilbage. Én ekspedient kan betjene mange kunder efter hinanden, og et travlt posthus åbner flere skranker.

Posthuset har også regler, kunden ikke kan omgå: du skal vise legitimation for at hente en pakke. Det er serverens job i en app også. Browseren kan bede om hvad som helst, men serveren afgør, hvad den får.

Sådan når en anmodning en server

Når nogen besøger https://bookings.example.com/schedule:

1. DNS-opslag. Browseren spørger domænenavnssystemet, hvilken IP-adresse bookings.example.com peger på. Se hvordan domæner og DNS virker.
2. Forbindelse. Browseren forbinder til den adresse på port 443 for HTTPS og opretter en krypteret forbindelse. Se hvad HTTPS er.
3. Anmodning. Den sender en HTTP-anmodning: GET /schedule.
4. Arbejde. Serveren kører den kode, der håndterer /schedule, måske ved at slå dagens bookinger op i databasen.
5. Svar. Den sender en statuskode (200 OK) og indholdet tilbage: en HTML-side eller JSON-data, siden skal vise.

Alt det tager som regel en brøkdel af et sekund.

Typer af servere, du vil høre om

Bemærk, at "server" betyder både maskinen og programmet. "Serveren gik ned" kan betyde begge.

Et konkret eksempel: en bookingapp for en frisør

Her er, hvad serveren gør i en lille bookingapp til en salon:

• En besøgende åbner siden. Serveren (eller et CDN foran den) sender sidefilerne.
• Siden spørger serveren GET /api/slots?date=2026-10-03. Serveren forespørger databasen for ledige tider og returnerer dem som JSON.
• Den besøgende booker kl. 14:00. Siden sender POST /api/bookings. Serveren kontrollerer, at tiden stadig er ledig. Den stoler ikke på browserens påstand. Den gemmer bookingen og returnerer 201 Created.
• Serveren kalder en e-mailtjeneste med en hemmelig nøgle, der ligger på serveren, for at sende en bekræftelse.

Hvis du slukkede serveren, kunne siden måske stadig indlæses fra et CDN, men den kunne ikke vise tider eller gemme bookinger.

Hvad en server har brug for for at køre godt

• Hukommelse (RAM) og CPU. For lidt hukommelse, og appen går ned under belastning; for lidt CPU, og den bliver langsom.
• At køre. En server, der er slukket, kan ikke svare. Nogle platforme sætter inaktive apps i dvale og vækker dem ved næste besøg, hvilket sparer penge, men kan gøre første anmodning langsommere.
• Konfiguration og hemmeligheder, givet som miljøvariabler.
• Logs, serverens optegnelse over, hvad der skete, og det første, du kigger i, når noget går i stykker.
• Opdateringer og sikkerhedsrettelser, som administreret hosting håndterer for dig.

Almindelige misforståelser

• "Cloud betyder, at der ikke er servere." Cloud er andre firmaers servere, lejet pr. time eller efter forbrug.
• "En server er en stor, speciel computer." Enhver computer kan fungere som server. Din bærbare kører en, når du åbner localhost under udvikling.
• "Hvis knappen er skjult, kan brugerne ikke gøre det." Enhver kan sende anmodninger direkte til din server. Rettighedstjek skal ske på serveren, ikke kun på siden.
• "Flere servere løser langsomhed." Ofte er den reelle årsag en langsom databaseforespørgsel eller en ekstern API. Find flaskehalsen først.
• "Jeg skal administrere en server for at have en app." Administrerede platforme kører serverne for dig; du deployer kode, og de håndterer maskinerne.

Hvad du kan spørge din AI-builder om

• "Hvilke dele af denne app kører på serveren, og hvilke kører i browseren?"
• "Behold alle API-nøgler på serveren, og læs dem fra miljøvariabler."
• "Kontrollér rettigheder på serveren for hver anmodning, der læser eller ændrer data."
• "Hvor finder jeg serverlogs, og hvad siger de om denne fejl?"
• "Har denne app overhovedet brug for en server, eller kan den være et statisk site?"
• "Hvad sker der med den første anmodning, efter appen har været inaktiv?"

Servere i Mythex

I Mythex administrerer du ikke servere. Mens du bygger, kører din app i en privat cloud-sandkasse til live-preview. Når du publicerer, deployer Mythex den: statiske frontends som statiske sites og backends (Node, Python, C#, Java og andre) som containere bygget fra en Dockerfile, uden at du selv skal konfigurere hosting. Mythex vælger maskinestørrelsen ved deployment: som standard 1 CPU og 512 MB hukommelse, med mere tilgængeligt efter anmodning (op til 1 GB på Free, og op til 2 CPU'er, 4 GB og 3 maskiner på Pro). Publicerede apps går i dvale, når de er inaktive, og vågner ved næste besøg, og en app i dvale koster ingenting i compute. Detaljer findes i dokumentationen om API-backends og hostinggrænser, og vores guide til webhosting dækker det bredere billede.

Spørgsmål