Single Page Application (SPA)

Single Page Application / SPA-løsninger er den moderne måde at bygge frontend-applikationer på. Revolutionen inden for Javascript og tilknyttede frameworks som Vue.js, React og Angular har muliggjort struktureret og effektiv udvikling af lynhurtige og brugervenlige responsive frontends - og så kan det også være fundamentet for Progressive Web Apps (PWA'er)

Internettet, links og "klik og vent"

Den traditionelle webverden er baseret på HTTP (Hypertext Transfer Protocol) og hyperlinks. Klienter/browsere laver såkaldte HTTP-requests, og får HTTP-responses retur fra serverne. Typisk står serverne ved hvert request og genererer output i form af HTML, CSS og Javascript og sender det retur. Links bringer brugeren mellem ressourcer på internettet, og hver gang der klikkes på et link laves en HTTP-forespørgsel. Det betyder også, at alt hentes ned af klienten - downloades - for hver HTTP-forespørgsel. Billeder, sidehoved, navigation, sidefod, indhold, stylesheets, Javascripts etc. Det hele. Og at serveren skal generere alt - hver gang.

Det giver den gammeldags "klik og vent" oplevelse, og selv om forskellige caching-teknikker både server-side og client-side bliver benyttet, så er det stadig "klik og vent". Og egentlig ikke særlig smart. En Single Page Application (SPA) forsøger at gøre noget ved disse problemer. Den sigter mod kun at hente relevant data, når man navigerer internt på et website, ikke redundant data. Data/information hentes asynkront og ofte i baggrunden mens brugerens fokus er et andet sted. Det giver brugeren en lynhurtig og flydende oplevelse med lækre animationer. Med andre ord en bedre brugeroplevelse.

SPA'er og søgemaskineoptimering

SPA'er virker fundamentalt ved at browseren/klienten via Javascript laver asynkrone forespørgsler efter data. Hvad så hvis klienten ikke kan håndtere Javascript? Eller tilsvarende: Ikke ønsker at eksekvere Javascript? Ja, så bliver der ikke hentet noget data, og dermed heller ikke noget indhold. Det er ikke godt for søgemaskineoptimeringen (Search Engine Optimization = SEO), da indholdet jo er en helt central del af denne diciplin.

Såfremt applikationen ikke behøver indeksering og synlighed i søgemaskinerne, så kan vi være lige glade. Det kan f.eks. være applikationer til administration (f.eks. et Content Management System, et PIM-system eller lignende) eller det kan være en B2B e-handelsløsning bag login. Men, hvis vi har at gøre med en kundevendt applikation, f.eks. et offentligt tilgængelig website eller en B2C-webshop, så er SEO med al sandsynlighed vigtig. I så fald skal man sandsynligvis indføre en form for Server Side Rendering, der giver SPA-løsningen det bedste fra begge verdener: Indhold uden Javascript-eksekvering for dem der ikke vil det (f.eks. søgemaskinerne), og Javascript til asynkrone, usability orienterede klienter (f.eks. en kunde via en browser).

Server Side Rendering (SSR) og sammenhængen med Jamstack

Server Side Rendering (SSR) er egentlig det som foregår i den traditionelle "HTTP-klik-og-vent" verden, men når vi taler om SSR i forbindelse med SPA-løsninger, så arbejder vi med værktøjer, der ved hjælp af én og samme kodebase, skaber en applikation der har frontend-koden prerenderet på serveren, samtidig med at frontendkoden også kan client-side-renderes vha. Javascript.

Ved første HTTP-request til serveren, vil den pre-renderede frontend-kode således blive returneret som et HTTP-response, mens evt. efterfølgende HTTP-requests kan blive udført som asynkrone kald via Javascript - ligesom SPA-løsninger er tænkt.

Med SSR bliver SPA-løsningen en såkaldt "isomorphic app". Den kan både generere/rendere applikationen client-side og server-side. Eftersom udgangspunktet for client-side-rendering og SPA'er er Javascript (og vi ønsker én fælles kodebase), så er langt de fleste SSR-teknikker også baseret på Javascript. Til Javascript server-side er det svært at komme uden om Node.js, og til udvikling af isomorphic apps, findes der en række teknologier og værktøjer baseret på Node.js og Javascript frontend-frameworks.

En interessant mulighed er, at tage SSR videre til det som hedder "Static Site Generation" (SSG). I stedet for at eksekvere Javascript på en server, og så efterfølgende cache server-side renderede sider og levere dem til klienterne, så kan man lade SSG'ere bygge hele statiske sites. At benytte moderne frontend-frameworks som React, Vue.js osv. og så benytte SSG til at prebygge websites, er blevet samlet i den arkitektur som kaldes Jamstack.

Frameworks og værktøjer til SPA'er

Javascript frameworks til SPA'er er i heftig udvikling lige nu. Der går nærmest ikke en måned uden at et nyt forslag til fremtidens vinder bliver præsenteret. De mest populære er lige nu React og Vue.js, og det er netop de to frameworks vi primært arbejder med hos LAIT.

Til SSR og SSG findes der ligeledes en lang række værktøjer. Hos LAIT er det især Nuxt kombineret med Vue.js og så React kombineret med Gatsby.

I forbindelse med med SPA, SSG og Jamstack-arkitektur er headless CMS og headless commerce løsninger aktuelle, og meget ofte indgår driftsplatformene Netlify og Azure i de samlede microservices-orienterede løsninger.

SPA'er og Progressive Web Apps

SPA-løsninger er ofte udgangspunkt for en Progressive Web App (PWA), men ikke nødvendigvis. PWA'er er allerede meget udbredte, og hos LAIT forventer vi at PWA'er stille og roligt vil tage markedsandele fra de native apps der i mange år har fandtes til telefonerne (iOS-apps og Android-apps). PWA'er har den store fordel at der kun er én kodebase at vedligeholde, uanset om applikationen bliver brugt via browser eller installeret på telefon, og derudover er PWA'er bygget på web-teknologier.

PWA'er er egentlig webapplikationer som definitionsmæssigt skal leve op til følgende:

  1. Kommunikation over HTTPS

  2. Skal have en valid Web Manifest fil med et minimums sæt af ikoner

  3. Skal registrere en Service Worker med en Fetch Event Handler og et minimum af offline support

Der er altså nødvendigvis ikke så langt fra en moderne SPA-løsning til en PWA, men selvfølgelig bør man have et formål med PWA'en og betragte den som en selvstændig kanal med muligheder der kan udnyttes.

Læs mere om PWA'er i vores artikel om emnet.