Infowijs was een van de sponsoren van de Kotlin Dev Day (Advanced Edition) op 24 november 2022. Vorig jaar deelde ik al over het technisch verleden en de toekomst van Infowijs. Inmiddels ruim een jaar verder geef ik iets meer een kijkje in de keuken waarom die transitie zo belangrijk voor ons is na de enorme groei van Hoy.
Onze producten, Hoy en Schoolwiki, zijn oorspronkelijk gebouwd in de programmeertaal PHP met MySQL als database. Toen ik 3 jaar geleden bij Infowijs kwam werken hebben we de keuze gemaakt om de bestaande applicaties om te gaan schrijven naar een combinatie van Kotlin met Vert.x en Postgres als database. Met name door de relatief snelle groei die Infowijs had doorgemaakt ontstonden er namelijk een aantal knelpunten. De programmeertaal Kotlin heeft in tegenstelling tot PHP veel meer mogelijkheden om asynchroon te werken. Dit in combinatie met het hoge responsieve karakter van Vert.x als toolkit wat ons veel schaalvoordeel geeft tegen minimale (AWS) server kosten. Dit, nu 3 jaar later, werkt enorm in ons voordeel. In het afgelopen jaar is onze groei fenomenaal geweest, het gebruik van Hoy is in 1 jaar tijd bijna verdubbeld en waar we in april 2021 al meer dan 150 requests per seconde moesten verwerken, zitten we inmiddels op gemiddeld 300 requests per seconde.
Om die enorme groei bij te benen hebben we naast de grote verandering in onze code, er ook voor gekozen om de nieuwe services met een nieuw type database te laten werken. Door Postgres in te zetten in plaats van MySQL hebben we een bredere ondersteuning voor zogenaamde "JSON storage" binnen onze relationele modellen. Waardoor we het beste van Relational Databases en NoSQL kunnen toepassen. Dit is voor ons heel belangrijk omdat we met veel verschillende rollen werken. Ouders, leerlingen, mentoren, docenten en schoolbeheerders worden bij schooladminstratiesystemen, zoals Magister en Somtoday, vaak als aparte modellen gezien. Binnen onze applicatie proberen we geen onderscheidt te maken tussen die modellen en zien wij al die rollen als "mensen" binnen ons systeem. Maar al die verschillende rollen die die mensen hebben komen met heel verschillende datasets. Onze databases en applicaties moeten dus om kunnen gaan met die grote flexibiliteit.
Met zoveel verschillende soorten datasets per rol moet ons systeem continu kunnen schakelen welke informatie voor wie van belang is.
Laten we eens inzoomen op die verschillende datasets, want hoe ziet dat er dan uit? Van leerlingen weten we in welke klas of klassen ze zitten, binnen welke schooljaren en wie hun mentor(en) en ouders zijn. Maar van docenten en mentoren weten we bijvoorbeeld ook op welke schoollocatie ze les geven, van welke klassen ze mentor zijn en welke lessen zij geven.
Hier zo'n geabstraheerd voorbeeld van een dataset van een leerling
De leerling heeft studentnummer 62151 Zit in schooljaar 2021-2022: Zit in klas dV2A Zit in leerjaar 2 Zit in niveau VWO_2 Op locatie Bellastraat En in schooljaar 2022-2023: Zit in klas dV3 Zit in leerjaar 3 Zit in niveau VWO_3 Op locatie Deltastraat
Om het verschil aan te tonen, hier een geabstraheerd voorbeeld van een dataset van een mentor
De mentor heeft medewerkernummer 62151 Is mentor van klas dV3 Heeft ook als functie Docent Biologie Werkt op locatie Deltastraat In schooljaar 2023-2023 Geeft deze docent lessen Biologie Aan klas BIO4D
Zoals je hierboven ziet zijn de verschillen tussen de data die we nodig hebben voor de ene rol heel anders vormgegeven dan die van een andere rol.
Naast de flexibiliteit die we dus van onze database nodig hebben, halen we ook veel voordeel uit de korte lijnen die we hebben tussen de verschillende (micro)services die we hebben gebouwd. Dit doen we via de Vert.x Eventbus. Door informatie snel tussen services uit te wisselen is er een beperkte "latency" en blijft het systeem heel erg reactief. Zeker in combinatie met Kotlin Coroutines is het schrijven van code voor onze developers een fijne aangelegenheid. Onze code is compact, gemakkelijk aan te passen en de doorlooptijd van het implementeren van nieuwe features in onze nieuwe systemen zijn daardoor hoog. De tijd die we nodig hebben om een nieuwe feature uit te rollen of een bug te fixen kan bij ons een kwestie van minuten zijn.
Doordat we snel features én fixes uit kunnen rollen houden we de hoge flexibiliteit die onze klanten van ons verwachten en kunnen we nóg beter in co-creatie met de scholen aan de slag!
En of dit hele verhaal financieel dan een beetje rendabel is? Voor lagere AWS kosten dan ons oorspronkelijke platform met de PHP monoliet en zware MySQL servers verwerken we nu gemakkelijk vele duizenden requests meer en dan draaien we nog niet eens op de toppen van onze (virtuele) hardware.