Wat is back-end website ontwikkeling?

Back-end ontwikkeling is alles wat op de server gebeurt en wat je bezoeker niet ziet. Gegevens opslaan en ophalen, gebruikers inloggen, formulieren verwerken, betalingen afhandelen, mails versturen.

De voorkant bepaalt hoe iets eruitziet, de achterkant bepaalt wat er echt gebeurt. Bij een contactformulier is het invulveld de voorkant en het opslaan en versturen de achterkant.

Wat er gebeurt tussen de klik en de pagina

Om te snappen waar de achterkant zit, helpt het om één paginaverzoek te volgen. Iemand tikt je adres in. Zijn computer vraagt eerst via het Domain Name System op welk IP-adres jouw site staat.

Daarna wordt er een beveiligde verbinding opgezet met de webserver, meestal Apache of nginx. Dat is de laag die het verkeer aanneemt en die ook je SSL-certificaat afhandelt.

De webserver geeft het verzoek door aan PHP. Die haalt bij de database op wat er op de pagina moet staan, plakt dat in een sjabloon en geeft de HTML terug. Die HTML gaat naar de browser, die vervolgens de afbeeldingen, stijlbestanden en scripts opvraagt.

Dit hele rondje duurt bij een gezonde site een paar honderd milliseconden. Duurt het een seconde of langer voordat de eerste byte terugkomt, dan zit het probleem vrijwel altijd in dit stuk, en dan helpt geen enkele verbetering aan de voorkant.

Wat erbij komt kijken

Een taal die op de server draait. PHP, waar WordPress op draait, of Node.js, Python, Ruby, C# of Java.

Een database. Meestal MySQL of PostgreSQL voor gegevens in rijen en kolommen, of MongoDB als de structuur losser is.

Een raamwerk. Laravel bij PHP, Django bij Python, Express bij Node. Die nemen het standaardwerk uit handen zodat je niet elke keer opnieuw begint.

Koppelingen. Een betaalpartij, een boekhoudpakket, een verzendpartij. In de praktijk is dit bij veel projecten het grootste deel van het werk.

Beveiliging. Invoer controleren, wachtwoorden versleutelen, rechten regelen. Hier ligt de zwaarste verantwoordelijkheid van het hele vak.

Beheer. Back-ups, updates, logboeken, een plek om te testen. Dit hoort erbij en wordt bij de offerte meestal vergeten.

De talen op een rij

PHP. Draait op een enorm deel van het web, onder meer via WordPress. Wordt vaak onderschat en is met de versies 8.0 en later flink sneller en strenger geworden. Overal ontwikkelaars voor te vinden. Meer erover staat in het artikel over PHP.

Node.js. JavaScript op de server. Prettig als je voorkant ook in JavaScript is, want dan werk je in één taal. Het verwerkt veel gelijktijdige verbindingen goed, maar één zware berekening blokkeert de rest.

Python. Leesbaar, veel gebruikt, en de standaard zodra er data-analyse of AI bij komt kijken.

Ruby. Minder populair dan tien jaar geleden, en met Ruby on Rails nog steeds een snelle manier om iets werkends neer te zetten.

C# en Java. Vooral in grotere organisaties en bij bestaande systemen. Zwaarder om mee te beginnen, en sterk als er veel mensen jarenlang aan hetzelfde systeem werken.

Welke taal het beste is, is een discussie zonder einde. Belangrijker: kies iets waar mensen mee kunnen werken die je later kunt inhuren. Een systeem in een taal die niemand in de buurt beheerst is over drie jaar een probleem, hoe elegant het ook is gebouwd.

Wat een raamwerk je bespaart

Een raamwerk is een verzameling kant-en-klare oplossingen voor dingen die elke website nodig heeft. Inloggen, formulieren valideren, adressen omzetten naar de juiste code, mails versturen, database-opdrachten opbouwen.

Dat scheelt tijd, en belangrijker nog: het scheelt fouten, want die onderdelen zijn door duizenden mensen gebruikt en getest. Wie zijn eigen inlogsysteem schrijft omdat het maar een paar regels zijn, bouwt bijna altijd een lek.

Er zit ook een keerzijde aan. Je erft de manier van werken van het raamwerk en je bent afhankelijk van het onderhoud ervan. Een groot project op een raamwerk dat na twee jaar wordt losgelaten, is een dure verhuizing.

Kies daarom iets met een grote gemeenschap eromheen en een voorspelbaar ritme van nieuwe versies. Laravel, Symfony, Django en Rails voldoen daaraan. Een hip raamwerk van vorig jaar met drie beheerders is voor een bedrijfssite geen verstandige basis.

De database is waar het meestal misgaat

Is een site traag en ligt het niet aan de afbeeldingen, dan zit het probleem bijna altijd in de database. Meestal in één van drie dingen.

Het eerste is een ontbrekende index. Zonder index moet de database bij elke zoekopdracht de hele tabel doorlopen. Bij duizend rijen merk je dat niet, bij een half miljoen wel.

Het tweede is een lus met een zoekopdracht erin. Je haalt honderd bestellingen op en vraagt vervolgens per bestelling de klantgegevens apart op. Dat zijn honderdeen keer heen en weer naar de database terwijl het er twee hadden kunnen zijn.

Het derde is opgehoopte rommel. Bij WordPress zie ik dat wekelijks: tabellen vol oude revisies van pagina's, verlopen tijdelijke gegevens en losse velden van plugins die er al jaren niet meer zijn. WordPress leest bij elk paginaverzoek een blok instellingen in één keer in. Heeft een plugin daar een megabyte aan gegevens in geparkeerd, dan betaalt elke bezoeker daarvoor.

Dat opruimen is saai werk met een direct effect. Het is bij oudere sites vaak de goedkoopste snelheidswinst die er te halen valt.

De server eronder

De achterkant staat of valt met waar hij draait. Een site kan technisch prima in elkaar zitten en toch traag zijn omdat hij op een overvolle gedeelde server staat.

Waar het op aankomt bij webhosting voor een dynamische site: een recente PHP-versie, genoeg werkgeheugen per verzoek, PHP-code die in het geheugen wordt bewaard zodat hij niet elke keer opnieuw wordt gelezen, en bij drukkere sites een aparte cache voor databaseresultaten.

Let ook op de taken die op vaste tijden moeten draaien. WordPress regelt die standaard zelf, maar alleen als er iemand op je site komt. Op een rustige site betekent dat gemiste back-ups en nieuwsbrieven die te laat vertrekken. De oplossing is een echte geplande taak op de server, en dat is vijf minuten werk.

Voor de AVG telt daarnaast waar je gegevens staan. Hosting binnen de Europese Unie voorkomt een hoop vragen over doorgifte naar landen buiten de EU. Je hebt bovendien een verwerkersovereenkomst met je hostingpartij nodig, want die verwerkt persoonsgegevens namens jou.

Beveiliging is het zwaarste deel

Bijna elk lek komt op hetzelfde neer: er is iets gebruikt dat van buiten kwam zonder het te controleren.

Alles wat uit een formulier, een adresregel of een koppeling komt is verdacht tot je het hebt nagekeken. Bouw je vragen aan de database daarom op met parameters en plak nooit tekst van een bezoeker in een database-opdracht. Daar komt SQL-injectie vandaan, en dat is nog steeds een van de meest gebruikte manieren om een site over te nemen.

Dezelfde regel geldt de andere kant op. Wat je terugzet op een pagina moet zo worden opgemaakt dat het geen code kan worden, anders draait de browser van je bezoeker het script van iemand anders. Reactieformulieren en zoekvelden zijn daarvoor de gebruikelijke ingang.

Wachtwoorden sla je nooit leesbaar op. Gebruik een functie die daarvoor is gemaakt, zoals bcrypt of argon2; PHP heeft er een ingebouwde functie voor. Regel daarnaast rechten per rol, want iedereen beheerder maken is de snelste route naar een ongeluk.

Wantrouw ook uploads en herhaling. Controleer bij een geüpload bestand het type en zet het op een plek waar het niet als code kan worden uitgevoerd. En zet een rem op het aantal inlogpogingen, anders staat je site open voor het geduldig aftikken van wachtwoorden.

Voor een Nederlands bedrijf zit hier ook een wettelijke kant aan. De AVG vraagt in artikel 32 om passende technische maatregelen om persoonsgegevens te beschermen. Gaat het toch mis en lekken er gegevens, dan moet je dat binnen 72 uur melden bij de Autoriteit Persoonsgegevens, tenzij het risico voor de betrokkenen verwaarloosbaar is. Wat je daarvoor praktisch kunt doen staat bij een WordPress-website beveiligen.

Updates en onderhoud

Software veroudert, ook als je er niets aan verandert. Dat is het deel van de achterkant dat het vaakst wordt onderschat.

PHP krijgt per versie twee jaar actieve ondersteuning en daarna nog een jaar beveiligingsupdates. PHP 8.1 kreeg eind 2025 zijn laatste. Draai je daar nog op, dan worden nieuwe lekken in de taal zelf niet meer gedicht, hoe goed jouw code ook is.

Bij WordPress komt daar het onderhoud van plugins bij. Een plugin die twee jaar geen update heeft gehad is een risico, niet omdat hij vandaag stuk is, maar omdat er niemand meer op let. Ik gooi zulke plugins er liever uit dan dat ik ze laat staan.

Updates draai je niet blind op een live site. De volgorde die werkt: back-up maken, bijwerken op een testomgeving, controleren of de belangrijke onderdelen het nog doen, en dan pas live. Bij een site met een webshop of ledenadministratie is die testomgeving geen luxe.

Test ook eens per jaar of je back-up echt terug te zetten is. Een back-up die nooit is teruggezet is een aanname.

Koppelingen met andere systemen

Bij de meeste projecten zit het echte werk in de verbindingen met andere partijen. Een betaalprovider, een boekhoudpakket, een voorraadsysteem, een verzendpartij, een e-mailplatform.

Zulke koppelingen lopen via een API: een afgesproken manier waarop twee systemen elkaar gegevens doorgeven, meestal in JSON. Daarnaast bestaan er webhooks, waarbij de andere partij jou belt zodra er iets gebeurt, bijvoorbeeld als een betaling is gelukt.

De valkuil is dat je ervan uitgaat dat de andere kant altijd bereikbaar is. Dat is hij niet. Bouw daarom in dat een mislukte poging later opnieuw wordt gedaan, dat dezelfde melding twee keer verwerken geen dubbele order oplevert, en dat er ergens een logboek staat waarin je kunt terugzien wat er is uitgewisseld.

Let ook op de limieten. Veel partijen staan maar een bepaald aantal verzoeken per minuut toe. En vraag altijd om een testomgeving, want je wilt niet met echte betalingen leren hoe iets werkt.

Terugkijken als het misgaat

Het verschil tussen een amateur en een vakman zie je niet als het werkt, maar op het moment dat het stukgaat.

Zorg dat fouten ergens worden weggeschreven, met tijdstip, gebruiker en wat er precies gebeurde. Bij WordPress zet je daarvoor het foutenlogboek aan, met de foutmeldingen uit het zicht van de bezoeker. Een technische melding op je pagina is slordig, en hij vertelt een aanvaller precies waar hij moet zoeken.

Zet daarnaast iets neer dat je waarschuwt. Een simpele controle die elke vijf minuten kijkt of je site nog reageert is genoeg, en dat kost tegenwoordig weinig. Het alternatief is dat je klant je belt.

Geautomatiseerd testen is bij maatwerk verstandig, bij een gewone WordPress-site meestal overdreven. Wel goed: schrijf de vijf handelingen op die absoluut moeten werken en loop die na elke ingreep zelf even door. Bestellen, inloggen, formulier versturen, factuur ontvangen, zoeken.

Wat een goede achterkant kenmerkt

• Invoer wordt gecontroleerd. Nooit vertrouwen op wat er uit een formulier komt. Dit is de bron van bijna elk beveiligingsprobleem.
• Fouten worden netjes afgehandeld. Een bezoeker hoort geen technische foutmelding te zien, en jij hoort er wel een melding van te krijgen.
• Het is te volgen. Logboeken waarin je kunt terugzien wat er is gebeurd toen het misging.
• Het is snel genoeg. Zware zoekopdrachten op een database vertragen je hele site.
• Er zijn back-ups. Van de bestanden en van de database, en getest of je ze kunt terugzetten.
• Het is te onderhouden. Code die een ander over twee jaar nog begrijpt is meer waard dan slimme code.
• Het staat in versiebeheer. Elke wijziging terug te vinden, met een reden erbij.

Voorkant, achterkant en alles ertussenin

De scheiding is minder scherp dan de termen doen vermoeden. Wat vroeger op de server werd samengesteld, gebeurt tegenwoordig vaak in de browser met gegevens die de achterkant aanlevert.

Daardoor is de achterkant bij moderne projecten steeds vaker een leverancier van gegevens in plaats van een bouwer van pagina's. Wat er met die gegevens gebeurt hoort bij front-end ontwikkeling.

Iemand die beide kanten doet heet een full-stack ontwikkelaar. Dat is voor kleine projecten praktisch, want er is niemand om iets aan over te dragen. Bij grotere systemen zie je juist specialisatie, omdat de diepte aan beide kanten toeneemt. Meer daarover staat bij full-stack ontwikkeling.

Bij WordPress, en wanneer je maatwerk nodig hebt

Voor de meeste websites hoef je geen achterkant te bouwen: WordPress heeft er al een. Het werk zit dan in maatwerk erbovenop.

Een eigen berichttype voor een productcatalogus, een koppeling met het systeem van een klant, een formulier dat meer doet dan een mailtje sturen. Dat is back-end werk, alleen binnen een bestaand kader. Je haakt daarbij in op de plekken die WordPress zelf aanbiedt, en sinds versie 4.7 uit 2016 kun je de inhoud ook via de ingebouwde REST-API benaderen, wat koppelingen met andere systemen een stuk eenvoudiger maakt.

Belangrijk daarbij: bouw maatwerk in een eigen plugin en niet in je thema. Anders ben je alles kwijt zodra het uiterlijk verandert. En pas nooit de bestanden van WordPress zelf of van een plugin aan, want de eerstvolgende update overschrijft dat.

Wanneer is maatwerk terecht? Als een handeling elke week terugkomt en handwerk is, als gegevens tussen twee systemen worden overgetikt, of als een bestaande plugin negentig procent doet en die laatste tien procent je bedrijf raakt. Anders is een plugin die goed wordt onderhouden bijna altijd goedkoper, ook op de lange termijn.

Hoe je het leert

Begin bij de basis van programmeren in één taal, en kies er één. Van taal wisselen voordat je de eerste beheerst is de meest gemaakte fout.

Leer daarna hoe databases werken, want dat is waar het meeste misgaat. Zorg dat je snapt wat een relatie tussen tabellen is en hoe je een fatsoenlijke zoekopdracht schrijft.

Bouw daarna iets dat je zelf wilt hebben. Een cursus afmaken levert minder op dan één project waar je echt doorheen moet, met alle vastlopers die erbij horen.

En leer versiebeheer met git vanaf dag één. Dat is geen luxe, dat is hoe je jezelf redt als je iets sloopt. Wat je daarmee kunt staat bij GitHub.

Leer verder hoe een server werkt, ook als je geen beheerder wilt worden. Weten waar logbestanden staan, hoe je een dienst herstart en wat een rechtenprobleem is, scheelt je in de praktijk meer tijd dan de zoveelste taalfunctie.

Veelgestelde vragen over back-end ontwikkeling

Wat is het verschil tussen front-end en back-end ontwikkeling?

De front-end is alles wat in de browser draait en wat de bezoeker ziet en aanraakt. De back-end is alles wat op de server draait: gegevens opslaan, rechten controleren, betalingen verwerken, mails versturen.

Een handige toets: kun je het zien door met de rechtermuisknop de broncode te bekijken, dan is het de voorkant. Zit het achter een inlog of in een database, dan is het de achterkant.

Welke programmeertaal kan ik het beste leren voor back-end?

PHP als je met websites wilt werken en zeker als je richting WordPress gaat, want daar draaien in Nederland heel veel zakelijke websites op. Python als je richting data of automatisering wilt. JavaScript met Node.js als je toch al de voorkant doet en in één taal wilt blijven.

Is PHP nog steeds een goede keuze?

Ja. De taal is sinds versie 8 aanzienlijk sneller en strenger geworden, en er is meer dan genoeg werk in. De slechte reputatie stamt uit de tijd van PHP 5 en uit oudere code die niemand vandaag meer zo zou schrijven.

Heb ik back-end ontwikkeling nodig voor een gewone bedrijfswebsite?

Meestal niet als apart bouwwerk. Een WordPress-site heeft de achterkant al: gebruikers, formulieren, media, een database. Je hebt wel iemand nodig die het beheert, want updates, back-ups en beveiliging horen ook tot dit vak.

Wat kost maatwerk aan de achterkant?

Dat hangt vrijwel volledig af van de koppelingen. Een eigen berichttype met een paar velden is een dag werk. Een koppeling met een boekhoud- of voorraadsysteem loopt op, omdat je moet omgaan met fouten, dubbele meldingen en gegevens die niet netjes zijn. Vraag altijd een prijs voor het onderhoud erbij, want die post komt anders later alsnog.

Wat is een API precies?

Een afspraak waarmee twee systemen gegevens uitwisselen zonder dat er een mens tussen zit. Jouw site vraagt bijvoorbeeld aan een verzendpartij om een pakketlabel, en krijgt daar een bestand en een volgnummer voor terug. Je hebt er een nodig zodra je iets wilt automatiseren dat nu wordt overgetikt.

Welke database moet ik kiezen?

Voor een website met WordPress heb je geen keuze: dat is MySQL of MariaDB. Bouw je iets nieuws, dan is PostgreSQL een uitstekende standaardkeuze. Een database zonder tabellen, zoals MongoDB, is pas logisch als je gegevens echt geen vaste vorm hebben, en dat komt minder vaak voor dan gedacht.

Hoe veilig is WordPress?

De kern zelf is redelijk veilig en wordt actief onderhouden. De problemen komen vrijwel altijd van plugins en thema's die niet zijn bijgewerkt, van zwakke wachtwoorden en van beheerders die niemand meer kent. Minder plugins, alles bijwerken en tweestapsverificatie aanzetten lost het overgrote deel op.

Moet ik updates automatisch laten uitvoeren?

Beveiligingsupdates van de kern: ja, laat die automatisch draaien. Grote versiesprongen en plugins: liever met de hand, na een back-up, met een controle achteraf. Een automatisch bijgewerkte site die twee weken stuk staat zonder dat iemand het merkt is duurder dan het uitgespaarde kwartier.

Waar moet mijn website staan volgens de AVG?

De AVG schrijft geen locatie voor, maar hosting binnen de Europese Unie scheelt je de discussie over doorgifte naar landen daarbuiten. Let daarbij ook op je back-ups en je mailverkeer, want daar staan dezelfde persoonsgegevens in en die lopen vaak via een andere leverancier. Vraag bij elke partij een verwerkersovereenkomst op; vrijwel alle Nederlandse hosters hebben daar een standaardversie voor.

Hoe lang duurt het om back-end ontwikkelaar te worden?

Reken op een half jaar tot een jaar serieus oefenen voordat je iets kunt bouwen dat mensen mogen gebruiken, en op een paar jaar voordat je zelfstandig verantwoordelijkheid kunt dragen voor een systeem waar geld doorheen gaat. Het bouwen leer je snel, het omgaan met fouten en beveiliging duurt langer.

Wat gebeurt er als mijn ontwikkelaar ermee stopt?

Dat hangt af van wat je hebt vastgelegd. Zorg dat je zelf eigenaar bent van je domeinnaam, je hosting en je code, dat de code in een versiebeheersysteem staat waar jij bij kunt, en dat er een pagina met wachtwoorden en afspraken ligt die een opvolger kan lezen. Wie dat op orde heeft, wisselt van bouwer in een week. Wie dat niet heeft, begint opnieuw.

Heb ik een aparte achterkant nodig voor een app?

Alleen als de app gegevens moet delen tussen gebruikers of apparaten. Een app die alleen op de telefoon zelf werkt heeft niets nodig. Zodra er accounts, meldingen of gedeelde gegevens bij komen, heb je een server nodig, en dan kan een bestaande website daar vaak de basis voor zijn.