Wat is een server? Een duidelijke gids voor app-bouwers

Een server is een computer, of een programma dat op een computer draait, dat wacht op verzoeken en die beantwoordt. Wanneer je een website opent, stuurt je browser (de client) een verzoek over het internet, en stuurt een server ergens de pagina, de afbeeldingen of de gegevens terug. Elke app die je gebruikt, van e-mail tot internetbankieren, is afhankelijk van servers die dit miljoenen keren per dag doen.

Waarom servers ertoe doen als je met AI bouwt

Wanneer een AI-bouwer een app voor je maakt, draait een deel van de code in de browser van de bezoeker en draait een deel meestal op een server. Het serverdeel doet de dingen waarop de browser niet kan worden vertrouwd of die hij niet alleen kan:

• Gegevens opslaan en laden uit een database.
• Geheimen bewaren, zoals API-sleutels van betaal- of AI-providers, die nooit de browser mogen bereiken.
• Rechten controleren: zorgen dat een gebruiker alleen zijn eigen gegevens kan zien en wijzigen.
• Met andere diensten praten: een kaart belasten, een e-mail versturen, een AI-model aanroepen.

Weten wat de server doet, helpt je begrijpen waar de regels van je app echt zitten, waarom sommige wijzigingen opnieuw publiceren vragen, en waarvoor je betaalt wanneer je een app host. Voor de splitsing tussen beide helften, zie frontend versus backend.

Een alledaagse vergelijking

Een server is als het loket op het postkantoor. Hij gaat niet op zoek naar klanten; hij wacht. Een klant (de client) komt binnen met een verzoek, zoals “dit pakketje versturen” of “heb ik post?”, en de medewerker handelt het af en geeft een resultaat terug. Eén medewerker kan de ene klant na de andere helpen, en een druk postkantoor opent meer loketten.

Het postkantoor heeft ook regels die de klant niet kan omzeilen: je moet je legitimeren om een pakketje op te halen. Dat is in een app ook de taak van de server: de browser kan om alles vragen, maar de server beslist wat hij krijgt.

Hoe een verzoek een server bereikt

Wanneer iemand https://bookings.example.com/schedule bezoekt:

1. DNS-opzoeking. De browser vraagt het domeinnaamsysteem naar welk IP-adres bookings.example.com verwijst. Zie hoe domeinen en DNS werken.
2. Verbinding. De browser verbindt met dat adres, op poort 443 voor HTTPS, en zet een versleutelde verbinding op. Zie wat HTTPS is.
3. Verzoek. Hij stuurt een HTTP-verzoek: GET /schedule.
4. Werk. De server draait de code die /schedule afhandelt, misschien het opzoeken van de boekingen van vandaag in de database.
5. Antwoord. Hij stuurt een statuscode (200 OK) en de inhoud terug: een HTML-pagina, of JSON-gegevens die de pagina toont.

Dat duurt meestal een fractie van een seconde.

Soorten servers die je tegenkomt

Let op dat “server” zowel de machine als het programma betekent. “De server is gecrasht” kan allebei betekenen.

Een uitgewerkt voorbeeld: een boekingsapp voor een kapsalon

Hier is wat de server doet in een kleine boekingsapp voor een kapsalon:

• Een bezoeker opent de site. De server (of een CDN ervoor) stuurt de paginabestanden.
• De pagina vraagt de server GET /api/slots?date=2026-10-03. De server bevraagt de database op vrije tijdsloten en geeft ze terug als JSON.
• De bezoeker boekt 14:00. De pagina stuurt POST /api/bookings. De server controleert of het tijdslot nog vrij is, want hij vertrouwt de browser daarop niet; hij slaat de boeking op en antwoordt met 201 Created.
• De server roept een e-mailservice aan met een geheime sleutel, die op de server is opgeslagen, om een bevestiging te sturen.

Als je de server uitzette, zou de pagina misschien nog steeds laden vanaf een CDN, maar hij zou geen tijdsloten kunnen tonen of boekingen kunnen opslaan.

Wat een server nodig heeft om goed te draaien

• Geheugen (RAM) en CPU. Te weinig geheugen en de app crasht onder belasting; te weinig CPU en hij wordt traag.
• Dat hij draait. Een server die uit staat, kan niet antwoorden. Sommige platforms zetten ongebruikte apps in de slaapstand en wekken ze bij het volgende bezoek, wat geld bespaart maar het eerste verzoek trager kan maken.
• Configuratie en geheimen, geleverd als omgevingsvariabelen.
• Logs: het logboek van de server van wat er is gebeurd, waar je als eerste kijkt wanneer iets misgaat.
• Updates en beveiligingspatches, die beheerde hosting voor je afhandelt.

Veelvoorkomende misverstanden

• “De cloud betekent geen servers.” De cloud zijn de servers van andere bedrijven, gehuurd per uur of per gebruik.
• “Een server is een grote speciale computer.” Elke computer kan als server dienen. Je laptop draait er een wanneer je localhost opent tijdens het ontwikkelen.
• “Als de knop verborgen is, kunnen gebruikers het niet doen.” Iedereen kan verzoeken rechtstreeks naar je server sturen. Rechtencontroles moeten op de server gebeuren, niet alleen in de pagina.
• “Meer servers lossen traagheid op.” Vaak is de echte oorzaak een trage databasequery of een externe API. Zoek eerst het knelpunt.
• “Ik moet een server beheren om een app te hebben.” Beheerde platforms draaien de servers voor je; jij deployt code en zij beheren de machines.

Wat je aan je AI-appbouwer kunt vragen

• “Welke delen van deze app draaien op de server, en welke in de browser?”
• “Houd alle API-sleutels op de server en lees ze uit omgevingsvariabelen.”
• “Controleer rechten op de server voor elk verzoek dat gegevens leest of wijzigt.”
• “Waar vind ik de serverlogs, en wat zeggen ze over deze fout?”
• “Heeft deze app überhaupt een server nodig, of kan het een statische site zijn?”
• “Wat gebeurt er met het eerste verzoek nadat de app een tijdje inactief is geweest?”

Servers in Mythex

In Mythex beheer je geen servers en stel je ze niet in. Tijdens het bouwen draait je app in een eigen cloud-sandbox voor de live preview. Wanneer je publiceert, deployt Mythex hem: statische frontends als statische sites, backends (Node, Python, C#, Java en andere) als containers die uit een Dockerfile zijn gebouwd, zonder dat je zelf hosting hoeft in te stellen. Mythex kiest de machinegrootte bij het deployen: standaard 1 CPU en 512 MB geheugen, met meer beschikbaar op verzoek (tot 1 GB op Free, en tot 2 CPU’s, 4 GB en 3 machines op Pro). Gepubliceerde apps gaan slapen wanneer ze inactief zijn en worden wakker bij het volgende bezoek, en een slapende app kost geen rekenkracht. Details staan in de documentatie over API-backends en hostinglimieten, en onze gids over webhosting geeft het bredere beeld.

Veelgestelde vragen