Technische analyse

Hoe kan de nieuwe module naadloos geïntegreerd worden met het bestaande Veloyd-systeem?

Doel

Integratie met bestaande functionaliteiten: De nieuwe module moet naadloos geïntegreerd worden met het bestaande Veloyd-systeem, in combinatie met de vier verschillende omgevingen (Admin, Reseller, Customers, Messengers). Het technische ontwerpen van deze integratie en het zorgen voor een vloeiende workflow tussen modules is een uitdaging.

Veloyd Structuur

Veloyd is gebaseerd op ritten die door klanten worden aangemaakt, waarbij elke rit een specifiek adres heeft waar de koerier naartoe moet. Voor afhaalpunten kan de situatie verschillen: een rit kan direct naar een afhaalpunt gaan, of het kan zijn dat de rit eerst een bezorgpoging op het adres heeft en daarna naar het afhaalpunt toe moet. Het afhaalpunt is dus een toevoeging aan de rit, geen volledige vervanging van het oorspronkelijke adres.

Welke technische vereisten zijn er voor de integratie?

De meest prominente en belangrijkste technologieën waar Veloyd mee werkt:

• React
  • v16
  • class components
• NodeJS
  • v16
• Express
• SocketIO
• MongoDB

De implementatie van de afhaalpunten module zou binnen de grenzen van deze technologieën moeten liggen.

Data structuur

Veloyd gebruikt MongoDB als database, MongoDB is een niet-relationele database¹. Dit is belangrijk om rekening mee te houden bij het opzetten van de datastructuur van de afhaalpunten.

Bij een relationele database heb je verschillende tabellen die samen een entiteit voorstellen, bijvoorbeeld:

Afhaalpunten tabel

id	naam	adres_id
0	Jumbo	0
1	Bruna	1

Adressen tabel

id	straat	huisnr	postcode	stad	land
0	Westboschlaan	107	2265 GB	Leidschendam	NL
1	Blaauwhoflaan	113	8501 EK	Joure	NL

In dit geval heeft een afhaalpunt een uniek identificatienummer(id), een naam en een uniek adresnummer. Het is niet handig om het adres als één tekstveld in de afhaalpunttabel te zetten. Als je in je applicatie alleen de postcode en huisnummer wilt laten zien, zou je die eerst moeten ontleden van deze tekst. Het is beter om al deze eigenschappen in losse velden te hebben staan. Omdat een tabel tweedimensionaal is, kunnen we niet deze losse adres velden in de afhaalpunttabel zetten. Daarom moeten we een nieuwe tabel aanmaken die alle gebruikte adressen bevat. In de afhaalpuntentabel kan dan verwezen worden naar het identificatienummer van een adres om in de applicatie toch het adres met de losse velden op te kunnen vragen.

Veloyd gebruikt dus niet bovenstaande structuur, ze gebruiken MongoDB. MongoDB maakt gebruik van een documentgebaseerd model. Hierbij worden gegevens opgeslagen in documenten. Stel je een document voor als een digitale enveloppe waarin je allerlei soorten informatie kunt stoppen. Het mooie is dat elk document zijn eigen structuur kan hebben, net als een persoonlijke notitie die je in een enveloppe steekt.

Bijvoorbeeld, in een traditionele database zou je een vaste tabel hebben voor klantgegevens, waar elke klant dezelfde informatie in dezelfde kolommen heeft. Maar met MongoDB, kun je de gegevens van verschillende klanten in aparte documenten stoppen, waarbij elk document de specifieke informatie van die klant bevat. Dit maakt MongoDB heel flexibel en handig voor situaties waar de gegevens niet allemaal hetzelfde zijn.

Dit geeft MongoDB een grote mate van flexibiliteit bij het opslaan van gegevens. Het is bijvoorbeeld uitermate geschikt voor situaties waarin de structuur van de gegevens kan variëren.

Als je bovenstaande tabellen wilt vertalen naar deze documenten structuur, krijg je zoiets:

Afhaalpunt document

{
  "_id": 0,
  "naam": "Jumbo",
  "adres": {
    "straat": "Westboschlaan",
    "huisnr": 107,
    "postcode": "2265 GB",
    "stad": "Leidschendam",
    "land": "NL"
  }
}

Hier zie je dat je ook meteen het adres samen met het afhaalpunt kan opslaan. Dus heb je niet een aparte tabel(=collectie in MongoDB) nodig.

notitie

Een paar dependencies[^2] nemen ruimte in dat niet wordt gebruikt, deze zijn:

• quagga
• chartjs-adapter-date-fns
• telnet-client

Advies voor Veloyd is om deze dependencies te verwijderen uit de codebase[^3] om zo de bundle size[^4] van het project te verlagen.

Advies

Binnen de context van de implementatie van deze nieuwe module, zijn volgende punten relevante adviezen:

1. Flexibele datastructuur voor toekomstige uitbreidingen

Gezien de basis van Veloyd, waarin ritten en afhaalpunten variabele structuren hebben, wordt geadviseerd de flexibele MongoDB-documentstructuur te behouden. Dit biedt niet alleen de mogelijkheid om huidige eisen te ondersteunen, maar maakt ook gemakkelijke uitbreiding mogelijk voor toekomstige functionaliteiten.

2. Optimalisatie van de codebase

Het voorgestelde advies om ongebruikte dependencies te verwijderen is relevant. Een slanke codebase draagt niet alleen bij aan een efficiëntere bundelgrootte maar verbetert ook de algemene onderhoudbaarheid en prestaties van het Veloyd-systeem.

3. Uitgebreide documentatie en code annotations

Gedetailleerde annotaties in de code kunnen samenwerking vergemakkelijken en toekomstige ontwikkelaars helpen bij het begrijpen van het systeem in het geheel en de afhaalpunten implementatie. Er komt steeds meer functionaliteit in Veloyd, daarom ook het advies om documentatie op te stellen voor toekomstige collega's of 3e partijen.

4. Implementatie van unit tests

Om de robuustheid van de integratie te waarborgen, is het aan te bevelen om unit tests te implementeren. Dit zal helpen bij het vroegtijdig identificeren van potentiële bugs en zorgt voor een meer betrouwbare en stabiele module.

Door deze adviezen te integreren in het implementatieproces, kan de nieuwe module niet alleen voldoen aan de bestaande eisen maar ook voorbereid zijn op toekomstige uitbreidingen en wijzigingen binnen het Veloyd-systeem.

Conclusie

De integratie van de nieuwe module binnen het Veloyd-systeem is cruciaal voor het verbeteren van de functionaliteit, waarbij speciale aandacht wordt besteed aan de diversiteit in rit-structuren. Gezien de complexiteit van afhaalpunten, die als aanvulling op ritten fungeren, is het noodzakelijk om de datastructuur zorgvuldig te ontwerpen. De technische vereisten, met de nadruk op React, NodeJS, Express, SocketIO en MongoDB, dienen als leidraad voor een succesvolle implementatie.

Het gebruik van MongoDB als niet-relationele database biedt flexibiliteit in gegevensopslag, vooral in situaties waarin de structuur van gegevens kan variëren. De voorgestelde documentstructuur voor afhaalpunten in MongoDB illustreert deze flexibiliteit en benadrukt de efficiëntie van het systeem.

Als aanvulling op de technische aspecten wordt benadrukt het belang van de volgende adviezen:

1. Flexibele Datastructuur voor Toekomstige Uitbreidingen: Het behoud van de flexibele MongoDB-documentstructuur biedt niet alleen ondersteuning voor huidige eisen maar maakt ook gemakkelijke uitbreiding mogelijk voor toekomstige functionaliteiten.

2. Optimalisatie van de Codebase: Het verwijderen van ongebruikte dependencies draagt bij aan een efficiëntere bundelgrootte en verbetert de onderhoudbaarheid en prestaties van het Veloyd-systeem.

3. Uitgebreide Documentatie en Code Annotations: Gedetailleerde annotaties in de code vergemakkelijken samenwerking en helpen toekomstige ontwikkelaars het systeem beter te begrijpen.

4. Implementatie van Unit Tests: Het aanbevelen van unit tests draagt bij aan de robuustheid van de integratie door potentiële bugs vroegtijdig te identificeren, wat resulteert in een betrouwbare en stabiele module.

Door deze adviezen te integreren in het implementatieproces, zal de nieuwe module niet alleen voldoen aan de bestaande eisen maar ook voorbereid zijn op toekomstige uitbreidingen en wijzigingen binnen het Veloyd-systeem.

Footnotes

1. Relationele databases gebruiken rijen en kolommen om data op te slaan, net zoals men gewend is van Excel sheets. Niet-relationele databases gebruiken een model dat is geoptimaliseerd voor de vereisten van het type data dat wordt opgeslagen (Martinekuan, z.d.). ↩