Spring til indhold
Academi.dk

Arkitektur

Tre-lagsarkitektur

Let øvet DA↔EN-ordliste

En webapplikation deles typisk i tre lag: en frontend brugeren ser, en backend der indeholder reglerne, og en database der gemmer data. Lagene taler kun med naboen, og formålet er, at man kan ændre det ene uden at røre de andre.

Forudsætter, at du har set http-protokollen .

De tre lag

Browser  ──HTTP──▶  Backend  ──SQL──▶  Database
(frontend)          (regler)           (data)

Præsentationslaget (frontend). Det, brugeren ser og rører. HTML, CSS og JavaScript i browseren. Ansvar: vis data, tag imod input, giv besked om fejl. Ikke ansvar: at afgøre, om noget er tilladt.

Logiklaget (backend). Serveren. Ansvar: reglerne. Må den her bruger det her? Er ordren gyldig? Hvad koster det med rabat? Det er også her, en API-nøgle bor.

Datalaget (databasen). Ansvar: gemme og finde data pålideligt, og håndhæve de strukturelle regler. At en ordre ikke kan pege på en kunde, der ikke findes.

Hvorfor overhovedet dele det op?

Fordi de tre ting ændrer sig med hver deres hastighed og af hver deres grund. Et nyt design rører kun frontend. En ny rabatregel rører kun backend. En ny kolonne rører databasen og lidt af backend.

Ligger det hele blandet sammen, betyder en lille ændring, at alt skal testes igen. Det er den begrundelse, der efterspørges i rapporten, ikke “fordi man plejer”.

Hvem må tale med hvem?

Kun med naboen. Frontend taler med backend over HTTP; backend taler med databasen over SQL. Frontend taler aldrig direkte med databasen.

Det er ikke en æstetisk regel. Alt, hvad frontend indeholder, kan læses og ændres af enhver bruger. Havde browseren adgangsoplysninger til databasen, ville alle have dem.

Rejsen gennem lagene

Det her spørgsmål falder næsten altid til den mundtlige eksamen: “hvad sker der, når brugeren trykker på knappen?” Øv svaret.

  1. Brugeren klikker. En event-lytter i frontend kører.
  2. Frontend samler data fra felterne og sender en HTTP-forespørgsel, for eksempel POST /api/ordrer med JSON i indholdet.
  3. Backend tager imod, tjekker at brugeren må, og at data er gyldige.
  4. Backend sender SQL til databasen: INSERT INTO ordrer ….
  5. Databasen gemmer og svarer med id’et på den nye række.
  6. Backend svarer frontend med en statuskode og JSON.
  7. Frontend opdaterer siden. Ingen genindlæsning.

Kan I fortælle den rejse i ét stræk med jeres eget projekt som eksempel, står I godt.

De typiske fejl i et førsteårsprojekt

  • Regler i frontend. Rabatten regnes ud i JavaScript, så en bruger kan ændre den.
  • SQL i frontend. Er et alvorligt sikkerhedsproblem, ikke bare grimt.
  • Backend som gennemløber. Backend sender bare databasens rækker videre uden at gøre noget. Så er der reelt kun to lag, og det skal I i så fald kunne begrunde.
  • Forretningslogik i databasen. Kan lade sig gøre, men gør reglerne svære at finde. Hold databasen til struktur og integritet.

Kort opsamling

  • Frontend viser, backend bestemmer, databasen husker.
  • Hvert lag taler kun med naboen.
  • Validering i frontend er høflighed, i backend er det sikkerhed.
  • Kunne fortælle et kliks rejse gennem alle tre lag.

Læs videre

Senest gennemgået .