Hvad er en full-stack-app? En forklaring på almindeligt sprog

En full-stack-app er en app, der indeholder alle de lag, den behøver for at fungere: frontenden, som folk ser og klikker på, backenden, der kører på en server og håndhæver reglerne, og databasen, der husker alt. En to-do-liste, der gemmer dine opgaver, lader dig logge ind fra enhver enhed og ikke viser din liste til andre, er full-stack. En enkelt side, der kun viser dine åbningstider, er det ikke.

"Stack" betyder blot de teknologilag, der ligger oven på hinanden. "Full" betyder, at alle er med.

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

Når du beskriver en app for en AI-builder, afgør de ord, du bruger, hvilke lag den bygger. "Lav en side, der viser vores menu" giver en frontend. "Lad kunder bestille fra vores menu, og lad køkkenet se nye ordrer" kræver alle tre lag, fordi ordrer skal gemmes, deles mellem to slags brugere og holdes private.

At kende forskellen hjælper dig på tre måder:

• Du beder om det rigtige. Hvis du vil have data gemt, så sig det. En builder, der kun laver frontenden, ser færdig ud, men glemmer alt ved genindlæsning.
• Du opdager falsk færdighed. En demo med eksempeldata kan se præcis ud som en fungerende app. Når du kender lagene, kan du kontrollere, at data virkelig går et sted hen.
• Du forstår driftsomkostningerne. En ren frontend kan serveres som statiske filer. En backend og en database er programmer, der kører på servere, og det er her det meste af hostingomkostningen opstår.

En hverdagsanalogi: en restaurant

Tænk på en restaurant.

• Spisesalen er frontenden. Menuer, borde og tjenerens notesblok. Det er det, gæsterne ser, og det skal være behageligt og nemt at bruge.
• Køkkenet er backenden. Gæsterne går aldrig ind. Det modtager ordrer, tjekker at retten er på lager, laver den og afviser underlige ønsker. Reglerne bor her.
• Køleskabet og ordrebogen er databasen. De indeholder det, der findes, og det, der er bestilt, så intet glemmes, når vagten skifter.

En restaurant med kun en spisesal kan vise dig en flot menu, men du kan ikke få mad. Det er en frontend-only-app, der lader som om, den er full-stack.

De tre lag i detaljer

Lagene taler sammen i en fast rækkefølge. Frontenden beder backenden om noget gennem en API, altså et defineret sæt anmodninger, backenden accepterer. Backenden kontrollerer anmodningen, læser eller skriver i databasen og sender et svar tilbage. Frontenden taler aldrig direkte med databasen.

Den rækkefølge er den vigtigste sikkerhedsidé i hele stacken. Alt i frontenden kan læses og ændres af besøgende, fordi det kører på deres enhed. Derfor skal reglerne (»kun ejeren må se denne faktura«, »en rabatkode kan kun bruges én gang«) håndhæves i backenden. Mere om opdelingen finder du i frontend vs. backend.

Et konkret eksempel: en app til holdtimer

Sig at du driver et yogastudie og vil have, at folk kan booke hold online.

Hvad den besøgende gør: åbner siden, ser ugens hold, trykker på et, logger ind og booker en plads.

Hvad der sker under overfladen:

1. Frontenden viser skemaet. For at udfylde det spørger den backenden: "Hvilke hold er der denne uge, og hvor mange pladser er ledige?"
2. Backenden spørger databasen om holdene og tæller bookingerne for hvert, og svarer.
3. Den besøgende trykker på Book. Frontenden sender "book hold 42 for denne indloggede person".
4. Backenden kontrollerer: Er personen virkelig logget ind? Er holdet fuldt? Har de allerede booket det? Kun hvis alt er i orden, skriver den en ny bookingrække til databasen.
5. Backenden svarer "booket", og frontenden viser en bekræftelse.
6. Senere logger studieejeren ind og ser holdlisten. Backenden kontrollerer, at hun er admin, før den viser alles navne.

Forestil dig nu, at dette var bygget som kun frontend. Skemaet kunne vises, og Book-knappen kunne vise et flot flueben, men bookingen ville forsvinde ved genindlæsning, antallet af ledige pladser ville være forkert for alle andre, og ejeren ville aldrig se den. Trin 4, kontrollerne, ville helt mangle. Det er den praktiske forskel.

Vigtige begreber

• Frontend (klientside): den del, der kører i browseren.
• Backend (serverside): den del, der kører på en server. Kaldes også API-serveren.
• Database: der, hvor data gemmes på en struktureret måde. Se hvad en database er.
• API: listen over anmodninger, backenden accepterer fra frontenden eller andre programmer.
• Godkendelse (authentication): at kontrollere, hvem nogen er (login). Autorisation: at kontrollere, hvad de må gøre.
• Deployment: at lægge alle lagene på servere, så offentligheden kan bruge dem.
• Monolit vs. services: ét program, der gør alt, versus flere mindre programmer (fx et website og en separat API). Begge er full-stack.

Almindelige fejl og misforståelser

• "Det ser færdigt ud, så det er færdigt." Eksempeldata og en knap, der virker fungerende, er ikke det samme som gemte data. Genindlæs siden, åbn den i et privat vindue, og tjek at data stadig er der.
• At putte regler i frontenden. At skjule en knap er ikke sikkerhed. Hvis backenden ikke kontrollerer, kan enhver, der kender anmodningen, lave den.
• At putte hemmelige nøgler i frontenden. En betalings- eller AI-udbyders nøgle i browserkode kan læses af enhver besøgende. Nøgler hører hjemme i backenden, i miljøvariabler. Se miljøvariabler og secrets.
• At tro, full-stack betyder kompliceret. En lille full-stack-app kan være et par skærme, en håndfuld backend-ruter og tre databasetabeller. Det er en beskrivelse af lagene, ikke af størrelsen.
• At tro, du selv skal vælge hver teknologi. Enhver fornuftig, udbredt stack duer til en første version. Det vigtigste er en klar beskrivelse af data og regler.

Hvad du kan bede din AI-builder om

Beskriv appen i form af de tre lag, også selvom du ikke navngiver dem:

• Dataene: "Gem hold (navn, tidspunkt, kapacitet) og bookinger (hold, person, booket tidspunkt) i en database."
• Reglerne: "Et hold kan ikke bookes ud over kapaciteten. En person kan kun booke et hold én gang. Kun admins må se, hvem der har booket."
• Skærmene: "Et ugentligt skema, en bookingbekræftelse, en admin-side med bookinger pr. hold."
• Kontrollerne: "Håndhæv disse regler på serveren, ikke kun på siden. Behold alle API-nøgler på serveren."

Test derefter som en skeptiker: genindlæs, log ind som to forskellige personer, og prøv at se data, du ikke må se. Guiden til at bygge en app med AI gennemgår hele den loop.

Full-stack-apps på Mythex

Mythex bygger full-stack-webapps ud fra en chatbeskrivelse. Som standard får en ny app en React- og TypeScript-frontend. Når appen skal gemme data, tilføjer Mythex en dedikeret Postgres-database til projektet, og du kan bede om en separat API-server (fx Python, Node, C# eller Java) ved siden af websitet. Alt kører sammen i et live preview og publiceres til en offentlig URL. Dokumentationssiden om multi-service-apps viser, hvordan et website og en API forhåndsvises og publiceres sammen, og siden full-stack app-builder har udgangspunkter.

Spørgsmål