Research
frontend
Als eerste gaan we het hebben over de backend keuze, want dat was het makkelijkste. Ik heb hier een opsomming van vergelijkingen waar ik achter ben gekomen door mijn onderoek. Express is gemaakt in javascript en voor javascript. Nu heeft het wel een port voor Typescript, maar het is nie thet meest fijne, volgen s mijn bronnen. NestJS is gebouwd als Typescript first, alles is dus volledig supported. Fastify heeft typescript support maar mist dingen zoals decorators. Verder was het plan dat we een ONION architecture gingen gebruiken, dus had ik dependency injection nodig, dit kan je in Express en Fastify doen maar daarvoor heb je externe libraries nodig. in NestJS is het ingebouwd. Verder heeft NestJs ook al JWT support en throttling ingebouwt wat het leven een stuk makkelijker gemaakt. Dus NestJS was voor mij een relatief makkelijke keuze.
Nu komen we bij de chaos.
Ik moest gaan uitzoeken wat het beste was voor dit project, en gelukkig kregen we hier wat voorbeeld vragen voor. Hoe makkelijk is het om te leren?, Hoe goed werkt het met TypeScript? etc. Nu zijn de simpele vragen makkelijk te beantwoorden want iedereen op het internet weet dat React het meest gebruikte framework is met de grootste community. Maar wanneer je naar andere dingen wil kijken, om te kijken wat beter is, dan zit er veel nuance in.
Dit is niet de eerste keer dat ik deze presentatie geef, en ik heb dus ook 2 keer onderzoek gedaan, niet omdat ik voor de herkansing een nieuwe taal zou kiezen, maar uit intresse om te zien of er dingen verandert zijn. De eerste keer dat ik dit onderzoek deed was ik uitgekomen op React samen met NestJS, dat is omdat mijn bronnen zeiden dat React meer toekomst bestendig is, React is industry standard, React is goed in prestatie vergeleken met de rest. En na het schrijven van een document van 2700 woorden had ik dus deze keuze gemaakt.
Maar toen ik de 2e keer onderzoek deed, en meer googlede op globale zoektermen in plaats van āReact vs Angularā kwam ik er achter dat ik niet zo goed bezig was geweest. Want het blijkt dus dat developers nogal biased zijn wanneer ze hier over schrijven. Het echte antwoord licht een stuk genuanceerder. En na het weer schrijven van een lang document, kwam ik tot de realisatie dat afhankelijk aan wie je het vraagt, React, Angular, Svelte en Vue een stuk dichter op elkaar liggen. Maar om tot een conclusie te moeten komen heb ik alle data proberen op te sommen in een tabel waar alles een score krijgt van 0 tot 10, en dat zijn nummers die ik heb bedacht gebaseerd op wat ik in het 2e onderzoek heb gelezen. Hier kwam naar buiten dat React en Vue even goed zijn:
| Criterium | React | Angular | Svelte | Vue |
|---|---|---|---|---|
| 1. Leesbaarheid & Voorbeelden | 8/10 | 6/10 | 9/10 | 9/10 |
| 2. TypeScript Ondersteuning | 8/10 | 10/10 | 9/10 | 9/10 |
| 3. Community Grootte (Actief) | 10/10 | 7/10 | 6/10 | 8/10 |
| 4. Framework Onderhoud & Updates | 9/10 | 9/10 | 8/10 | 9/10 |
| 5. CLI & Startsjablonen | 8/10 | 9/10 | 8/10 | 9/10 |
| 6. Documentatie Kwaliteit | 8/10 | 9/10 | 9/10 | 9/10 |
| 7. Bundle Size Performance | 7/10 | 4/10 | 10/10 | 8/10 |
| 8. Extensibility & Libraries | 10/10 | 8/10 | 7/10 | 9/10 |
| 9. Bedrijfsadoptie & Jobmarkt | 10/10 | 9/10 | 5/10 | 8/10 |
| 10. Toekomstbestendigheid (2026-2029) | 9/10 | 8/10 | 7/10 | 9/10 |
| TOTAAL | 87/100 | 79/100 | 78/100 | 87/100 |
Dus wat zijn de grootste verschillen dan? Nou, React heeft meer libraries, en meer adoptie in het bedrijfs leven. Maar Vue heeft betere Typescript support omdat het bij React de plugins niet perse suport voor typescript hebben. En ook is de documentatie en voorbeelden library van Vue groter dan die van React. En als we dan kijken naar Svelte, die is weer beter in Bundle size optimisation, En Angular is de GOAT van typescript support, want het is in typescript geschreven en is met default instellingen heel strict.
Maar wat betekent dit nu? was dit een goede keuze dat ik voor react was gegaan? Ja, React is een goed framework, maar had ik achteraf beter iets anders kunnen kiezen? Ik denk het wel, want voor dit project hebben we niet perse die grote library aan extensions nodig van React, want ik heb alles kunnen maken in de app zonder veel react libraries te installeren. Achteraf gezien zou ik voor Svelte zijn gegaan voor de kleine bundel size wat efficient is voor een telefoon applicatie die op 4g bekeken gaat worden.
Backend
Hoe zit het met de backend? Deze keuze was een stuk makkelijker, NestJS heeft ingebouwde typescript support, Het heeft ingebouwde mongodb support, het heeft ingebouwde testing.
| Criterium | Express | NestJS | Fastify |
|---|---|---|---|
| 1. Leesbaarheid & Voorbeelden | 9/10 | 8/10 | 8/10 |
| 2. TypeScript Ondersteuning | 5/10 | 10/10 | 8/10 |
| 3. Community Grootte (Actief) | 10/10 | 8/10 | 6/10 |
| 4. Framework Onderhoud & Updates | 8/10 | 9/10 | 8/10 |
| 5. CLI & Startsjablonen | 3/10 | 10/10 | 4/10 |
| 6. Documentatie Kwaliteit | 8/10 | 10/10 | 8/10 |
| 7. MongoDB Integratie & ORM Support | 8/10 | 9/10 | 8/10 |
| 8. Built-in Testing & DI | 4/10 | 10/10 | 6/10 |
| 9. Bedrijfsadoptie & Jobmarkt | 9/10 | 8/10 | 5/10 |
| 10. Toekomstbestendigheid (2026-2029) | 8/10 | 9/10 | 8/10 |
| TOTAAL | 82/100 | 91/100 | 73/100 |
Architecture
Voor dit project moesten we kijken hoe de ONION architecture in elkaar zit, en het toepassen. Dit was een hele andere manier van applicaties bouwen die ik nog nooit heb gebruikt. Mijn applicatie bestaat uit 4 lagen, de presentatie, infrastructure, applicatie en domein lagen.
- Domain, dit zijn de Entities en interfaces. data structuur en niks meer.
- Application, dit zijn de use cases en de DTOs. Use cases zijn single responsability en afhankelijk van de entities en interfaces van laag 1.
- Infrastructure, De repositories en de mappers. Mappers worden gebruikt om te converteren tussen de Entities van laag 1 en de database modellen. Ook is er een persistence module die de dependency injection regelt.
- Presentation, dit zijn de controllers die dus alles aansturen gebaseerd op webrequests.
Nu is het onion architectuur een beetje misleidend, want het doet zich voor alsof het allemaal lagen zijn die op elkaar liggen, maar dan kom je aan bij de Infrastructure laag en dan klopt het niet echt, want de infrastructure laag zorgt er voor dat de dependency injection van de domain in de application laag werkt, dus eigenlijk moet de infrastructure laag tussen application en domain, als je kijkt in de logica van āalleen depending op lagen er onderā, maar dat klopt dan ook weer niet, dus daarom duurde het even voordat het klikte, en vind ik dat de bovenstaande schemas accurater zijn.
Zou ik dit aanraden? Ja en nee, het hangt van de scope van je project af. Voor een relatief klein project kan het veel overhead werk zijn. Maar voor grotere projecten vind ik dit zeker de moeite waard, want op deze manier kan je makkelijker fouten spotten, en met de opkomst van LLM agents die mensen loslaten in hun codebase is dit zeker een aanrader want het forceerd een structuur.
Requirements
Nu heb ik een flinke lijst van requirements voor mezelf opgezet, functionals en non functionals, hiervan wil ik er een paar specefiek uitlichten.
Non functional: De app moet veilig zijn, De app moet onder 2 seconden inladen
Functional: Een gebruiker moet zijn studie kunnen selecteren en gebaseerd op zijn studie een lijst van aanbevolen modules krijgen. Een gebruiker moet modules kunnen toevoegen aan zijn favorieten, en zijn favorieten kunnen bekijken Een leraar moet modules kunnen toeveogen en aanpassen. Een leraar moet studies kunnen toevoegen en aanpassen. De app moet instlalleer baar zijn als PWA De app moet vertalingen hebben.
Er zijn er nog meer, dit is terug te lezen in het ingeleverde document. Alles gaat via JWT tokens. Wachtwoorden worden gehashed. Gebruikers input wordt gevalideerd op NoSQL injectie en cross site scripting.
De app laadt op al mijn apperaten binnen 1 seconde.
De UI is gedesigned voor telefoons, en is op alle chrome devtool telefoon groottes goed bruikbaar.
Deze functional requirements wil ik zometeen laten zien in de demo.
Testing
Een belangrijk gedeelte van development is checken of dat je code nogsteeds doet wat het ooit deed en zou moeten doen, hiervoor schrijf je testen. Ik heb frotnend en backend testen. De frontend testen heb ik gedan met cypress, en de backend testen zijn gemaakt met NestJS. Deze testen start je door npm run test te doen.
De frontend testen controleren of je bij alles pas kan als je de goede rechten hebt, en of dat de meeste functionaliteit werkt. De frontend heeft ongeveer 80% coverage.
In de backend gebruiken we het NestJS built-in testing framework. En deze hebben 75% coverage:
Ook heb ik een testplan, die is mee gelevert in de documentatie.
CICD
Ik gebruik de CICD van Github Actions om automatisch de website en backend te deployen. Ik wil hier even doorheen lopen. Als de frontend naar main gepushed wordt dan testen we alseerste of alle testen nog werken. Als die testen slagen en er geen error is gevonden, dan hosten we de website met github pages. De rede dat ik github pages gebruik is omdat de website statisch is, en ik graag https wilde enforcen. Maar ik heb geen SSL certificate, dus ik zou geen https kunnen enforcen als ik het zelf zou hosten, tenzij je zoān warning wil krijgen van chrome met de text āweet je zeker dat je deze website wilt bekijkenā.
Wanneer de testen falen wordt de website ook niet gepublished en blijft hij op de vorige versie.
Bij de backend is het idee het zelfde, als eerste runnen we de tests, en als de testen falen stoppen we.
Als de testen wel geslaagd zijn, dan doorlopen we de volgende stappen, als eerste sturen we de image van de backend naar dockerhub. Daarna gebruiken we SSH om mijn VPS binnen te gaan, en vanuit daar pullen we da laatste docker image vanaf dockerhub. En dan staat officieel de nieuwe versie van de backend online.
Database
Voor de database moesten we werken met mongodb. Dit is een non-relational database en dat betekent dat het eigenlijk niet de norm is dat je veel relaties hebt tussen tables, en dat je eigenlijk maar alle data dumpt in 1 collectie. Dat betekent dat waar je normaal bij sql veel koppeltabellen zou maken, je het in mongodb als json list of dictionary in het zelfde object opslaat.
Ik heb een ERD gemaakt om te proberen te laten zien hoe mijn structuur er uit ziet:
En hierbij heb ik alle embedded objecten, zoals de dictionaries omgezet met een laag streepje. Dus title_dutch en title_english zijn 2 velden die in het title object zitten.
Verder had ik eerst mijn mongodb draaiende op mijn eigen vps, maar omdat ik zelf nog niet de tijd had om uit te zoeken hoe ik dat veilig moest doen, ben ik later teruggeswitched naar mongodb atlas
Demo
Conclusion
Dit was mijn proof of concept. Ik heb veel geleerd van dit project, Dat wanneer ik op zoek ga naar vergelijkingen, dat ik beter kan googlen op bijde kanten van de BIASED reviews, in plaats van neutraal te zoeken en dan mogelijk maar 1 van de BIASED meningen krijgen.
Ook heb ik geleerd over mongodb en de ONION wat nuttige ervaringen zijn, want nu kan ik zelf kijken naar wanneer het beter is om het toe te passen, in plaats van dat ik eerst voeral SQL voor gebruikte heb ik nu de mogelijkheid om af te wegen wat slim is.