Van Concept naar Code: De weg naar een real-time dashboard

Buiten mijn comfortzone: Een Java-developer duikt in Vue

Als student Full Stack Developer met een focus op Java voelde frontendontwikkeling altijd een beetje als buiten mijn terrein. Toch kreeg ik bij Dennenboom de kans om precies dát te doen: me vastbijten in de frontend van een nieuwe Monitor App. Spannend, maar ook de ideale gelegenheid om mijn vaardigheden te verbreden.

Het doel van de applicatie was helder:

1. Een globaal overzicht bieden van alle lopende projecten en hun ‘gezondheid’
2. Snel inzicht geven in foutmeldingen via interactieve charts, zoals 30-dagen-overzichten en specifieke healthchecks

Wat begon als “even een frontend bouwen”, groeide al snel uit tot een project dat mijn kijk op architectuur, real-time systemen en testing blijvend heeft veranderd.

Van chaos naar structuur met Pinia

In het begin probeerde ik zoveel mogelijk logica in de frontend zelf te verwerken. Dat leek efficiënt, maar leidde al snel tot een wirwar van data die van component naar component werd doorgegeven. Overzicht verdween en onderhoud werd lastig.

De oplossing bleek Pinia: een centrale plek waar state eindelijk overzichtelijk werd:

1. De applicatie een duidelijke structuur
2. Berekeningen en data-opslag werden verplaatst naar één centrale plek
3. De code werd meteen een stuk leesbaarder en onderhoudsvriendelijker

Dit was voor mij het moment waarop ik écht begreep waarom een centrale source of truth onmisbaar is in moderne frontendapplicaties.

Visualisatie: De gezondheid in beeld

Om de data echt begrijpelijk te maken, heb ik twee typen visualisaties ontworpen. De 30-daagse Health-Matrix toont de globale stabiliteit per dag in groen, oranje en rood.

Voor de details is er de Uur-Heatmap, waarbij je exact kunt zien op welke dag en uur een healthcheck faalde.

Het was een uitdaging om deze complexe datastructuren vanuit de backend om te zetten naar een helder beeld, maar het is dé manier waarop Dennenboom nu "kort op de bal" kan spelen.

De overstap naar Laravel: kracht en elegantie

Hoewel ik oorspronkelijk voor de frontend kwam, trok de backend al snel mijn aandacht. We kozen voor Laravel, met Sanctum voor authenticatie. Voor iemand met een Java-achtergrond voelde dat in het begin als een cultuurschok.

Waar Java sterk leunt op expliciete types en volledige controle, neemt Laravel veel werk uit handen via abstracties en conventies. Als developer die graag precies weet wat er onder de motorkap gebeurt, moest ik leren vertrouwen op die “magie”. Gaandeweg begon ik echter de kracht ervan te waarderen: je boekt razendsnel resultaat zonder overzicht te verliezen.

We maakten een duidelijke architecturale keuze:

1. Alle statusberekeningen en database-acties verhuisden naar de backend
2. De frontend bleef clean en focuste zich puur op visualisatie

Met Models, Factories en Seeders leerde ik efficiënt met data omgaan. Vooral factories om snel realistische testdata te genereren vond ik verrassend prettig werken — vlotter dan ik gewend was in Java.

Geen F5 meer nodig: real-time magie met Reverb

Een dashboard dat je handmatig moet verversen, voelt niet als een echt dashboard. Daarom besloten we real-time updates te implementeren met Laravel Reverb en WebSockets.

Het concept:

1. De backend voert elk uur een healthcheck uit via een cronjob
2. De resultaten worden direct gebroadcast naar de frontend
3. Het dashboard werkt live bij, zonder refresh

WebSockets zijn efficiënter dan traditioneel polling omdat de server updates actief naar de client pusht in plaats van dat de client constant vraagt om nieuwe data. Dit vermindert niet alleen netwerkverkeer, maar vergroot ook de schaalbaarheid van het dashboard aanzienlijk, vooral bij meerdere gelijktijdige gebruikers.

De implementatie van een WebSocket-server was nieuw en soms uitdagend, maar het eindresultaat — een dashboard dat daadwerkelijk leeft — maakte dit een van de meest leerzame onderdelen van het project.

De harde les: testen is geen luxe

Tijdens het ontwikkelen had ik af en toe een wrang gevoel: werkt alles echt zoals het hoort? Dat was voor mij het signaal om me te verdiepen in testing binnen Laravel, met Pest.

Na het schrijven van tests kwamen er inderdaad enkele subtiele bugs aan het licht. Dat moment was confronterend, maar ook leerzaam. De conclusie was duidelijk:

testen hoort niet aan het einde, maar aan het begin van het ontwikkelproces.

Opnieuw bewezen factories hun waarde door het snel opzetten van consistente testdata

De laatste stap: van code naar productie

Met werkende code en groene tests volgde de laatste uitdaging: deployment. Via een professionele setup in Plesk leerden we hoe je een applicatie daadwerkelijk live zet, inclusief serverconfiguratie en subdomeinen. Daarmee viel voor mij het laatste puzzelstukje op zijn plek.

Reflectie: Wat ik heb meegenomen uit dit project

Terugkijkend was dit project veel meer dan “een app bouwen”. Het heeft mijn manier van denken als developer veranderd:

1. Architecturaal inzicht: het bewust scheiden van frontend en backend maakte de applicatie schaalbaarder en rustiger
2. State management: Pinia liet me het belang van een centrale waarheid écht begrijpen
3. Real-time mindset: met Reverb zag ik hoe een statische pagina verandert in een dynamisch systeem
4. Framework-waardering: Laravel leerde me vertrouwen op conventies zonder controle te verliezen
5. Test-driven denken: testen is geen bijzaak meer, maar een vast onderdeel van mijn workflow
6. Deployment-ervaring: van code tot cloud — ik begrijp nu het volledige plaatje

Afsluiting

Dit project was voor mij de perfecte brug tussen theorie en praktijk. Ik ben Ben en het team van Dennenboom enorm dankbaar voor de ruimte om te experimenteren, fouten te maken en uiteindelijk een product neer te zetten waar we trots op kunnen zijn. Dit project heeft me niet alleen een betere developer gemaakt, maar vooral een bewustere architect.

Op naar de volgende uitdaging!