Deze week heb ik me gericht op de werking van Node.js en NPM packages. Ik heb documentatie doorgelezen over Node en verschillende NPM packages. Uit mijn onderzoek heb ik de volgende bevindingen gedaan:

• Node.js: Een runtime-omgeving voor JavaScript, en vormt het fundament van het project. Alle verschillende NPM packages die we deze weken gaan gebruiken, worden door Node.js beheerd en door NPM gedownload
• Express: Voegt backend-functionaliteiten toe, zoals het opzetten van een localhost, URL-encoding en routing. Express is ook een dependency voor andere packages zoals express-session.
• EJS: Biedt ondersteuning voor de EJS-taal en views. EJS is een templating language bovenop de frontend HTML, die backend communicatie en het dynamisch genereren van lijsten makkelijker maakt. Bestanden krijgen nu de naam titel.ejs in plaats van titel.html. Er is ook een Visual Studio Code plugin om programmeren in EJS makkelijker te maken. EJS word door de HTML heen geschreven en moet tussen <% en %> geschreven worden.
• Nodemon: Versnelt de ontwikkelworkflow door het project automatisch opnieuw op te starten na wijzigingen in de code. Nodemon is in tegenstelling tot de eerder genoemde packages, alleen bedoeld voor gebruik tijdens de ontwikkeling en moet niet actief zijn wanneer het project daadwerkelijk is gedeployed.

Ik heb onderzoek gedaan naar de beste manieren om een Node.js-project op te zetten en in te delen. Door mijn eerdere werkervaring met Laravel en Symfony tijdens eerdere stages had ik al basiskennis van package managers en server-side programming. Ik heb me verdiept in de best practices voor de file structure van Node.js en hoe ik deze tijdens dit project kan volgen.

Net als Symfony en Laravel, heeft Node.js een best practice file structure. Het verschil is dat bij Node.js deze structuur niet automatisch wordt ingesteld. De developer moet zelf alle bestanden aanmaken en configureren. In Node.js kun je functies zoals databaseconnecties, routing, controllers en middleware scheiden.

• Routing: In het routing-bestand staan alleen de routes van de frontend naar de controllerfuncties of EJS-bestanden. In de router wordt geen data verwerkt, maar wel doorgestuurd.
• Controllers: Het controllerbestand bevat alle functies voor CRUD (Create, Read, Update, Delete). Maar ook functies zoals de login en logout.
• Middleware: Middleware bestanden bevatten code die tussen de frontend en de backend wordt uitgevoerd. Een voorbeeld van een middlewarefunctie is het parsen van frontend data, zodat deze eenvoudig in de backend kan worden verwerkt (urlencoded).

Met deze opzet kun je de code beter structureren en onderhoudsvriendelijker maken, maar ook er voor zorgen dat de developer niet meerdere keren de zelfde code moet schrijven. Door code te splitsen kan een developer stukken code opnieuw gebruiken of samenvoegen om dubbele code te voorkomen.

Tijdens het opzetten van Node.js en de GitHub repository hebben we als groep besloten om best practices qua file structure te volgen. Door aparte folders en bestanden te maken voor de verschillende functionaliteiten, zoals controllers, models, routers en middleware, wordt het project overzichtelijker en kan dit de workflow verbeteren.

De stappen die we hebben ondernomen zijn als volgt:

1. Structureren van de projectmap:
   • We hebben aparte mappen aangemaakt voor controllers, models, routers en middleware.
   • Het opzetten van de file structure is moeilijker vergeleken met een enkele app.js.
   • Deze structuur zorgt ervoor dat de verantwoordelijkheden duidelijk gescheiden zijn en de code beter onderhoudbaar is.
2. Configureren van GitHub:
   • We hebben een .gitignore bestand aangemaakt om te voorkomen dat ongewenste mappen, zoals node_modules, worden gecommit.
   • GitHub biedt templates voor verschillende frameworks en package managers, inclusief Node.js, wat ons heeft geholpen bij het snel opzetten van de repository.
3. Opzetten van een lokale server:
   • Aan het einde van de week is het gelukt om een simpele localhost op te zetten.
   • We hebben de server getest door een simpele route toe te voegen en deze succesvol in de browser te tonen.
4. Versiebeheer met Git:
   • We hebben succesvol onze eerste aanpassingen gecommit naar GitHub.
   • We hebben ook een development branch aangemaakt om aanpassingen beter bij te houden.

File structure

Klein stukje van de .gitignore

De eerste paar commits

Localhost test

• Node.JS File Structure
• Node.JS Docs
• Express
• EJS
• Nodemon

Om mijn kennis van Node.js te verbeteren, heb ik een eigen project opgezet dat parallel loopt met ons teamproject. Hierdoor kan ik zelf de verschillende functionaliteiten leren en toe passen terwijl ze door het team worden verdeeld. Hierdoor kan ik niet alleen mijn eigen vaardigheden uitbreiden, maar ook mijn teamleden beter ondersteunen wanneer zij tegen problemen aanlopen.

Deze week heb ik me verder verdiept in de verschillende NPM packages waarmee we tijdens dit project gaan werken. Ik heb onderzoek gedaan naar de volgende packages en hun functionaliteiten:

• ESLint: ESLint helpt bij het detecteren van fouten in JavaScript-code en zorgt ervoor dat de code consistent en volgens de best practices wordt geschreven. Het voorkomt veelvoorkomende programmeerfouten en verbetert de leesbaarheid van de code.
• Mongoose: Mongoose is een geavanceerdere versie van de MongoDB NPM package en biedt een eenvoudigere functies voor het uitvoeren van CRUD (Create, Read, Update, Delete). Het ondersteunt schema-gebaseerde datavalidatie en modeldefinities, wat helpt bij het structureren van de applicatie.
• Bcrypt: Bcrypt is een wachtwoord encryptie package die gebruikersdata zo veilig mogelijk opslaat en verwerkt. Het maakt gebruik van hashing en salting om wachtwoorden te beveiligen, waardoor ze moeilijker te kraken zijn. Dit is essentieel voor gebruikers veiligheid.
• Express-session: Express-session voegt sessie-functionaliteit toe in de vorm van cookies. Het maakt inloggen mogelijk door een gebruikerssessie aan te maken, en biedt de mogelijkheid om deze te manipuleren en te verwijderen. Express-session is nodig om een veilige gebruikers omgeving te maken.
• Dotenv: Dotenv biedt de mogelijkheid om projectvariabelen in een apart bestand (.env) op te slaan. Dit verbetert de veiligheid door gevoelige informatie, zoals database variabelen, buiten de source code te houden. Het wordt beschouwd als een best practice voor het beheren van configuratiegegevens.

Deze week hebben we gewerkt aan het opzetten van een database in MongoDB en deze te verbinden met ons project. Hieronder volgen de stappen die we hebben genomen:

1. Database-configuratie:
   • We hebben een database aangemaakt via MongoDB en deze via een IP gedeeld zodat onze machines kunnen verbinden via het project.
   • We hebben onze databasevariabelen opgeslagen in ons .env bestand om de veiligheid te verbeteren en om de best practices te volgen.
2. Onderzoek naar CRUD-functionaliteiten:
   • Tegelijkertijd hebben we onderzoek gedaan naar de verschillende CRUD-functionaliteiten die we nodig hebben voor ons project.
   • Na het bekijken en maken van oefeningen over Mongoose hebben we besloten om Mongoose boven MongoDB te kiezen voor onze database interacties.
   • De keuze voor Mongoose werd gemaakt op basis van de robuustere CRUD-functionaliteiten die het biedt, en de ervaring die ik eerder in de week heb opgedaan met oefeningen over Mongoose.
3. Opzetten van database model:
   • Later in de week hebben we een opzet gemaakt voor ons database model.
   • De gebruikers schema bevat alle velden voor een gebruiker zoals de gebruikersnaam, email en wachtwoord.
   • Het is belangrijk om elk veld correct in te stellen. Bijvoorbeeld om het email veld uniek te maken. En een maximale hoeveelheid characters te definieren voor een beschrijving.
   • Het voordeel van MongoDB is dat we onze schema's gemakkelijk kunnen aanpassen in ons project zonder de database helemaal opnieuw te moeten maken, zoals bij SQL-databases.
4. Toevoegen van CRUD-functionaliteiten:
   • Uiteindelijk is het gelukt om simpele CRUD-functionaliteiten toe te voegen aan het project.
   • Alle CRUD functies staan opgeslagen in de controller file.
   • We hebben hiervoor simpele formulieren gemaakt, die later in het project zullen worden vervangen door de definitieve ontwerpen die zijn gemaakt door de frontenders.

.env bestand

Gedeelte van de user model

Database connectie

1. Is er feedback naar mijn werkhouding en of naar mij in het algemeen?

1. Zijn de schema namen duidelijk aangegeven?

• CRUD Guide
• ESLint Docs
• Mongoose Docs
• Bcrypt
• Express-Session
• Dotenv
• MongoDB

Deze week heb ik onderzoek gedaan naar de Multer package. Multer biedt de mogelijkheid om media te verwerken en op te slaan tijdens POST requests. Voor de scope van het huidige project voorziet Multer voor alle functionaliteiten die we nodig hebben. Echter bied Multer in de toekomst ook de flexibiliteit om te worden gecombineerd met packages die file storage op externe databases mogelijk maakt.

Multer is een veelgebruikte package in Node project voor het verwerken van bestanden, zoals afbeeldingen en video's, die worden geüpload via formulieren op webpagina's. Het stelt ons in staat om deze bestanden te ontvangen, te verwerken en op te slaan op onze server. De beste manier om data op te slaan voor het scope van dit project is om de bestanden zelf op een aparte folder in ons project op te slaan, en om de titel van dat bestand op te slaan in onze MongoDB database.

Het is ook mogelijk om Multer bestanden direct op te slaan in de tekst database door het bestand de encoden naar base-64. Het voordeel hiervan is dat alle data op een plek staat opgeslagen. Het nadeel is dat dit de maximum bestandsgrote limiteert to 10mb. Het is echter wel mogelijk om het bestand dan te splitten in verschillende stukjes. Ik heb geexperimenteerd met deze mogelijkheden maar het is mij uiteindelijk niet gelukt, en voor de scope van het project is de standaard manier van Multer het beste.

Deze week heb ik ook onderzoek gedaan naar het extern hosten van ons Node project en die vervolgens te koppelen aan een eigen domein. Ik heb verschillende websites gevonden die hostingopties bieden, zoals Vercel, Render en Cyclic. Het is me gelukt om ons project via Render te laten werken op mijn eigen domein.

Echter, al snel stuitte ik op een probleem. Aangezien we al onze Multer media opslaan in ons project zelf, is het voor Render niet mogelijk om foto's en media op te slaan zonder eigen opslag te hebben. Render biedt wel een persistent storage drive aan, maar deze begint bij 7 euro voor 250 GB, wat buiten de scope van dit project valt.

In de komende weken wil ik verder onderzoek doen naar hosting van Node projecten.

Deze week hebben we gewerkt aan de integratie van Multer in ons project. Hier volgt een overzicht van de stappen die we hebben genomen:

1. Aanmaken van een middleware voor bestandsuploads:
   • We hebben een middleware aangemaakt die een specifieke map in de /public/uploads directory gebruikt als opslag voor alle geüploade media.
2. Aanpassingen aan het gebruikersschema/model:
   • We hebben aanpassingen gemaakt aan ons gebruikersschema/model om de bestandsnaam van geüploade media op te slaan, zodat deze kunnen worden gekoppeld aan de bijbehorende gebruikers.
3. Aanpassingen aan de formulieren:
   • De frontenders hebben de formulieren aangepast om multipart/form-data toe te staan, wat nodig is voor het uploaden van bestanden.
   • Dit zorgt ervoor dat de verzonden data in de backend wordt verdeeld over twee variabelen: req.body voor alle string data en req.files voor alle geüploade bestanden.
4. Aanpassingen aan de CRUD-functionaliteit:
   • We hebben de CRUD-code aangepast om de geüploade media te kunnen verwerken.
   • Door de POST aan te passen met een upload single of upload any functie kan Multer het bestand opslaan.
   • Multer geeft het bestand ook een nieuwe naam om de vervolgens op te slaan in de database.

Aan het einde van de week zijn we erin geslaagd om media succesvol op te slaan en weer te geven in onze applicatie.

Multer middleware

Aanpassingen in user schema/model

Nieuwe create user function

1. Geen

1. Geen

• Multer

Deze week heb ik mij gericht op het experimenteren met websitehosting. Ik heb verschillende platforms onderzocht, maar uiteindelijk ben ik beland bij het gebruik van een VPS (Virtual Private Server). Een VPS biedt de mogelijkheid om vrijwel alles te doen op een eigen serveromgeving.

Ik heb een kleine VPS gehuurd bij Hetzner met 4 GB RAM en 2 cores. De server wordt gehost in Duitsland en ik kan er via een SSH-key verbinding mee maken. De VPS draait op Ubuntu Terminal, wat even wennen is in vergelijking met GUI systemen zoals Windows of MacOS.

Om de VPS te testen heb ik een Node-project geïnstalleerd en alles werkt via localhost. Om de localhost op elke machine te kunnen bereiken moet je alleen het server IP plus de port invullen in de URL balk.

In de toekomst wil ik certificaten toevoegen en een domein koppelen aan de VPS. Op dit moment bereik ik de website met alleen HTTP. Wat van nature onveilig is. Het internet in het algemeen is niet gebouwd op security. Door in de toekomst een certificaat toe te voegen kan ik mijn website bereiken via HTTPS.

Deze week heb ik voornamelijk geholpen bij het correct programmeren van alle backend functionaliteiten. De frontenders zijn bezig geweest met alle views programmeren, en wij hebben gewerkt aan het aanmaken van routes voor die verschillende pagina's, waaronder de "foryou" pagina, instellingen, profiel, registratie en de inlog- en uitlogroutes.

1. Backend functionaliteiten:

   • Met de informatie van de frontenders heb ik nieuwe routes en controller functies aangemaakt voor de verschillende views.
   • De nieuwe controller aanpassingen zijn voornamelijk CRUD updates en bug fixes.

2. Sessions en login:

   • We hebben een login gemaakt waar een email word gechecked of het daadwerkelijk bestaat, vervolgens checkt het of de wachtwoorden overheen komen. Ten slotte word een nieuwe session cookie aangemaakt.
   • Route aanpassingen zijn gemaakt om verschillende pagina's alleen toegankelijk te maken wanneer een gebruiker is ingelogd.
   • Als die routes worden ingetyped in de browser zonder eerst in te loggen word de gebruiker naar de login pagina geredirect.

Gedeelte van de routes

Update gebruiker functie

Login functie

1. Geen

1. Geen

• Hetzner

Deze week heb ik weinig onderzoek gedaan naar nieuwe technologieën. In plaats daarvan heb ik me voornamelijk gericht op het ondersteunen van mijn teamleden en het schrijven van comments in de code. Door gedetailleerde comments toe te voegen, wordt de code beter te begrijpen en te onderhouden. Niet alleen voor de developer zelf, maar ook voor andere devs die de code proberen te snappen of aan te passen in de toekomst.

Deze week hebben we grote delen van de applicatie afgerond en als team besproken hoe we het project willen afsluiten. Hieronder volgt een overzicht van de belangrijkste stappen en aanpassingen die we hebben gedaan:

1. Overleg over projectafronding:
   • We hebben als team overlegd hoe we het project willen afronden en welke functionaliteiten we nog kunnen implementeren binnen de resterende tijd.
2. Email verificatie en wachtwoord reset:
   • Hoewel we niet voldoende tijd hebben om de functionaliteiten voor email verificatie en wachtwoord reset volledig in de applicatie in te bouwen, probeert Laurens deze functionaliteiten te testen en te integreren in een eigen branch.
3. Aanpassingen aan routing en controllers:
   • We hebben wijzigingen aangebracht in de routing en controllers met betrekking tot de verwerking van Multer bestanden.
   • Tijdens de eerdere implementatie van de backend voor Multer bestanden werd niet goed nagedacht over hoe gebruikers eenvoudig nieuwe bestanden kunnen toevoegen en verwijderen. Hierdoor heb ik deze week nieuwe routes en controller functies aangemaakt en geprogrammeerd.
   • Het bewerken van de profiel en het toevoegen en verwijderen van media is nu gesplitst.
4. Ondersteuning van frontenders:
   • Ik heb de frontenders geholpen met het correct programmeren van de verschillende formulieren in de applicatie.
   • Het is belangrijk dat alle formulier namen in de views koppen met de schema namen. Fouten hierin zijn vaak moeilijk te spotten maar zorgt er wel voor dat een hele applicatie kan crashen.

1. Geen

1. Geen

1. Geen

Deze week heb ik gewerkt aan het draaien van ons project op mijn VPS. Via GIT heb ik het project op mijn server gecloned en getest of alle gegevens correct worden opgeslagen en of de URL goed werkt en overal toegankelijk is.

Mijn doel is om tijdens het eindgesprek op maandag de website via mijn VPS te tonen. Ik wil echter na het inleveren nog in het weekend nakijken of er geen problemen optreden. Mocht er een probleem opduiken, dan heb ik als back-up plan om het project op mijn eigen laptop of de laptop van een teamgenoot te draaien. Hierbij moeten we ervoor zorgen dat alle mediabestanden overeenkomen met de bestandsnamen in de database.

Deze week heb ik mij voornamelijk gericht op het schrijven van de documentatie en het afronden van het project. Hieronder volgt een overzicht van de stappen die we hebben genomen:

1. Schrijven van de documentatie:
   • Ik heb mijn wiki afgemaakt en mijn competentieverslag geschreven.
   • De readme is afgemaakt met alle informatie over ons project en hoe je het moet installeren. Hierdoor kunnen leraren en andere gebruikers makkelijk het project op hun eigen machine installeren.
2. Samenwerking met teamleden:
   • Gedurende de week heb ik regelmatig samengewerkt met mijn teamleden om de laatste foutmeldingen te verhelpen. Veel van deze fouten waren het gevolg van verkeerde variabelnamen en andere kleine maar kritieke issues.
3. Mergen van code:
   • In de laatste dagen van de week zijn we bezig geweest met het mergen van onze code. Dit is altijd spannend of er merge conflicts komen en of de code nog goed werkt na de merge.
   • Uiteindelijk is het mergen gelukt. Niet zonder paar merge conflicts, maar geen extreme gevallen.
4. Bug testen:
   • Wij hebben na de merge nog bug testen uitgevoerd door alle functionaliteiten goed te testen en edge cases te voorkomen.
5. Laatste puntjes op de i:
   • We hebben nog code comments toegevoegd en ongebruikte code verwijderd.

1. Geen

1. Geen

1. Geen