Een “Single Page Application”

Bijna iedereen die veel websites bezoekt heeft een SPA (single page application) meegemaakt. Gmail, Google Maps, Netflix, Twitter…. een lange lijst. Het zijn allemaal SPA’s. Als je door Gmail heen navigeert, dan merk je dat er niet zoveel verandert. De “sidebar”, de “header” blijft hetzelfde als je van “Inbox” naar “Verzonden” gaat. De lijst met emails verandert, maar de layout en onderdelen van de pagina blijven hetzelfde. Dus de pagina wordt niet opnieuw geladen, alleen de lijst van emails verandert, alleen de delen die de inhoud wijzigen veranderen. Dit is het basisprincipe van een SPA. Dit zorgt ervoor dat het laden van die onderdelen veel sneller gaat, de pagina wordt niet opnieuw geladen, en zijn geen grote gebeurtenissen binnen de browser van de webbezoeker.

De ervaring voor de gebruiker is rustiger, de applicatie vertoont geen grote veranderingen, geen witte lege pagina’s, ook niet een fractie van een seconde. En de server heeft het ook makkelijker, die hoeft alleen maar dat stukje te doen wat verandert. Een win-win situatie.

Wat is er zo speciaal aan een SPA en hoe is dit mogelijk?

Op de meeste websites zijn op iedere pagina delen die nooit veranderen. Dit is een keuze. Een web-applicatie hoort op alle pagina’s dezelfde layout te hebben zodat de gebruiker makkelijk zijn weg kan vinden. We denken dan aan “headers”, “footers”, logo’s, “navigation-bar”, soms veranderen deze dingen wel binnen een sectie van een applicatie, maar zijn dan binnen die sectie toch weer consistent. SPA’s maken van deze ergonomische conditie een voordeel. De laadtijd van een applicatie per onderdeel is sneller, en het beeld is rustiger. Indien het asynchroon (reactive) is geprogrammeerd (iets dat binnen Angular de standaard is), dan hoeft de gebruiker zelfs niet te wachten tot dat de nieuwe items compleet zijn verzameld maar kan de pagina worden geupdate terwijl de items binnen komen. De applicatie blijft responsive. Omdat reactive ook betekent dat het laden geannuleerd kan worden kan de gebruiker ervoor kiezen om het laden halverwege af te breken door een andere keuze te maken. Bijvoorbeeld als de webapplicatie bezig is om de afbeelding van een televisie te laden kan de gebruiker beseffen dat hij verkeerd heeft geklikt, en alsnog op het goede klikken waardoor het laden stopt en de gebruiker direct naar een ander item gaat.

Qua ervaring werkt het zoals weergegeven op deze afbeelding (hierboven). In de linkse situatie moet de gebruiker wachten totdat de pagina klaar is met vernieuwen, en is het web, zeker bij een slechte netwerkverbinding enkele seconden niet responsive. Op mobiele apparaten, waar de netwerkverbinding soms een paar seconden wegvalt is dit al helemaal desastreus.

In een SPA applicatie is dit niet, en kan de gebruiker altijd het laden onderbreken, en is de hoeveelheid data die geladen moet worden beperkt, blijft het overgrote deel van de pagina, dat deel dat niet wordt gewijzigd, gewoon op het scherm. Geen flitsen, geen laadtijd, en al die tijd responsive. Dit is erg belangrijk voor een goede gebruikerservaring en in modern web-design onontbeerlijk.

Waarom houden ontwikkelaars van SPA?

Er zijn bezwaren. De leercurve is nogal steil. Verschillende concepten moeten tegelijkertijd worden geleerd en toegepast. Het reactive programmeren vereist een andere manier van nadenken, het observer-patroon moet worden begrepen. Maar als deze horde is genomen, en er is geoefend, dan komen er snel mooie resultaten. Immers het html-gedeelte blijft gelijk. Het is zo dat het vanwege de modulaire opzet eenvoudiger wordt. Men bouwt geen hele pagina’s meer, maar slechts gedeelten van een pagina, en de interactie tussen de delen, daarvoor zorgt de SPA-ontwikkel omgeving (bijvoorbeeld Angular).

Een ander voordeel van SPA is het loskoppelen van de back-end met de front-end, dit in tegenstelling tot de technieken waarin deze juist enorm zijn verweven. Door de loskoppeling is het mogelijk om meerdere interfaces te maken op dezelfde back-end bron. Data worden opgevraagd via REST-API’s op het moment dat het er toe doet. Ze worden niet meer ongevraagd meegeleverd. Ook is het eenvoudig mogelijk om meerdere servers op een web-applicatie te integreren. In een vierkantje op een sportpagina kan bijvoorbeeld een weer-applicatie worden getoond, of de kwaliteit van het zwemwater. Integratie van services kan op de client plaatsvinden. Plugin’s kunnen de bloeddruk tonen van een patiënt binnen de pagina waarin de patient’s NAW gegevens staan, en als daarna de bloedsuiker wordt gemeten kan die ook als plugin worden getoond. Door inzet van CORS kan een aanval via cross-site scripting worden voorkomen.

Voor programmeurs en web-designers is het eenvoudig om een multi-functionele web-applicatie te schrijven en daarin gebruik te maken van vele services.

Single Page vs Multi Page?  (SPA vs MPA)

Een lijstje van voor en tegen, zonder de illusie compleet te zijn:

SPAMPA
voortegenvoortegen
SPA is snel, de meeste resources worden maar een keer geladen. Alleen data worden heen en weer gezonden.De frameworks zelf worden in de client geladen waardoor SPA's langzamer laden. Dit wordt wel weer gecompenseerd door slimme (application-level) caching, en doordat de frameworks met reactive programming vanaf het begin responsive zijn.MPA's geven een heldere structuur van een applicatie. Niet functionaliteit wordt gedistribueerd, maar pagina's vooraf functioneel ingericht.Front-end en back-end zijn vast gekoppeld. De front-end wordt op de server opgebouwd.
Het ontwikkelen is modulair en gestroomlijnd. Er worden geen pagina's op de server opgebouwd, de serverbelasting is veel kleiner.Javascript moet actief zijn op de browser. Hoewel, indien dit niet zo is, bijvoorbeeld in sommige HMI's zijn er mogelijkheden om de pagina's server-side te renderen.Betere SEO is mogelijk omdat pagina's keywords per pagina kunnen inrichten waardoor ze een hogere ranking krijgen wanneer deze keyword gebaseerd is.Ontwikkelen kan complexer zijn doordat frameworks voor de server alsook voor de client moeten worden geschreven. Applicatiebouw duurt hierdoor langer.
SPA is eenvoudig te debuggen binnen Chrome waarin ontwikkeltools zijn geïntegreerd.
SPA's zijn makkelijk te transformeren naar andere devices, omdat dezelfde achtergrond-code wordt gebruikt.
SPA's kunnen zelfs tijdelijk zonder netwerkverbinding blijven werken, zonder dat de gebruiker hoeft te merken dat het netwerk instabiel is.

SPA? Angular, React, Vue?

Dit zijn ontwikkelomgevingen die het op efficiënte en eloquente wijze mogelijk maken om SPA’s te schrijven. Deze frameworks maken gebruik van herbruikbare componenten die in community-circuits te verkrijgen zijn. Niet iedere keer moet het wiel opnieuw worden uitgevonden. Het bouwen van web’s wordt veel sneller. Welke omgeving (Angular, React, Vue) de voorkeur geniet? Er zijn veel argumenten voor of tegen iedere omgeving. Immers is het ook belangrijk waarin je goed bent. Veranderen van programmeerconcept kost tijd, het veroorzaakt stress. Maar soms kan het niet anders.

Ik wil wel een paar punten meegeven ter overweging:

  • Hoe volwassen (mature) zijn de frameworks, libraries?
  • Worden de frameworks komende tijd nog wel voldoende ondersteund (is er een grote stabiele gebruikers-basis, zijn ze open source?)
  • Is er veel steun vanuit de communities bij het oplossen van problemen (kijk eens op stackoverflow)
  • Hoe makkelijk is het om goede programmeurs voor een framework te vinden?
  • Hoe schaalbaar (in complexiteit) zijn de frameworks, kun je makkelijk kleine applicaties schrijven, kun je makkelijk grote applicaties schrijven?
  • Hoe is de leer-curve voor een framework?
  • Welke performance verwacht je van een framework?

Migratie van MPA naar SPA?

Nu, de leercurve, die is wel lastig. Het vereist vele andere manieren van denken. De architectuur is anders, modulair denken, het reactive programmeren, het gebruiken van het Observer-patroon. Ook organisatorisch kan het consequenties hebben. Was er voorheen een taak voor een webdevelopers-team, het schrijven van een back-end en het schrijven van een front-end, en deze vast aan elkaar koppelen. Het front-end werd immers door het back-end gegenereerd. In De SPA situatie is dit volledig anders. De back-end programmeurs hoeven niet meer te weten wat de front-ends doen, op welke apparaten ze worden getoond. De front-end programmeurs hoeven niets over de backend te weten. Welke databases er zijn. Ze hoeven alleen maar de REST-API’s te kennen, en hoe de data worden opgeslagen/verwerkt is niet hun probleem.

Niet alleen de web-applicaties worden modulair, maar ook de bedrijfsorganisatie wordt modulair. Dit is een voordeel indien bedrijven in staat zijn om zonder kleerscheuren deze migratie uit te voeren. Immers de rollen die mensen vanuit oudsher hebben gaan wijzigen, en soms kan dit ook pijnlijk zijn. Dit zijn geen processen van een nacht ijs en moeten goed doordacht worden, willen we voorkomen dat er mensen gefrustreerd rondlopen.

Echter er zijn ook argumenten die het minder erg maken dan het op eerste gezicht lijkt. De backend wordt simpeler, maar de databases blijven hetzelfde. De bouwers van de front-end kunnen gebruik maken van de html-code van het MPA netwerk dat gaat verdwijnen. Ook grafische elementen kunnen worden hergebruikt. De kosten van de migratie kunnen dus meevallen, en de kosten van toekomstige applicaties kunnen per functie punt fors lager uitvallen.

Uiteindelijk zal de migratie op een scherpe markt wel moeten voor een bedrijf dat van internetgebruik en complexe applicaties afhankelijk is. Zeker als men in ogenschouw neemt de enorme en toenemende variëteit van apparaten, en omstandigheden waarmee applicatie-gebruikers de bedrijfsapplicatie willen benaderen. Een salesmanager wil thuis op zijn notebook werken, in de trein op een tablet en in een meeting even gauw op zijn mobiel. Op vliegvelden of op stations zijn er area’s waar het netwerk minder goed is. Het moet allemaal kunnen, zonder hoge ontwikkelkosten, zonder verlies van functionaliteit, door slim programmeren, door frameworks die veel van deze problemen out of the box oplossen. Uiteindelijk zal ieder bedrijf van MPA’s naar SPA’s migreren. De vragen gaan over wanneer, en wat zijn de consequenties.