Leestijd 9 min

Laurens Slechten

Bij het bouwen van producten wordt steeds meer erkend dat succes niet alleen te maken heeft met het leveren van functies of het halen van deadlines. In plaats daarvan gaat het om het leveren van echte waarde aan klanten en het bereiken van zakelijke impact. Dit vereist een mentaliteitsverandering van outputgericht naar resultaatgericht denken. In dit artikel onderzoeken we waarom het belangrijker is om uitkomsten prioriteit te geven dan output om succesvolle producten te maken en hoe je deze benadering kunt toepassen in je eigen werk. Wat betekent "uitkomsten boven output"? In de bedrijfswereld worden de termen resultaat en output vaak door elkaar gebruikt, wat voor enige verwarring zorgt. Het is echter belangrijk om het onderscheid tussen deze twee termen goed te begrijpen. Hoewel ze misschien eenvoudig lijken, laten we ze toch eens definiëren om ervoor te zorgen dat we allemaal op dezelfde golflengte zitten. Laten we ons eens voorstellen dat je je de laatste tijd uitgeput voelt, dus begin je te trainen in de sportschool om je energieker te voelen. Sommige mensen zouden kunnen zeggen dat het resultaat van je fitnessroutine het aantal uren dat je hebt gesport en de hoeveelheid gewicht die je hebt getild is. Maar het echte resultaat van je routine is veel belangrijker dan dat . Het resultaat is dat je je sterker, zelfverzekerder en gezonder voelt. Het resultaat is de manier waarop je harde werk (de output) zich heeft vertaald in een betere levenskwaliteit en een positiever zelfbeeld. Het resultaat is de manier waarop je probleem werd opgelost door de output. In een zakelijke context verwijst een resultaat naar de impact die je product heeft op de organisatie en haar klanten en belanghebbenden, terwijl een output verwijst naar de tastbare dingen die je (ontwikkel)team produceert, zoals documenten, software en tests. Focussen op resultaat boven output betekent succes definiëren op basis van het bereiken van een specifiek resultaat en vooruitgang meten op basis van hoe dicht je bij het bereiken van dat resultaat bent. Het doel van je team is niet om output te produceren; het is om een specifiek resultaat te bereiken. Een succesvol team streeft ernaar het gewenste resultaat te maximaliseren en tegelijkertijd de hoeveelheid geproduceerd werk te minimaliseren. De voordelen van een resultaatgerichte aanpak 1. Het helpt je te ontsnappen aan de bouwval Het eerste Agile Principe stelt dat je topprioriteit is om je klanten gelukkig te maken door waardevolle software zo vroeg en consistent mogelijk op te leveren. Naarmate agile werkwijzen op verschillende gebieden worden toegepast, hebben mensen dit principe geherformuleerd om het belang van het snel en consistent leveren van waarde aan klanten te benadrukken. Als je succes meet op basis van een resultaatgerichte metriek, zoals " het aantal doorkliks op nieuwsbrieven binnen zes maanden met 15% verhogen ", koppel je de inspanningen van je team onmiddellijk aan de waarde voor je organisatie en klanten. Dit helpt je te begrijpen welke impact je maakt en wanneer je echt een verschil maakt. Als je daarentegen succes meet door alleen te kijken naar de dingen die je produceert, zoals " het aantal opgeleverde features " of " het aantal voltooide punten in een scrum sprint ", loop je het risico in wat Melissa Perri (product management expert, spreker en auteur) "de bouwval" noemt. Deze valkuil houdt in dat je je alleen richt op het maken van features zonder rekening te houden met de gewenste resultaten. Wanneer organisaties prioriteit geven aan output boven uitkomsten, lopen ze het risico verstrikt te raken in een cyclus van het bouwen van meer en meer features zonder echt te begrijpen of ze klantproblemen oplossen of bedrijfswaarde creëren. Door je te fixeren op het opleveren van features als maatstaf voor succes, kun je het grotere geheel uit het oog verliezen. Het vertelt je niet of je de juiste dingen bouwt. Het is dus essentieel om je focus te verleggen naar de resultaten die er toe doen. Dit vereist een mentaliteitsverandering die de behoeften en gewenste resultaten van de klant op de voorgrond plaatst. Door succes te definiëren op basis van resultaten, kan je team ontsnappen aan de bouwval . 2. Het helpt je te focussen op leren en itereren Als je kritisch gaat denken over het leveren van waarde in plaats van features, loop je al snel tegen het probleem aan waar ik het eerder over had: hoe weet je zeker dat de features die je bouwt ook echt waarde gaan leveren? Een resultaatgerichte aanpak erkent dat je misschien niet vanaf het begin alle antwoorden hebt en dat leren een belangrijk onderdeel van het proces is. Daarom heb je bij het werken met uitkomsten een hulpmiddel nodig: het experiment. Wanneer je resultaatgericht denken combineert met een proces dat gebaseerd is op het uitvoeren van experimenten, begin je echt het ware potentieel van agile benaderingen te ontsluiten. Dit is vooral waardevol in situaties waar veel onzekerheid is. Als je bijvoorbeeld een nieuw softwareproduct maakt, weet je misschien niet zeker of het de gewenste impact zal hebben op je bedrijf en of alle mooie functies die je hebt bedacht wel nodig zijn. Door te focussen op resultaten, kun je doelen stellen die je team toelaten om te experimenteren en verschillende oplossingen uit te proberen tot ze vinden wat het beste werkt. In een agile context behandelen we elke stap als een hypothese en een experiment gericht op het bereiken van een specifiek resultaat. Dit is waar het concept van een MVP, of Minimum Viable Product , om de hoek komt kijken. Beschouw MVP als het kleinste ding dat je kunt doen of het kleinste ding dat je kunt bouwen om te leren of je hypothese juist is. Dit iteratieve proces van testen, leren en aanpassen stelt teams in staat om te experimenteren, om verschillende oplossingen uit te proberen, totdat ze de oplossing vinden die werkt. 3. Het helpt je team meer autonomie te bereiken Werknemers vinden het vaak een uitdaging om een diep gevoel van doelgerichtheid en motivatie te ervaren, enkel door de output die ze produceren. Wat mensen echt drijft om elke dag op het werk te verschijnen, zijn niet de specifieke taken waarmee ze zich elke dag bezighouden, maar eerder de betekenisvolle resultaten waar hun werk uiteindelijk aan zal bijdragen . De nadruk op resultaten helpt om je team op één lijn te krijgen rond een gemeenschappelijk doel en gedeelde doelen. Door duidelijkheid te verschaffen over wat er bereikt moet worden, kun je je team motiveren en in staat stellen om samen te werken aan duidelijke doelen die het product moet bereiken. Hierdoor kan je team prioriteiten stellen in hun werk en functies bouwen die bijdragen aan het bereiken van die doelen. Door hen beslissingen te laten nemen over de functies die ze bouwen, krijgen ze een groter gevoel van eigenaarschap over het werk dat ze doen. De resultaten voor je product definiëren en implementeren Nu ben je het er misschien wel mee eens dat focussen op resultaten klinkt als een goed idee, maar ze daadwerkelijk implementeren in onze bedrijfspraktijken is niet zo eenvoudig . Elke methodologie heeft zijn nadelen. Eén uitdaging is dat uitkomsten minder gemakkelijk te meten en te kwantificeren zijn dan outputs. Ten tweede staan veel bedrijven onder druk om snel door te gaan naar het volgende project als het ene is afgerond . Helaas wordt het iteratieve proces van testen, leren en aanpassen nog steeds niet vaak toegepast. Tot slot, wat het moeilijk maakt, is dat we vaak doelen stellen die te hoog gegrepen zijn . Als je het team bijvoorbeeld vraagt om het bedrijf winstgevender te maken of de risico's te verminderen, dan is dat te complex omdat die uitdagingen bestaan uit veel variabelen om te beïnvloeden. Deze doelen op impactniveau zijn te complex voor teams. In plaats daarvan moet je je richten op kleinere en beter beheersbare doelen . Om dit te doen, moet je je team vragen om zich te concentreren op het veranderen van klantgedrag op manieren die positieve bedrijfsresultaten opleveren. In zijn boek "Outcomes Over Output: Why Customer Behavior Is The Key Metric For Business Success" presenteert Joshua Seiden drie magische vragen die je kunnen helpen bij het identificeren van geschikte resultaten: Wat zijn de gedragingen van gebruikers en klanten die bedrijfsresultaten genereren? (Dit is het resultaat dat je probeert te creëren.) Hoe kunnen we mensen meer van dat gedrag laten vertonen? (Dit zijn de functies, beleidswijzigingen, etc. die je gaat doen om te proberen de resultaten te creëren). Hoe weten we of we gelijk hebben? (Dit onthult de experimenten en statistieken die je zult gebruiken om de voortgang te meten). Ik zal je een voorbeeld geven van hoe dit werkt. Stel je voor dat je een e-commerce kledingwinkel runt en je hebt te maken met zware concurrentie van een concurrerend bedrijf. Je doel is om de klantloyaliteit te verbeteren, dus stel je het team een breed doel om de frequentie van klantbezoeken te verhogen van één keer per maand naar twee keer per maand. Om dit effect te bereiken, moet u specifiek gedrag van klanten identificeren dat correleert met het bezoeken van uw site. U merkt bijvoorbeeld dat klanten de neiging hebben om de site te bezoeken na het openen van de maandelijkse nieuwsbrief waarin nieuwe artikelen worden gepresenteerd. Daarom zou een mogelijke uitkomst kunnen zijn om de doorklikratio van de nieuwsbrief te verhogen. Daarnaast merkt u dat klanten de site ook bezoeken nadat een vriend een afbeelding van een van de artikelen heeft gedeeld op sociale media. Een andere mogelijke uitkomst is dus om klanten aan te moedigen vaker afbeeldingen van artikelen te delen. Door je te richten op deze klantgedragingen die het gewenste resultaat van sitebezoeken bepalen, zorg je ervoor dat je doelen zowel observeerbaar als meetbaar zijn. Dit is cruciaal omdat je zo de voortgang effectief kunt beheren en bijhouden. Ik hoop dat dit voorbeeld duidelijk maakt hoe resultaten specifiek kunnen zijn en gemakkelijk kunnen worden uitgesplitst. Onthoud dat een resultaat een gedrag is dat klanten vertonen en dat direct van invloed is op de bedrijfsresultaten. Door dit gedrag te begrijpen, kunt u uw inspanningen afstemmen op de resultaten die echt belangrijk zijn voor uw bedrijf. Aanknopingspunten Een resultaat verwijst naar de impact die je product heeft op de organisatie en haar klanten en belanghebbenden, terwijl een output verwijst naar de tastbare dingen die je team produceert, zoals documenten, software en tests. Het doel van je team is niet om output te produceren; het is om een specifieke uitkomst te bereiken. Een succesvol team streeft ernaar om het gewenste resultaat te maximaliseren en tegelijkertijd de hoeveelheid geproduceerd werk te minimaliseren. Door je te fixeren op feature delivery als maatstaf voor succes, kun je het grotere geheel uit het oog verliezen. Het vertelt je niet of je de juiste dingen bouwt. Het is dus essentieel om je focus te verleggen naar de resultaten. Een resultaatgerichte aanpak erkent dat je misschien niet meteen alle antwoorden hebt en dat leren een belangrijk onderdeel is van het proces. Daarom heb je bij het werken met uitkomsten een hulpmiddel nodig: het experiment. Als je je werk plant, wees dan duidelijk over je aannames. Wees bereid om je veronderstellingen te testen door je werk uit te drukken als hypotheses. Test je hypotheses voortdurend door in kleine iteraties te werken, te experimenteren en te reageren op de gegevens en feedback die je verzamelt. Verwar impact - ambitieuze doelen op hoog niveau - niet met uitkomsten. Impact is belangrijk, maar deze doelen zijn te complex voor teams omdat ze bestaan uit veel variabelen om te beïnvloeden. Gebruik deze vragen om resultaten te definiëren: wat zijn de menselijke gedragingen die bedrijfsresultaten stimuleren? Hoe kunnen we mensen meer van deze dingen laten doen? Hoe weten we of we gelijk hebben? 👀 Meer weten over onze diensten ? Klik hier om meer te weten te komen!

Leestijd 6 min

Christophe Senesael

Mobiele ontwikkeling is tegenwoordig veel complexer en functioneler dan tien jaar geleden. Wat ooit begon als eenvoudige projecten met een paar functies zijn nu geëvolueerd tot geavanceerde systemen met alles van biometrische authenticatie en AI tot geavanceerde camera-integraties. Deze groei vereist een architectuurstrategie die de complexiteit effectief beheert met behoud van codebases van hoge kwaliteit. In dit artikel verkennen we een robuuste architecturale oplossing voor deze uitdaging: een modulaire of samenstelbare architectuur in mobiele ontwikkeling, geïnspireerd op de microservicearchitectuur die gangbaar is in backendontwikkeling. Wat is een modulaire architectuur? Net als bij microservices splitsen we een grote applicatie op in kleine, gerichte mobiele bibliotheken, die zich elk richten op een specifiek domein of een specifieke functionaliteit. Deze modulaire architectuur maakt het mogelijk om meerdere applicaties te bouwen met behulp van deze herbruikbare componenten, waarbij ervoor wordt gezorgd dat elke module losjes gekoppeld blijft. Dit maximaliseert de flexibiliteit, testbaarheid en aanpasbaarheid van elke component. Laten we eens dieper ingaan op de voordelen van een modulaire architectuur bij mobiele ontwikkeling. Waarom een modulaire architectuur gebruiken bij mobiele ontwikkeling? Separation of Concern afdwingen met een modulaire architectuur Het gebruik van een modulaire architectuur bij mobiele ontwikkeling zorgt voor een duidelijke scheiding van zorgen. Dit gaat verder dan de onderliggende code tot de organisatiestructuur van het project. Elke module functioneert als een op zichzelf staande eenheid, die een afzonderlijk verantwoordelijkheidsdomein vertegenwoordigt en afzonderlijk wordt ontwikkeld en onderhouden. Dit verbetert niet alleen de leesbaarheid en beheersbaarheid van het project, maar stroomlijnt ook de samenwerking en het debuggen. Bijgevolg creëert de ontwerpfilosofie van de modulaire architectuur een samenhangend systeem waarin de grenzen van de componenten onmiddellijk duidelijk zijn, zelfs zonder in de codebase te duiken. Modulaire architectuur bevordert herbruikbaarheid en onderhoudbaarheid van code Een modulaire architectuur verduidelijkt de projectstructuur en bevordert de herbruikbaarheid en onderhoudbaarheid van de code aanzienlijk. Door de app op te delen in modules creëren we herbruikbare componenten die kunnen worden geïntegreerd in verschillende delen van de applicatie of zelfs in geheel nieuwe projecten. Dit hergebruik van code minimaliseert overbodig werk, waardoor ontwikkelaars zich kunnen richten op innovatie in plaats van het wiel opnieuw uit te vinden voor elke nieuwe functie. Bovendien vereenvoudigt een modulaire architectuur het onderhoud en updaten van apps. Modules werken onafhankelijk van elkaar, waardoor verbeteringen of fixes op de ene module kunnen worden toegepast zonder andere modules onbedoeld te verstoren. Deze scheiding vereenvoudigt het testen en maakt gerichte validatie van wijzigingen mogelijk, wat zorgt voor een stabielere en betrouwbaardere applicatie. Het resultaat is dat de modulaire aanpak een codebase oplevert die niet alleen robuuster is, maar ook flexibeler, zodat de app zich snel kan aanpassen aan nieuwe vereisten of technologische vooruitgang. Modulaire architectuur verbetert testbaarheid Een van de grootste voordelen van een modulaire architectuur in grote mobiele ontwikkelingsprojecten is de verbeterde testbaarheid. In grote monolithische mobiele projecten kunnen bouwtijden aanzienlijk zijn, wat vaak resulteert in inefficiënte workflows. Stel je bijvoorbeeld voor dat je werkt aan een grote Xamarin-applicatie zonder hot reload-mogelijkheid. Als de UI zich misdraagt, moet je de hele applicatie bouwen en de hele flow doorlopen. En als deze flow afhankelijk is van web calls die worden onderhouden door een klantenteam, dan weet je dat je te maken hebt met een ongelooflijk tijdrovend en inefficiënt proces. Voordelen van modulaire architectuur bij mobiel testen Het gebruik van een modulaire architectuur voor je mobiele ontwikkelingsprojecten biedt een reeks belangrijke voordelen op het gebied van testen: Geïsoleerd testen Met een modulaire architectuur kun je alle gegevensafhankelijkheden van een module mocken en deze testen als een op zichzelf staande app. Deze isolatie maakt het mogelijk om gericht te testen op specifieke functionaliteiten zonder de overhead van het draaien van de hele applicatie. Kortere bouwtijden Het bouwen van de hele applicatie voor elke wijziging is niet nodig, waardoor de end-to-end testtijden aanzienlijk worden verkort. Deze efficiëntie leidt tot snellere ontwikkelcycli en snellere iteratie, cruciaal voor het behouden van een hoge productiviteit. Stabiele testomgeving Het ontkoppelen van modules minimaliseert het risico dat de ene component de andere beïnvloedt, wat zorgt voor betrouwbaardere tests en eenvoudiger opsporen van bugs. Parallel ontwikkelen en testen Teams kunnen verschillende modules gelijktijdig ontwikkelen en testen zonder te wachten tot een gedeelde codebase gestabiliseerd is, waardoor het ontwikkelproces versnelt en dynamische, flexibele workflows mogelijk worden. Een modulaire architectuur resulteert in een efficiënter, betrouwbaarder en schaalbaarder mobiel ontwikkelproces en beperkt de risico's van monolithische architecturen. Door te focussen op modulariteit verbeteren we zowel de ontwikkelings- als de testfase, wat leidt tot een betere algehele softwarekwaliteit. Modules definiëren bij mobiele ontwikkeling Bij het ontwikkelen van applicatiemodules is samenwerking met domeinexperts cruciaal om de verschillende functies binnen een organisatie volledig te begrijpen. Door deze samenwerking wordt duidelijk hoe de applicatie logisch kan worden gesegmenteerd. Het documenteren van rollen, gekoppeld aan domeinspecifieke vereisten, moet worden opgelost als een iteratief proces, waarbij voortdurende verfijningen mogelijk zijn die zijn afgestemd op de veranderende behoeften van de organisatie. De basismodule In onze modulaire architectuur gebruiken we een basismodule. Zie dit als de genetische code van de applicatie - de kern waarvan elke andere module erft. Deze basismodule bevat alle gedeelde, domeinagnostische functies, waaronder universele ontwerpelementen en besturingselementen. Het centraliseren van deze gemeenschappelijke aspecten zorgt voor een consistente look en feel in de hele app. Elke gespecialiseerde module die op deze basis is gebouwd, neemt inherent deze gedeelde kenmerken over, waardoor de ontwikkeling wordt gestroomlijnd en ervoor wordt gezorgd dat wijzigingen aan fundamentele aspecten slechts eenmaal hoeven te worden doorgevoerd, wat doorwerkt in de hele applicatie. Onze eerste module maken Zodra de basismodule klaar is, is de volgende stap het maken van de eerste samenstelbare module. De structuur bootst de klassieke gelaagde architectuur na (Data, Domain en Presentation projecten), met een extra Test project om het testen van de module te vergemakkelijken. Dit Test-project roept de module rechtstreeks aan. Het is een eenvoudige mobiele toepassing, meestal bestaande uit een knop om de component op te starten. De rol is om mock definities te bieden voor alle vereiste afhankelijkheden van de module, zodat deze kan worden ingezet op een apparaat of emulator om te testen. Projectstructuur voor modulaire architectuur Gegevensproject: Definieert gegevensentiteiten en vereiste gegevensinterfaces. Domeinproject: Bevat kernbedrijfslogica en domeinmodellen. Definieert use cases en bedrijfsregels die op de gegevens werken. Presentatie Project: Beheert UI-componenten en presentatielogica. Bevat views en UI-gerelateerde hulpprogramma's. Test Project: Standalone project dat rechtstreeks met de module interageert. Biedt schijnimplementaties voor afhankelijkheden. Maakt geïsoleerd testen van de functionaliteit van de module mogelijk. Gegevensafhankelijkheden definiëren in een modulaire architectuur Voor elke samenstelbare bibliotheek is het van cruciaal belang om gegevensafhankelijkheden te definiëren via contracten (bv. interfaces) in plaats van gegevensbronnen hard te coderen. Dit zorgt ervoor dat de bibliotheek agnostisch blijft wat betreft de herkomst van gegevens, of ze nu afkomstig zijn van een lokale database of een web-API. Dependency injection levert de juiste gegevensimplementaties aan de module. Met deze aanpak kunnen consumenten de gegevensbron kiezen. Door ervoor te zorgen dat de samenstelbare bibliotheek zich alleen bezighoudt met het type gegevens dat nodig is, in plaats van met de herkomst van de gegevens, wordt het mocken van gegevenscontracten en de emulatie van verwachte functionele scenario's vereenvoudigd. Deze modulaire en testbare aanpak verbetert de flexibiliteit en onderhoudbaarheid van de codebase aanzienlijk. Een module of component gebruiken in mobiele ontwikkeling Het integreren van een ontwikkelde module in je applicatie is eenvoudig dankzij duidelijk gedefinieerde interfaces en afhankelijkheden: Importeer de module: Neem de module op in je project. Dit houdt vaak in dat je een afhankelijkheid toevoegt aan de buildconfiguratie van je project. Afhankelijkheden injecteren: Gebruik injectie van afhankelijkheden om de nodige gegevensbronnen en services te leveren die de module nodig heeft. Dit houdt de component agnostisch over de oorsprong van zijn gegevens, wat flexibiliteit en herbruikbaarheid bevordert. De module initialiseren: Stel alle initiële configuraties of toestanden in die nodig zijn voor de module, zoals initiële gegevens of specifieke instellingen. De API van de module gebruiken: Communiceer met de module via de openbare API, meestal inclusief methoden om flows te starten die gegevens retourneren of weergaven integreren met uw applicatie. Conclusie: de toekomst van mobiele ontwikkeling ligt in modulaire architectuur Het omarmen van modulaire architectuur in mobiele ontwikkeling biedt talloze voordelen, die zowel het ontwikkelproces als het eindproduct verbeteren. Door applicaties op te splitsen in kleinere, beheersbare componenten dwingen we scheiding van zorgen af, bevorderen we herbruikbaarheid van code en verbeteren we de onderhoudbaarheid aanzienlijk. Modules maken geïsoleerd testen mogelijk, verkorten bouwtijden en creëren een stabiele testomgeving, wat uiteindelijk leidt tot een efficiëntere en betrouwbaardere ontwikkelworkflow.

Leestijd 5 min

Kamen Zhekov

De webapplicaties en websites van tegenwoordig moeten 24/7 beschikbaar zijn vanaf elke plek ter wereld en moeten bruikbaar en prettig in gebruik zijn vanaf elk apparaat of schermformaat. Daarnaast moeten ze veilig, flexibel en schaalbaar zijn om pieken in de vraag op te vangen. In deze blog laten we u kennismaken met de architectuur van moderne webapplicaties en gaan we dieper in op verschillende back-end en front-end frameworks en hoe ze samenwerken. Wanneer mensen oplossingen vergelijken die worden gebruikt voor het bouwen van webapplicaties en websites, is er meestal sprake van een soort pitting tegen de ander. Hier gaan we tegen deze stroom in en proberen we de verschillen in kaart te brengen, zodat je kunt beslissen of de ene, de andere of beide passen bij de use case die je in gedachten hebt. Een essentieel concept dat moet worden opgemerkt is dat back-end frameworks, zoals Flask of FastAPI , en front-end frameworks, zoals React of Vue JS , twee fundamenteel verschillende technologieën zijn die verschillende, hoewel verwante, problemen oplossen. Ze tegen elkaar uitspelen is daarom geen goede aanpak. Tegenwoordig, als je een iets complexere webapplicatie of websiteoplossing wilt bouwen, heb je vaak solide frameworks nodig die stukjes van zowel de front-end als de back-end kant aanpakken om te bereiken wat je zoekt. De specifieke kenmerken van je applicatie zullen bepalen wat die onderdelen zijn en of het de moeite waard is om te investeren in het gebruik van slechts één van de twee technologieën, of beide in combinatie. Doel van een back-end framework Een back-end framework is het "brein" van je webapplicatie. Het moet zorgen voor de meeste, zo niet alle, taken op het gebied van berekeningen, gegevensbeheer en modelmanipulatie. Laten we het voorbeeld van FastAPI nemen. Hoewel dit back-end webframework voornamelijk wordt gebruikt voor het ontwikkelen van RESTful API's, kan het ook worden toegepast voor het ontwikkelen van complete webapplicaties als het wordt gekoppeld aan een front-end engine zoals Jinja2. Het gebruik van alleen FastAPI en wat templating zou ideaal zijn als je een standalone API wilt waar andere ontwikkelaars mee kunnen communiceren. Een ander goed doel zou een website of webapp zijn die dashboards en inzichten biedt over gegevensinvoer (grafieken gebaseerd op bestanden die je uploadt, etc.) zonder functionaliteiten die afhankelijk zijn van snelle gebruikersinteracties. Hieronder vind je een voorbeeld van een applicatie die volledig is gebouwd met een Python back-end en Jinja2 als templating engine. Klik hier voor meer informatie over het project, de broncode, enz. Het probleem dat je zou kunnen tegenkomen bij het maken van een complete web app of website met FastAPI is dat de hele logica van het programma naar de back-end wordt geduwd, en de enige taak voor de browser en het apparaat aan de kant van de client is het renderen van de HTML/CSS/JS respons die er naar toe wordt gestuurd. De tijd tussen het moment dat de browser het verzoek doet om iets weer te geven en het moment dat de gebruiker het ziet, kan dan enorm variëren op basis van een heleboel factoren. Denk aan de belasting van de server, de snelheid van het internet van de gebruiker, het geheugengebruik of de CPU-efficiëntie van de server, de complexiteit van de gevraagde taak, ... Doel van een front-end framework Tot nu toe kan de back-end zorgen voor alle operaties die we willen dat onze webapp heeft, maar er is geen manier om echt te interageren met de gebruiker. Een front-end framework zorgt voor de gebruikerservaring - UI-elementen zoals knoppen, een landingspagina, een interactieve tutorial, het uploaden van een bestand - in principe verloopt elke interactie met de gebruiker via het front-end framework. Als we kijken naar React of Vue JS - dit zijn front-end frameworks voor het ontwikkelen van dynamische websites en single page applicaties. Ze hebben echter een back-end technologie nodig (zoals FastAPI, Flask of NodeJS) om een RESTful API te bieden, zodat wat ze tonen dynamisch en interactief kan zijn. Alleen React gebruiken zou gebeuren in situaties waarin er al bestaande gegevensbronnen zijn waarmee je kunt interageren (openbare API's, externe gegevensleveranciers, cloudservices, enzovoort) en het enige wat je wilt creëren is de gebruikersinteractie met die services. Maar we kunnen hier al zien dat, in theorie, het combineren van de sterke punten van een solide back-end framework - zoals Flask, FastAPI, of NodeJS - met een goed front-end framework een optie is, en dan nog een hele goede ook. Voorbeelden van die combinatie zijn de BBC World Service News websites die worden gerenderd met behulp van een React-gebaseerde Single Page Application met een NodeJS back-end (Express). Klik hier voor een gedetailleerd overzicht op de GitHub-pagina van het project. In deze gevallen proberen front-end frameworks een deel (of veel) van de taken van de back-end te delegeren naar de client-side. Alleen de computationeel zware delen blijven op de server, terwijl alles wat overblijft en snel uit te voeren is in de browser op het apparaat van de client wordt gedaan. Dit zorgt voor een goede gebruikerservaring, "snappiness" en is in feite een soort decentralisatie van delen van de uitvoering van de webapplicatie, waardoor de belasting en verantwoordelijkheden van de server afnemen. De twee combineren 🤝 Tegenwoordig bestaat de architectuur van goed gebouwde en schaalbare webapplicaties uit een client-side framework dat een toestand bijhoudt, bestaande uit een toestand van de gebruikersinterface en een toestand van het datamodel. Deze toestanden vertegenwoordigen respectievelijk UI-elementen die de visuele ruggengraat van een applicatie vormen, en data-elementen die gekoppeld zijn aan wat voor soort gegevens of modellen (bijvoorbeeld een gebruiker) gebruikt worden doorheen de applicatie. Elke verandering in de toestand van het gegevensmodel veroorzaakt een verandering in de UI-toestand van de applicatie. Veranderingen in de datamodellen worden veroorzaakt door een gebeurtenis die direct van de gebruiker komt (zoals een muisklik) of een gebeurtenis aan de serverkant (zoals de server die zegt dat er een nieuwe melding voor de gebruiker is). De combinatie van al deze factoren zorgt voor een geweldige gebruikerservaring die dichter in de buurt komt van een desktopapplicatie in plaats van een ouderwetse, trage website. Klaar voor meer? In onze volgende blog leggen we de sterke punten van Python en NodeJS uit, en hoe je daartussen moet kiezen.