RouteLogic is een SaaS-product die we binnen OrangeTalent sinds een paar jaar ontwikkelen. Eind vorig jaar zijn we begonnen met het herschrijven van verschillende onderdelen om het weer future-proof te maken. Ik neem je graag mee in hoe en wat we gebouwd hebben.
Eerst een beetje achtergrond. RouteLogic is een product om routes te creëren waarmee je zo efficiënt mogelijk voertuigen inzet om opdrachten te vervoeren. Je synchroniseert of voert de opdrachten in, selecteert jouw beschikbare voertuigen en het systeem berekent de meest efficiënte routes.
Waarom onderdelen herschrijven?
Eind vorig jaar kwamen we tot de conclusie dat de functionaliteiten die we wilden inbouwen niet meer ‘haalbaar’ waren in het huidige systeem. Eén van die functionaliteiten is het onboarding proces waarbij gebruikers gratis een route kunnen maken om RouteLogic te testen.
Met het team hebben we besloten om delen van het systeem te herschrijven. Er zijn verschillende redenen voor deze beslissing:
-
Er is een nieuw systeem gekomen om efficiënte routes te berekenen. We hebben het systeem in eigen beheer genomen. Daarmee zijn de berekeningen vele malen sneller geworden, maar het inbouwen vereiste veel wijzigingen in een legacy codebase.
-
Er is een nieuw onboarding proces bedacht. Daarvoor moest zoveel data aan elkaar gekoppeld worden, dat een front-end framework dat makkelijker en overzichtelijker maakt.
-
De codebase bevatte veel onderdelen die geen unit (of feature) tests bevatte. Aangezien de codebase steeds grotere vormen begon aan te nemen, werd de kans op fouten ook groter.
-
En er was nog genoeg verbetering mogelijk in de gebruikerservaring. Vooral voor het maken van de routes.
Het herschrijven van de back-end
De eerste stap was het opschonen van de Laravel back-end. De back-end was een monolith, waar de views en applicatie logica in een project zaten. We zijn begonnen om dat los te trekken en te herbouwen naar een API gedreven oplossing. Waarbij de back-end in de nieuwe situatie een statische front-end applicatie kan voorzien van data.
Een voordeel van de splitsing is dat we de API ook kunnen gebruiken voor andere applicaties. Zo zijn we bezig met het ontwikkelen van een native applicatie met React Native die ook gebruik maakt van deze API’s.
Na het strippen van de back-end, hebben we bepaalde onderdelen herschreven en zijn we begonnen om de applicatie logica te testen. We maken gebruiken van Laravels ingebouwde testing framework (PHPUnit) om unit- en feature tests te schrijven voor essentiële onderdelen van RouteLogic.
Naast het opschonen zijn er ook een aantal nieuwe features gebouwd. Zo is het abonnement systeem op de schop gegaan en is het nieuwe route systeem (RouteLogic Engine) geïntegreerd in de applicatie.
Volgende stap, de front-end
Terwijl de back-end vernieuwd werd, is begonnen met het herschrijven van de front-end. De front-end was gebouwd met Laravel Blade templates en een combinatie van vanilla JavaScript (met een vleugje jQuery). We zijn volledig opnieuw begonnen met opbouwen.
We hebben de nieuwe front-end gebouwd met React. De keuze voor React is dat we het binnen OrangeTalent (en RouteLogic) vaker gebruiken en omdat React in te zetten is voor meerdere doeleinden. Zoals React Native waar we momenteel de native chauffeurs app in ontwikkelen. Zo houden we alles consistent.
Een essentieel onderdeel van de React applicatie, is state management. Als je bekend bent binnen het React ecosysteem, dan zul je mogelijk bekend zijn met Redux, Mobx, of een van de andere 100’en mogelijkheden.
Wij kozen voor een (nog) minder bekende state management oplossing, Recoil. Recoil is onderdeel van Facebook, dezelfde ontwikkelaars als React. Dat maakt dat Recoil een goede integratie biedt met React en de nieuwste functionaliteiten snel implementeert. Daarnaast is Recoil relatief simpel.
Voor de stijl gebruiken we Tailwind. Tailwind is binnen OrangeTalent nog niet zolang in gebruik, maar de eerste ervaringen zijn heel positief. Het werkt snel en als je het bewust inzet is het overzichtelijk. Met bewust bedoel ik dat je herhalende onderdelen opsplitst in componenten en vaak voorkomende CSS verplaatst naar een centrale stylesheet (gebruik makend van Tailwinds @apply).
Daarmee hebben we de belangrijkste onderdelen van de applicatie wel gehad. Natuurlijk maken we gebruik van nog een aantal andere plug-ins voor bijvoorbeeld formulieren, kaarten en datepickers.
Het doel is wel altijd de lijst met dependencies zo klein mogelijk te houden. Elke dependency die we gebruiken moet ons een hoop code besparen en er moet geen native oplossing voor zijn. Elke dependency die je toevoegt vereist onderhoud in de toekomst, hoe minder, hoe makkelijker.
Alles klaar om live te gaan
In onze Git omgeving (Gitlab) hebben we voor elk onderdeel van RouteLogic aparte repositories. Voor elke repository hebben CI/CD pipelines die onze code controleert en uiteindelijk live zet.
CI/CD pipelines geven ons snel feedback op onderdelen die onverwacht niet werken, maar ook op code stijl die niet voldoet aan onze richtlijnen. Deze korte feedback loop zorgt ervoor dat we heel regelmatig code live kunnen zetten.
We hebben een staging omgeving waar wijzigingen altijd doorheen gaan en we de hele applicatie kunnen testen voordat het live gaat naar productie.
Een overzicht van RouteLogic
Ik hoop dat we je een goed beeld hebben gegeven van het project waar we de afgelopen maanden aan gewerkt hebben. En we de komende jaren aan door ontwikkelen. Ben je benieuwd hoe alles er nu uitziet, dan kun je op routelogic.io gratis beginnen met een route.
Mocht je als developer geïnteresseerd zijn geraakt in de technieken en willen helpen met de toekomst van RouteLogic. Wij zijn op zoek naar front- en back-end developers.
