VX Company & Micro-frontends: werken met NX tijdens de kennisdag. 

Value Proposition Canvas x Software Development

Het Value Proposition Canvas, ontworpen door Alexander Osterwalder, is een klantenanalyse-tool waarbij de ontwikkeling van diensten en producten onder de loep gelegd wordt. Door op een systematische manier in kaart te brengen waar de klanten behoefte aan hebben en wat hun in de weg staat wordt het gemakkelijker om een aansluitend product- en dienstenaanbod te creëren. Je geeft met dit canvas de waardepropositie weer van de klant.

Het vraagstuk van de ‘celebrities’ is aan het begin van de dag nog onduidelijk. Maar na de interviewvragen is het al een stuk opgehelderd. Het canvas helpt de developers duidelijk overzicht krijgen van het probleem dat de celebrities hebben. Als eerst vul je de ‘customer profile’ kant in. Er komt dan een overzicht van positieve punten, pijnpunten, behoeftes en oplossingen in het model tevoorschijn. Met deze informatie kan de eerste hand gelegd worden aan een passende development oplossing. Die komen aan de ‘Value Map’ kant. Je beschrijft oplossingen voor de pijnpunten en de behoeftes. De behoeftes worden nu in mogelijke oplossingsgerichte producten of diensten gegoten.  

Omdat we belang zien van het ontwikkelen van waarde in onze development opdrachten staat deze opdracht in het teken van Value Proposition Design. Dit model leert je eerst nadenken over de oorzaak en het gevolg, voordat je je development brein echt aan het werk zet. Wat levert je dit op? Een veel beter inzicht in het probleem dat je probeert op te lossen en een effectievere weg naar de oplossing.

Wat zijn Micro-Frontends?

In deze blog laten we je kennis maken met Micro-Frontends. Een van de onderwerpen dat meegenomen is in de afgelopen kennisdag. Dus wat zijn Micro-Frontends nou precies? 

Iedere nieuwe website begint klein. Meestal, naarmate tijd verstrijkt, komen er steeds meer functionaliteiten in een site. Een logisch gevolg is dat er meer code te onderhouden is, en dat betekent een grotere ontwikkelafdeling. Hoe meer ontwikkelaars samenwerken in één code-base, hoe ingewikkelder het wordt. Dan moet er afgestemd worden wie, wanneer, welke nieuwe functionaliteit uitrolt. Bovendien betekent meer code een langere build-tijd. Op een gegeven moment gaat dat niet meer.

En zo ontstaat al snel de wens zo’n project als het ware “uit elkaar te trekken”. Ieder team onderhoudt dan een bepaald gedeelte van de totaaloplossing. Van de verschillende functionaliteiten die de teams produceren kun je vervolgens een compositie maken. Dat wordt dan één website. De eindgebruiker merkt er dus niks van. Dat is simpel gezegd de essentie van een micro-front-end architectuur.

In de moderne front-end wereld van vandaag is dat helaas makkelijker gezegd dan gedaan. Al snel beland je in een welbefaamde versie-hel. Stel dat je Angular gebruikt als front-end framework, het ene team bouwt in Angular 13, en het andere team in Angular 14, dat gaat voor problemen zorgen als dat bij elkaar komt op dezelfde website. Je hebt dus iets nodig om te zorgen dat zulke situaties niet kunnen ontstaan. Dat, en nog veel meer, kun je tackelen door een monorepo te gebruiken. Zonder tooling is het beheer van een monorepo ingewikkeld. Daarom is het verstandig gebruik te maken van tooling. Google heeft zo’n tool ontwikkeld: Nx. Dit is een monorepo-beheer-tool.

Een greep uit de functionaliteiten van Nx:

• Met Nx kun je de versies van dependencies van alle apps beheren,
• Je kunt er complete React, Angular, web-components projecten mee genereren,
• Je kunt de code genereren die je nodig hebt om runtime, in de browser apps in te laden,
• Als nieuwe code gebouwd wordt, worden de laatste build-resultaten van ongewijzigde code opgehaald uit de Nx-Cloud. Dat zorgt ervoor dat je veel sneller kunt bouwen.
  
  

Door Nx te gebruiken kun je individueel deployable apps bouwen. Dat betekent dat ieder team zo, zonder andere teams tot last te zijn, nieuwe business-waarde naar productie kan brengen. 
 
Houd wel in gedachte: de Nx filosofie is dat je continu, de hele monorepo geautomatiseerd test. En dat soort gedachtegoed sluit naadloos aan op GitHub actions. Daarmee kunnen bij iedere pull-request de tests gedraaid worden, de app gebouwd worden, en de resultaten in een Docker container plaatsen. Die kun je vervolgens in Kubernetes draaien.