De frontend van Profit Next


pijl schuin blauw naar transparant
De frontend van Profit Next heeft net als de backend te maken met een aantal uiteenlopende uitdagingen. In de eerste plaats hebben we te maken met een webapplicatie met duizenden verschillende pagina’s. Daarnaast willen we de gebruiker de best mogelijke user experience (UX) bieden op elk device. Tenslotte willen we ook een flexibele en toekomstvaste architectuur, zodat we nieuwe features kunnen blijven toevoegen en ook nieuwe inzichten en technologieën kunnen toepassen.

Hoe wij deze uitdagingen hebben opgelost in onze architectuur zullen we in de rest van dit stuk toelichten. Met deze opzet hebben we bereikt dat verantwoordelijkheden goed verdeeld zijn. Hierdoor kunnen we nieuwe technologie en nieuwe inzichten toepassen zonder dat de hele codebase aangepast hoeft te worden. Daarnaast kunnen we elk stuk code goed testen, waardoor we minder snel fouten maken.

Deployment

Om de architectuur te begrijpen kunnen we het beste beginnen met de deployment. Wij hebben gekozen voor een single-page applicatie architectuur waarbij alleen de browser met de backend communiceert. De deployment van de applicatie is het beste te begrijpen door te kijken naar hoe de applicatie opstart. Dit gebeurt in de volgende stappen.

  1. De browser benadert een url van de applicatie. Hij ontvangt een html-pagina die dynamisch opgebouwd is met configuratie informatie over waar de applicatie gedeployed is en welke versie actief is.
  2. De browser download vervolgens de javascript en stylesheet bundels die in de html-pagina opgegeven zijn. Deze bestanden zijn als statische bestanden opgeslagen op de server.
  3. Aan de hand van de huidige url wordt daarna het bijbehorende pagina-bestand gedownload. Dit is een bestand wat gegenereerd is aan de hand van het applicatie-model.
  4. De pagina download tenslotte de benodigde gegevens via de REST API van de backend.

De deployment van de frontend is dus eenvoudig en bestaat slechts uit de volgende functionaliteit:

  1. De html-pagina samenstellen aan de hand van de huidige deployment gegevens
  2. De statische javascript, stylesheets, plaatjes, fonts en dergelijke aanbieden
  3. De statische gegenereerde pagina’s aanbieden

De frontend zorgt er overigens wel steeds voor dat autorisatie-regels worden toegepast.

Blueprint

Zoals we al genoemd hebben bestaat Profit Next uit duizenden verschillende schermen. Elk scherm willen we op maat maken voor het device wat de gebruiker gebruikt, desktop, tablet of mobiel. Daarom hebben we ervoor gekozen om een abstractie-laag te introduceren, de blueprint. De blueprint beschrijft op een abstracte manier wat de structuur van de pagina is. Deze blueprint wordt vervolgens ingelezen door een composer. Deze composer vertaalt de blueprint naar de beste userinterface componenten voor het huidige device. Om een voorbeeld te geven: Een pagina met twee secties wordt op de desktop vertaald naar een tab-view met daarin twee tabs. Op een mobiel wordt dit vertaald naar een accordeon. 

Userinterface componenten

Om de userinterface zo flexibel mogelijk op te zetten maken we gebruik van herbruikbare userinterface componenten. Een component is een zelfstandig stukje userinterface wat helemaal los ontwikkeld en getest kan worden. Een component bevat zowel styling als javascript. We gebruiken hiervoor geen Polymer, AngularJS of React, maar we hebben onze eigen open source virtual DOM library gebouwd, maquette. Maquette is vele malen eenvoudiger dan de hiervoor genoemde frameworks. De code is gewoon javascript, zonder verdere toevoegingen. Daarnaast zijn animaties eenvoudig toe te voegen, zonder dat deze de werking van de applicatie beïnvloeden.

Componenten worden via dependency-injection geconfigureerd met callbacks om data mee op te halen en om een gebruikers-handelingen mee door te geven. Componenten kunnen vrijwel geheel ge-unit-test worden in NodeJS zonder een browser, wat testen erg snel en betrouwbaar maakt.

Model

Binnen de schermen van de Profit Next applicatie zijn veel bedrijfsregels van toepassing. De berekende waarde van een veld, of een veld zichtbaar is of niet, of een veld valide is, enzovoorts, kan allemaal afhangen van de waardes die de gebruiker invoert en van de instellingen op de server. Om ervoor te zorgen dat de juiste herberekeningen op het juiste moment uitgevoerd worden hebben we een afleidingsmechanisme gebouwd wat op basis van deze regels en de data automatisch de juiste berekeningen uitvoert, of deze uit laat voeren op de server. Dankzij de code-generatie hebben we geen problemen om de berekeningen op de server en in de browser gelijk te houden.

Technieken

Omdat we pas vanaf 2019 live gaan, zijn we continu bezig met de laatste web-technieken. De hele userinterface is bijvoorbeeld opgebouwd met flexbox en we schrijven code in Typescript. We gebruiken hierbij de nieuwste ECMAScript constructies.