The Park Playground: Operationeel Platform

The Park Playground is een entertainmentbedrijf waar mensen in groep free roam VR-games kunnen spelen.

Het operationele platform van The Park was een project dat nog actief in ontwikkeling was toen ik er begon. Dashdot, het web development bureau dat het platform oorspronkelijk had gebouwd, gaf me toegang tot de project repositories, waarna ik via pull requests met hen samenwerkte. Het project bestond uit drie repositories:

1. Een backend API in PHP, gebouwd met Laravel
2. Een operationele platform frontend, gebouwd met ReactJS en Redux
3. Een ticketing frontend, gebouwd met ReactJS

De grootste uitdaging bij dit project was dat zowel de backend (PHP) als de frontend (JS) niet statically typed waren. De gebruikte PHP-versie was minstens 7.X, die gelukkig al enige ondersteuning bood voor type hints, maar Dashdot's codebase maakte daar nauwelijks gebruik van. Dat betekende dat ik sterk moest leunen op trial-and-error en logging om de structuur van de meeste data modellen te begrijpen.

Nog erger: de frontend was geschreven in vanilla (niet-Typescript) ReactJS en gebruikte Redux middleware om inkomende data te transformeren, wat het onboarden en debuggen veel moeilijker maakte dan nodig was. Deze ervaring bevestigde voor mij dat statically typed languages bijna uitsluitend de betere optie zijn. De kleine extra inspanning aan het begin loont meermaals naarmate een project groeit. Kort samengevat: wees vriendelijk voor je toekomstige zelf en collega's.

Tegen eind 2021 namen wij, of ik liever, de volledige ontwikkeling** van de projecten over van Dashdot en hostten we ze zelf. Terwijl ik verschillende onderdelen van de backend onder handen nam en refactorde, maakte ik het project geleidelijk aan beter onderhoudbaar.

Een van de grotere features die ik bouwde, was een systeem waarmee twee speelvelden konden geboekt worden voor Nanoclash, een competitieve shooter waarin twee teams het tegen elkaar opnemen. Intern werden deze velden opgedeeld in tijdsloten, die moesten worden gevalideerd aan de hand van meerdere voorwaarden om te bepalen of ze beschikbaar waren en dus konden worden geboekt. Ik herschreef dit systeem volledig en introduceerde echte types (in plaats van PHP-associatieve arrays en string keys) en optimaliseerde de performance van het berekenen van tijdschema's en hun beschikbaarheid. Uiteindelijk kon het systeem ongeveer 88.000 tijdslot vergelijkingen uitvoeren in één seconde, iets waar ik nog steeds best trots op ben. Dankzij een combinatie van doordacht ontwerp, efficiënte SQL-queries en degelijke database-engineering leverde ik aanzienlijke performance verbeteringen op in de backend. Bijvoorbeeld: het ophalen van de geboekte tijdsloten van de dag, een actie die medewerkers van The Park bijna elke minuut uitvoerden, ging van 9–10 seconden naar ongeveer ~800 ms.

Tegen de tijd dat ik The Park verliet, werkte ik graag aan de backend. Met uitgebreide type hints en de vele kwaliteitsverbeteringen van PHP 8.x was het een aangename omgeving om in te werken. Helaas gold dat niet voor de frontend.

Was het onmogelijk om aan de operationele frontend te werken? Nee. Was het leuk? Ook nee. Het gebrek aan typering en de zware afhankelijkheid van Redux-middleware data transformaties maakten het tot het meest frustrerende project binnen The Park. Het werd zelfs zo erg dat wij (de developers) blad-steen-schaar speelden om te beslissen wie de bug moest oplossen wanneer er ééntje gemeld werd. Na verloop van tijd werd het een echt Frankenstein project, waarbij nieuwe features bewust Redux probeerden te vermijden. Waar mogelijk, verbeterden we de leesbaarheid door JSDoc type annotations toe te voegen, maar het bleef een pijnlijk project om in te werken.

De applicatie had bovendien geen responsive design, tot grote frustratie van de medewerkers van The Park, die altijd een laptop moesten openen om de app te gebruiken. Ik had de app graag volledig herontworpen en herschreven, maar jammer genoeg kreeg dat nooit prioriteit van het management.