Wat is een full-stack app? Een uitleg in begrijpelijke taal

Een full-stack app is een app die alle lagen bevat die hij nodig heeft om te werken: de frontend die mensen zien en aanklikken, de backend die op een server draait en de regels afdwingt, en de database die alles onthoudt. Een to-dolijst die je taken opslaat, je laat inloggen vanaf elk apparaat en niemand anders jouw lijst laat zien, is full-stack. Een enkele pagina die alleen je openingstijden toont, is dat niet.

“Stack” betekent gewoon de lagen van technologie die op elkaar liggen. “Full” betekent dat ze er allemaal zijn.

Waarom het ertoe doet als je met AI bouwt

Als je een app aan een AI-bouwer beschrijft, bepalen de woorden die je gebruikt welke lagen hij bouwt. “Maak een pagina die ons menu toont” levert een frontend op. “Laat klanten bestellen van ons menu en laat de keuken nieuwe bestellingen zien” vraagt om alle drie de lagen, omdat bestellingen moeten worden opgeslagen, gedeeld tussen twee soorten gebruikers en privé moeten blijven.

Het verschil kennen helpt je op drie manieren:

• Je vraagt het juiste. Als je wilt dat gegevens worden opgeslagen, zeg dat dan. Een bouwer die alleen de frontend maakt, ziet er af uit maar vergeet alles bij een refresh.
• Je herkent schijnbare volledigheid. Een demo met voorbeeldgegevens kan er precies uitzien als een werkende app. Als je de lagen kent, kun je controleren of de gegevens echt ergens naartoe gaan.
• Je begrijpt de doorlopende kosten. Een frontend alleen kan als statische bestanden worden geserveerd. Een backend en een database zijn programma’s die op servers draaien, en daar komt het grootste deel van de hostingkosten vandaan.

Een alledaagse vergelijking: een restaurant

Denk aan een restaurant.

• De eetzaal is de frontend. Menu’s, tafels en het notitieblok van de ober. Het is wat gasten zien, en het moet prettig en makkelijk te gebruiken zijn.
• De keuken is de backend. Gasten komen er nooit binnen. Ze neemt bestellingen op, controleert of een gerecht beschikbaar is, maakt het klaar en weigert rare verzoeken. De regels zitten hier.
• De voorraadkast en het bestelboek zijn de database. Ze bevatten wat er is en wat er besteld is, zodat er niets vergeten wordt als de dienst wisselt.

Een restaurant met alleen een eetzaal kan je een mooi menu laten zien, maar je krijgt niets te eten. Dat is een frontend-only app die doet alsof hij full-stack is.

De drie lagen nader bekeken

De lagen praten in een vaste volgorde met elkaar. De frontend vraagt de backend iets via een API: een vastgelegde set verzoeken die de backend accepteert. De backend controleert het verzoek, leest of schrijft de database en stuurt een antwoord terug. De frontend praat nooit rechtstreeks met de database.

Die volgorde is het belangrijkste beveiligingsidee in de hele stack. Alles in de frontend kan door de bezoeker worden gelezen en gewijzigd, omdat het op hun apparaat draait. Dus de regels (“alleen de eigenaar kan deze factuur zien”, “een kortingscode kan maar één keer worden gebruikt”) moeten in de backend worden afgedwongen. Meer over die splitsing vind je bij frontend versus backend.

Een uitgewerkt voorbeeld: een app voor yogalessen

Stel dat je een yogastudio runt en mensen online lessen wilt laten boeken.

Wat de bezoeker doet: de site openen, de lesrooster van deze week zien, een les aantikken, inloggen en een plek boeken.

Wat er onder de motorkap gebeurt:

1. De frontend toont het rooster. Om het te vullen vraagt hij de backend: “Welke lessen zijn er deze week, en hoeveel plekken zijn er nog vrij?”
2. De backend vraagt de database om de lessen en telt de boekingen per les, en antwoordt.
3. De bezoeker tikt op Boeken. De frontend stuurt “boek les 42 voor deze ingelogde persoon”.
4. De backend controleert: is deze persoon echt ingelogd? Zit de les al vol? Heeft die persoon hem al geboekt? Alleen als alles klopt, schrijft hij een nieuwe boekingsrij naar de database.
5. De backend antwoordt “geboekt”, en de frontend toont een bevestiging.
6. Later logt de studio-eigenaar in en ziet de lijst met lessen. De backend controleert dat zij beheerder is voordat hij de namen van iedereen toont.

Stel je nu voor dat dit alleen in de frontend was gebouwd. Het rooster zou misschien verschijnen, en de knop Boeken zou een mooi vinkje tonen, maar de boeking zou bij een refresh verdwijnen, het aantal vrije plekken zou voor iedereen anders kloppen, en de eigenaar zou er nooit iets van zien. Stap 4, de controles, zou helemaal ontbreken. Dat is het praktische verschil.

Belangrijke begrippen

• Frontend (client-side): het deel dat in de browser draait.
• Backend (server-side): het deel dat op een server draait. Ook wel de API-server genoemd.
• Database: waar gegevens georganiseerd worden opgeslagen. Zie wat een database is.
• API: de lijst met verzoeken die de backend accepteert van de frontend of andere programma’s.
• Authenticatie: controleren wie iemand is (inloggen). Autorisatie: controleren wat iemand mag doen.
• Deployment: alle lagen op servers zetten zodat het publiek de app kan gebruiken.
• Monoliet versus services: één programma dat alles doet, versus meerdere kleinere programma’s (bijvoorbeeld een website en een aparte API). Beide zijn full-stack.

Veelgemaakte fouten en misverstanden

• “Het ziet er af uit, dus het is af.” Voorbeeldgegevens en een knop die werkt, zijn niet hetzelfde als opgeslagen gegevens. Ververs de pagina, open hem in een privévenster en controleer of de gegevens er nog zijn.
• Regels in de frontend zetten. Een knop verbergen is geen beveiliging. Als de backend niet controleert, kan iedereen die het verzoek kent het gewoon doen.
• Geheime sleutels in de frontend zetten. Een sleutel van een betaal- of AI-provider in browsercode is voor elke bezoeker leesbaar. Sleutels horen op de backend, in omgevingsvariabelen. Zie omgevingsvariabelen en secrets.
• Denken dat full-stack ingewikkeld betekent. Een kleine full-stack app kan een paar schermen, een handvol backendroutes en drie databasetabellen hebben. Het beschrijft de lagen, niet de omvang.
• Denken dat je zelf elke technologie moet kiezen. Elke verstandige, veelgebruikte stack is goed genoeg voor een eerste versie. Belangrijker is een duidelijke beschrijving van de gegevens en de regels.

Wat je aan je AI-appbouwer kunt vragen

Beschrijf de app in termen van de drie lagen, ook als je ze niet bij naam noemt:

• De gegevens: “Sla lessen (naam, tijd, capaciteit) en boekingen (les, persoon, boekingstijd) op in een database.”
• De regels: “Een les kan niet boven de capaciteit worden geboekt. Een persoon kan een les maar één keer boeken. Alleen beheerders zien wie geboekt heeft.”
• De schermen: “Een wekelijks rooster, een boekingsbevestiging, een beheerpagina met boekingen per les.”
• De controles: “Handhaaf deze regels op de server, niet alleen in de pagina. Houd API-sleutels op de server.”

Test daarna als een scepticus: ververs, log in als twee verschillende personen, en probeer gegevens te zien die je niet mag zien. De gids over het bouwen van een app met AI loopt die cyclus van begin tot eind door.

Full-stack apps op Mythex

Mythex bouwt full-stack webapps op basis van een chatbeschrijving. Standaard krijgt een nieuwe app een React- en TypeScript-frontend; wanneer de app gegevens moet opslaan, voegt Mythex een eigen Postgres-database aan het project toe, en je kunt om een aparte API-server vragen (bijvoorbeeld in Python, Node, C# of Java) naast de website. Alles draait samen in een live preview en wordt gepubliceerd op een publieke URL. De documentatiepagina over apps met meerdere services laat zien hoe een website en een API samen worden getoond en gepubliceerd, en de pagina full-stack app-bouwer geeft startpunten.

Veelgestelde vragen