Webapplicatie architectuur: zo kies je een fundament dat meegroeit

Een webapplicatie architectuur is de manier waarop de onderdelen van je applicatie zijn opgebouwd en met elkaar samenwerken: de schermen die gebruikers zien, de logica op de server, de database en de koppelingen met andere systemen. Je ziet de architectuur niet, maar je merkt haar elke dag. Aan hoe snel een wijziging live staat, hoe vaak er iets omvalt en hoeveel het kost om een nieuwe functie te bouwen.

Dit artikel is geschreven voor beslissers, niet voor architecten. Je hoeft geen code te lezen om de juiste vragen te stellen aan je ontwikkelaar of bureau.

Wat is webapplicatie architectuur?

Architectuur is het ontwerp op hoog niveau van je software. Het beantwoordt vragen als: uit welke onderdelen bestaat de applicatie, wie is verantwoordelijk voor welke taken, hoe communiceren de onderdelen met elkaar en waar staan de gegevens?

Vergelijk het met een gebouw. Je kunt een kantoor neerzetten met één grote open ruimte of met afgesloten kamers en gangen. Beide werken, maar ze verschillen in flexibiliteit, onderhoud en wat er gebeurt als je wilt uitbreiden. Bij software is dat niet anders, met één verschil: een webapplicatie verandert veel vaker dan een gebouw.

Goede architectuur ondersteunt drie dingen:

• Onderhoudbaarheid: ontwikkelaars begrijpen de code en kunnen wijzigingen doen zonder dat er elders iets breekt.
• Schaalbaarheid: de applicatie kan meer gebruikers, data en verwerking aan zonder dat alles opnieuw moet.
• Betrouwbaarheid en beveiliging: gevoelige gegevens zijn beschermd en een fout in één onderdeel legt niet de hele applicatie plat.

De bouwstenen: frontend, backend en database

Vrijwel elke webapplicatie bestaat uit dezelfde lagen. Hoe je die invult en verbindt, maakt het verschil.

Frontend: wat de gebruiker ziet

De frontend is alles wat in de browser draait: schermen, formulieren, tabellen, knoppen. Hij is verantwoordelijk voor de interacties met de gebruiker en voor een prettige, snelle ervaring. Een frontend kan op de server worden opgebouwd (de server stuurt kant-en-klare pagina’s) of grotendeels in de browser draaien met een JavaScript-framework, een zogenaamde single-page application.

Backend: de logica aan de server side

De backend draait op de server. Hier zit de bedrijfslogica: berekeningen, regels, rechten, het verwerken van bestellingen of het versturen van e-mails. De backend controleert ook wie wat mag zien. Dat hoort altijd aan de server side te gebeuren, nooit alleen in de browser. Bij Inesta bouwen we backends meestal in Symfony of Laravel, twee volwassen PHP-frameworks met een grote community.

Database: waar je gegevens wonen

In de database staan je klanten, orders, planningen en alle andere data. De structuur van je databases (het datamodel) is een van de belangrijkste architectuurkeuzes, omdat hij lastig te veranderen is als er eenmaal jaren aan data in staat. Een helder datamodel dat je bedrijfsprocessen goed weerspiegelt, bespaart later veel werk.

API’s: hoe onderdelen met elkaar communiceren

Een API (application programming interface) is de afgesproken manier waarop onderdelen met elkaar communiceren. De frontend vraagt via een API gegevens op bij de backend; je webapplicatie praat via API’s met je boekhoudpakket, CRM of betaalprovider. Goed ontworpen API’s zorgen ervoor dat je onderdelen los van elkaar kunt verbeteren of vervangen.

Veelgebruikte architectuurpatronen

Er bestaat geen beste architectuur, wel een architectuur die past bij je situatie. Dit zijn de patronen die je het vaakst tegenkomt.

Monoliet en modulaire monoliet

Bij een monoliet zit de hele applicatie in één codebase die als geheel wordt uitgerold. Dat klinkt ouderwets, maar voor de meeste webapplicaties is het de meest efficiënte aanpak: één plek om te ontwikkelen, te testen en te deployen, en weinig infrastructuur om te onderhouden.

Het risico is dat een monoliet een kluwen wordt waarin alles van elkaar afhankelijk is. Daarom kiezen we bij voorkeur een modulaire monoliet: één applicatie, maar intern opgedeeld in duidelijke modules (bijvoorbeeld facturatie, planning, gebruikersbeheer) met vaste grenzen. Dat geeft eenvoudiger onderhoud en houdt de weg open om later een module af te splitsen.

Microservices

Bij microservices splits je de applicatie op in kleine, zelfstandige diensten die elk een eigen taak hebben en via API’s of berichten met elkaar communiceren. Elke service kan apart worden ontwikkeld, uitgerold en geschaald.

Dat is krachtig voor grote organisaties met meerdere ontwikkelteams en onderdelen met heel verschillende belasting. Maar het brengt verhoogde complexiteit mee: netwerkcommunicatie tussen services, gedistribueerde data, monitoring over meerdere systemen en meer infrastructuur. Voor een team van een paar ontwikkelaars weegt dat zelden op tegen de voordelen.

Serverless en managed diensten

Bij serverless draai je losse functies bij een cloudprovider, die de servers voor je beheert en automatisch schaalt. Dat werkt goed voor afgebakende taken, zoals het verwerken van uploads of het genereren van rapporten op de achtergrond. Als basis voor een complete bedrijfsapplicatie is het minder gebruikelijk, en je wordt sterker afhankelijk van één provider.

Server-rendered of single-page application

Ook aan de frontendkant is er een keuze. Server-rendered pagina’s zijn eenvoudig, snel bij de eerste keer laden en goed vindbaar. Een single-page application voelt vloeiender bij veel interactie, zoals een planbord met slepen en direct opslaan. Veel applicaties combineren beide: server-rendered waar het kan, rijke interactie waar het nodig is.

Welke architectuur past bij jouw webapplicatie?

De juiste keuze hangt af van een paar concrete vragen:

Vraag	Wijst richting monoliet	Wijst richting opgesplitste diensten
Hoe groot is het team?	Eén team, een paar ontwikkelaars	Meerdere teams die los van elkaar werken
Hoe verschilt de belasting per onderdeel?	Redelijk gelijkmatig	Eén onderdeel moet extreem schalen
Hoe vaak verandert wat?	Alles ontwikkelt samen	Onderdelen hebben eigen releaseritme
Hoeveel beheer wil je?	Zo min mogelijk infrastructuur	Er is capaciteit voor monitoring en DevOps

Twee voorbeelden uit de praktijk:

• Een klantportaal voor een dienstverlener met een paar honderd gebruikers, koppelingen met het CRM en de boekhouding. Een modulaire monoliet met een duidelijke API-laag is hier ruim voldoende en het goedkoopst om te onderhouden.
• Een SaaS-platform dat per klant grote hoeveelheden data importeert en verwerkt. De kern blijft een monoliet, maar het zware importwerk draait als aparte achtergrondtaak in een wachtrij, zodat gebruikers er niets van merken.

Begin eenvoudig en splits pas op als daar een concrete reden voor is. Een te complexe architectuur kost je elke dag geld; een eenvoudige architectuur die later wordt opgesplitst, kost je één keer werk.

Koppelingen met bestaande systemen

Een webapplicatie staat zelden alleen. Ze moet praten met bestaande systemen: je ERP, CRM, boekhouding, e-mailplatform of een oud maatwerksysteem. Hoe je die integraties inricht, is een architectuurkeuze.

Een paar principes die we hanteren:

• Eén laag voor koppelingen. Zet alle communicatie met verschillende systemen in een eigen module. Wisselt je boekhoudpakket, dan pas je één plek aan in plaats van de hele applicatie.
• Ga uit van storingen. Externe systemen zijn soms traag of onbereikbaar. Gebruik wachtrijen en herhaalpogingen, zodat een storing bij een leverancier niet jouw applicatie platlegt.
• Leg vast welk systeem de bron is. Als klantgegevens in twee systemen staan, moet duidelijk zijn welke leidend is. Anders ontstaan er tegenstrijdigheden die moeilijk op te sporen zijn.
• Automatiseer repetitieve taken. Laat gegevens automatisch doorstromen in plaats van ze handmatig over te tikken. Dat is vaak waar een webapplicatie de meeste tijd bespaart.

Beveiliging en schaalbaarheid vanaf het begin

Beveiliging is geen laag die je achteraf toevoegt. Of rechten consequent op de server worden gecontroleerd, hoe je gevoelige gegevens opslaat en hoe je met wachtwoorden omgaat, ligt grotendeels vast in de architectuur. In ons artikel over beveiliging van een webapplicatie lees je welke maatregelen het verschil maken.

Voor schaalbaarheid geldt iets vergelijkbaars. Je hoeft niet te bouwen voor een miljoen gebruikers, maar je moet het jezelf niet onmogelijk maken. Praktisch betekent dat:

• de applicatie bewaart geen sessiegegevens lokaal op één server, zodat je er later een tweede naast kunt zetten;
• zware taken draaien op de achtergrond in plaats van tijdens een klik van de gebruiker;
• de database heeft de juiste indexen en je meet waar het traag wordt in plaats van te gokken.

De omgeving waarop de applicatie draait, speelt hierin ook een belangrijke rol. Meer daarover in het artikel over webapplicatie hosting.

Architectuur die meegroeit met veranderende behoeften

De eisen aan je applicatie veranderen. Je organisatie groeit, processen wijzigen, er komt wetgeving bij of een nieuwe klantgroep. Een architectuur die goed omgaat met veranderende behoeften heeft een paar kenmerken:

• Duidelijke grenzen tussen onderdelen. Een wijziging in de planning raakt de facturatie niet.
• Geautomatiseerde tests. Ontwikkelaars kunnen met vertrouwen aanpassen, omdat tests direct laten zien als er iets breekt.
• Gedocumenteerde keuzes. Waarom is iets zo gebouwd? Een korte beschrijving per beslissing voorkomt dat een volgende ontwikkelaar het per ongeluk afbreekt.
• Actuele afhankelijkheden. Frameworks en libraries worden bijgehouden, zodat je niet na een paar jaar vastzit aan een verouderde versie.

Wordt dat laatste verwaarloosd, dan stapelt technische schuld zich op en wordt elke nieuwe functie duurder. Dat is meestal geen kwestie van slechte ontwikkelaars, maar van keuzes die nooit zijn herzien.

Veelgemaakte fouten in de architectuur van een webapplicatie

Deze fouten komen we regelmatig tegen bij applicaties die we overnemen:

1. Te vroeg microservices. Een klein team dat tien services moet onderhouden, besteedt meer tijd aan infrastructuur dan aan functionaliteit.
2. Logica in de frontend. Prijsberekeningen of rechtencontroles die alleen in de browser zitten, zijn te omzeilen en lastig te hergebruiken.
3. Geen scheiding tussen domeinen. Alles kan alles aanroepen, waardoor een kleine wijziging onverwachte gevolgen heeft in de hele applicatie.
4. Koppelingen overal in de code. Directe aanroepen naar externe systemen verspreid door de applicatie maken vervangen of debuggen moeilijk.
5. Geen ruimte voor groei in het datamodel. Een veld voor één adres per klant, terwijl je straks meerdere vestigingen hebt.

Breng je architectuur in kaart voordat je bouwt

Je hoeft geen dik architectuurdocument te schrijven. Wel is het verstandig om vooraf een aantal dingen in kaart te brengen:

• de belangrijkste processen en wie de applicatie gebruikt;
• welke gegevens je opslaat en welke daarvan gevoelig zijn;
• met welke systemen de applicatie moet koppelen;
• hoeveel gebruikers en data je de komende jaren verwacht;
• wie de applicatie straks onderhoudt: een extern team, een eigen team of een combinatie.

Met die antwoorden kan een ervaren ontwikkelaar een architectuur voorstellen die past, en kun jij de keuzes begrijpen. Een goed functioneel ontwerp is daarvoor een prima vertrekpunt.

Neem je een bestaande applicatie over, dan begint het andersom: eerst begrijpen hoe het nu is opgebouwd. Een codebase scan laat zien waar de architectuur knelt en wat je eerst moet aanpakken.

Hulp bij het ontwerpen van je webapplicatie

Een goede webapplicatie architectuur is geen doel op zich, maar de basis onder een applicatie die jarenlang meegaat. Wil je weten welke opbouw past bij jouw idee of bestaande applicatie? Lees hoe we te werk gaan bij webapplicatie ontwikkelen, of plan een kennismaking. Je krijgt binnen één werkdag reactie, en de code is altijd van jou.