Een eigen website bouwen biedt meer dan een plek om jezelf te presenteren. Voor mij werd het een manier om de samenhang tussen content, applicatieontwikkeling en infrastructuur beter te begrijpen. Van Drupal en Next.js tot GitHub en Docker: door zelf de keten te doorlopen, kregen technische keuzes een concrete betekenis.
Een bewuste scheiding
Bij het bouwen van mijn website wilde ik de content gescheiden houden van de vormgeving en de applicatie die deze presenteert. Ik wilde mijn teksten kunnen beheren zonder daarvoor steeds de code van de website te moeten aanpassen.
Drupal biedt veel flexibiliteit, maar bij het bouwen binnen een CMS werk je ook binnen de structuur van dat systeem. Voor de presentatie wilde ik meer ontwerpvrijheid.
De mogelijkheid om Drupal headless te gebruiken gaf voor mij de doorslag. Drupal bleef verantwoordelijk voor het contentbeheer, terwijl ik met Next.js een afzonderlijke voorkant kon bouwen. De inhoud kon zo beschikbaar worden gesteld aan de applicatie die deze op het scherm presenteert.
Die gedachte begreep ik. Hoe ik dat daadwerkelijk moest realiseren, wist ik nog niet.
Van ingevoerde tekst naar een werkende pagina
Tijdens het bouwen kreeg de structuur van de website geleidelijk vorm. Een belangrijk onderdeel daarvan was het bekijken van de gegevens die Drupal via JSON beschikbaar stelde.
Ik kon zien hoe mijn ingevoerde content terugkwam als gestructureerde tekst: titels, beschrijvingen, periodes en andere velden. Daarmee werd zichtbaar welke gegevens beschikbaar waren en hoe ik die in Next.js kon gebruiken.
De koppeling werd daardoor concreet. Een veld in Drupal kreeg een plaats op de website. Meerdere records konden worden weergegeven als een lijst of als kaarten. De contentstructuur en de presentatie hadden ieder hun eigen verantwoordelijkheid, maar moesten wel op elkaar aansluiten.
Door dat stap voor stap op te bouwen, begon ik steeds beter te begrijpen hoe de onderdelen samenwerkten.
Bouwblokken maken wijzigingen beheersbaar
Vanuit mijn werk wist ik al hoeveel gevolgen een kleine wijziging kan hebben. Daarom ben ik voorstander van applicaties die zijn opgebouwd uit duidelijke, herbruikbare bouwblokken.
Bij mijn website zag ik dat principe terug in componenten voor bijvoorbeeld kaarten, werkervaring en projectinformatie. Een gedeelde component maakt het mogelijk om de presentatie op meerdere plaatsen vanuit dezelfde basis te verzorgen.
Dat betekent niet dat iedere wijziging altijd op één plek kan worden uitgevoerd. Een nieuw contentveld kan bijvoorbeeld aanpassingen vragen in zowel Drupal als Next.js. Het helpt wel wanneer duidelijk is waar een verantwoordelijkheid ligt en dezelfde logica niet op verschillende plaatsen wordt herhaald.
Modulair bouwen vraagt dus ook om nadenken over de grenzen tussen onderdelen en de afspraken waarmee ze samenwerken.
De applicatie moet ook ergens draaien
Het leerproces bleef niet beperkt tot het bouwen van pagina’s. Ik leerde ook meer over werken met Visual Studio Code, wijzigingen vastleggen in GitHub en het overbrengen van die wijzigingen naar mijn server.
Nadat ik dat proces meerdere keren had doorlopen, werd de infrastructuur achter de website duidelijker. Een lokale wijziging was pas het begin. De aangepaste applicatie moest ook worden gebouwd en vervolgens op de server draaien.
Daarbij begon ik beter te zien waarom Docker bij deze opzet aansluit. De applicatie en haar uitvoeromgeving kregen een herkenbare plek in de inrichting. Tegelijkertijd bleven zaken als configuratie, bestanden en het actualiseren van de draaiende applicatie aandacht vragen.
Zo ontstond op kleine schaal een praktische ontwikkel-, test- en productieopzet. Die gaf mij de ruimte om wijzigingen eerst te bekijken voordat ik ze op mijn publieke website beschikbaar maakte.
Meer vrijheid vraagt om meer inzicht
De scheiding tussen Drupal en Next.js gaf mij de vrijheid die ik zocht. Daar kwam ook verantwoordelijkheid bij: ik moest zelf begrijpen hoe gegevens werden opgehaald, verwerkt en weergegeven, en hoe ik wijzigingen beschikbaar maakte.
Een geïntegreerd CMS met een thema kan uitstekend passen bij een bedrijfswebsite. Ook met PHP en WordPress kunnen complexe toepassingen worden gebouwd. Voor mij ging de keuze vooral over de gewenste scheiding en de ruimte om onderdelen zelfstandig te ontwikkelen.
Bij die afweging hoort de vraag hoeveel extra complexiteit je wilt beheren. Ontwerpvrijheid heeft pas waarde wanneer je ook begrijpt hoe je de oplossing werkend en onderhoudbaar houdt.
DevOps vraagt om betrokkenheid van beheer
De verbinding tussen ontwikkeling en beheer herken ik uit mijn dagelijkse werk. Ik vind het belangrijk dat ontwikkelaars, applicatiebeheerders en infrastructuurbeheerders vroeg met elkaar in gesprek gaan over wat een applicatie nodig heeft.
In de praktijk zie ik soms dat organisaties zeggen volgens DevOps te werken, terwijl applicatiebeheerders nog steeds aan het einde van het proces updates ontvangen en uitvoeren. De ontwikkelwerkwijze is dan veranderd, maar de overdracht naar beheer lijkt grotendeels hetzelfde gebleven.
Voor mij krijgt DevOps betekenis wanneer het team samen verantwoordelijkheid draagt voor wat er in productie draait. Dat vraagt ook om praktische kennis van elkaars werk. Ontwikkelaars moeten kunnen uitleggen wat hun applicatie van de infrastructuur verwacht. Beheerders moeten kunnen meedenken over de gevolgen van ontwerpkeuzes en wijzigingen.
Het bouwen van mijn website maakte die samenhang tastbaar. Ik kon zelf volgen hoe een keuze in de contentstructuur doorwerkte in de code en uiteindelijk in de draaiende applicatie.
Die ervaring neem ik mee in mijn werk: betere vragen stellen, afhankelijkheden zichtbaar maken en ontwikkeling en beheer vanaf het begin met elkaar verbinden.