Hvad er webapplikationsarkitektur? Forklaring af en webapplikation

Verden er flyttet til internettet, og webapplikationer er blevet de nye arbejdspladser og kommercielle butikker. For at imødekomme de mange forskellige formål, som moderne webapplikationer tjener, skal hver enkelt af dem være designet med henblik på høj ydeevne og tilpasningsmuligheder.

Webapplikationsarkitekturer løser dette problem.

Webapplikationsarkitektur definerer, hvordan de forskellige komponenter i en webbaseret applikation er struktureret. Denne arkitektur er meget specifik i forhold til webapplikationens art og formål. Hvis du vælger den forkerte arkitektur til din webapplikation, kan det gå ud over din virksomhed.

I denne vejledning vil vi forklare begrebet webapplikationsarkitektur og forstå, hvordan det påvirker slutbrugeroplevelsen af din applikation. Mod slutningen vil vi også se på nogle af de bedste praksisser, du kan implementere for at få mest muligt ud af din webapplikation.

Hvad er webapplikationsarkitektur?

Lad os starte diskussionen med at starte med definitionen af webapplikationsarkitektur.

Med enkle ord er webapplikationsarkitektur en oversigt over, hvordan de forskellige komponenter i din webapplikation interagerer med hinanden.

Det kan være så simpelt som at definere forholdet mellem klienten og serveren. Det kan også være så komplekst som at definere de indbyrdes relationer mellem en sværm af containeriserede backend-servere, load balancers, API-gateways og brugervendte single-page frontends.

Når det er sagt, handler det sjældent om at vælge det programmeringssprog, som du vil skrive din kode i.

Hvordan du designer din webapp spiller en afgørende rolle for både dens brugervenlighed og din omkostningsoptimering. Her er et eksempel på, hvordan en webapp-arkitektur ser ud på papiret:

Hvorfor er webapplikationsarkitektur vigtig?

Webapplikationsarkitektur er uden tvivl en af de vigtigste dele af din webapplikation. Hvis du vælger at udvikle din webapplikation med en bestemt arkitektur i tankerne, er du sikker på at få mange fordele, når det kommer til vedligeholdelse og vækst af din applikation.

Men ved at vælge den rigtige arkitektur forstærkes disse fordele yderligere.

Her er nogle af de vigtigste grunde til, at du seriøst bør overveje at indføre en webapplikationsarkitektur.

Tilpasning til virksomhedens behov nemt

Din app er en vigtig indgang til din virksomhed, og forretningsbehovene udvikler sig i takt med det skiftende marked. For at kunne følge med, skal din app være fleksibel nok til at kunne tilpasses dine skiftende forretningsbehov. Og hvis du bygger en app uden at tage højde for indbygget fleksibilitet, vil du helt sikkert stadig skulle bruge mere tid og kræfter på at foretage små justeringer i din app senere hen.

Den rigtige webapplikationsarkitektur tager allerede højde for nogle af de ændringer, som din virksomhed kan få brug for i fremtiden. Hvis du f.eks. ved, at du bygger en e-handelsapplikation, der skal skaleres og en dag skal levere en bred vifte af tjenester til et stort antal kunder, vil det give dig mere fleksibilitet at vælge en mikroservice-arkitektur frem for en monolitisk arkitektur.

Hvis du derimod bygger en intern app til din virksomhed med kun et eller to faste krav, kan du vælge en enklere monolit for at fremskynde udviklingen og holde din kodebase ren.

Organiseret udvikling

Som vi nævnte tidligere, giver den rigtige webapp-arkitektur dig en mere praktisk køreplan for udvikling. Arkitekturen giver nok modularitet i dit system til at isolere komponenter efter behov, og du får frihed til at vælge den rigtige projektstruktur for hvert af dine moduler og komponenter efter behov.

Hvis du kaster dig ud i app-udvikling uden at have en arkitektur i tankerne, risikerer du at spilde tid og penge på at omorganisere dine komponenter og opstille nye regler for at lette samarbejdet mellem dine teammedlemmer – tid og penge, som ellers kunne være brugt andre steder.

Bedre styring af kodebasen

Udover at skrive koden til din app bruger du også en betydelig mængde tid på at administrere den. Organisering af dine projektfiler, opdeling af din app i moduler og opsætning af brugerdefinerede pipelines er blot nogle af de opgaver, der kræver aktiv vedligeholdelse for at sikre en gnidningsfri udvikling.

Den rigtige webapparkitektur gør det nemt for dig at foretage ændringer. Du får mulighed for at implementere komponentspecifikke best practices, adskille din apps smertepunkter fra hinanden og holde hver enkelt funktion uafhængig og løst koblet. Det er ikke sådan, at disse ting ikke kan gøres uden arkitektur; det skyldes blot, at den rigtige arkitektur gør det hele meget enklere.

Hvis du følger en foruddefineret arkitektur, er det også lettere for dig at udvikle dine applikationer hurtigere. Den rigtige arkitektur kombineret med en god versionskontrolstrategi kan gøre det muligt for dine udviklere at arbejde parallelt med hinanden og bygge funktioner hurtigere.

En webapparkitektur sikrer også din applikation mod fremtiden. Når du først har defineret en solid strategi for, hvordan du skal organisere appens komponenter, kan du nemt migrere disse komponenter til nyere teknologier en efter en, uden at skulle lave hele din applikation om.

Forbedret sikkerhed

De fleste webapparkitekturer tager højde for sikkerheden, når komponenterne struktureres. Udviklerne kan på forhånd planlægge de foranstaltninger og metoder, der skal implementeres for at forbedre appens sikkerhed, inden den rulles ud til brugerne.

Det giver f.eks. mere mening at opbygge en OTT-videostreaming-app, der både tilbyder betalt og gratis indhold, ved hjælp af mikrotjenester, da mikrotjenestearkitekturen gør det muligt at opdele din app i forretningsvenlige komponenter, f.eks. brugergodkendelse og streaming af gratis eller betalt indhold. Hvis dit brugergodkendelsesmodul nogensinde går ned, kan du nemt konfigurere din app til at begrænse adgangen til modulet med betalt indhold, indtil auth er oppe at køre, mens modulet med gratis indhold stadig er tilgængeligt for dine brugere.

I et alternativt tilfælde, hvor den samme app var designet som en tæt koblet monolit, ville en nedlagt autentificeringstjeneste enten betyde en nedlagt applikation eller at betalt indhold blev stillet gratis til rådighed – resultater, som du for enhver pris vil undgå.

Hvordan fungerer webapplikationsarkitektur?

Før vi taler om, hvordan webapplikationsarkitektur fungerer, er det vigtigt at forstå, hvordan et simpelt websted fungerer:

1. Brugeren indtaster appens URL-adresse i browserens adresselinje eller klikker på et link.
2. Browseren slår URL-adressen op i DNS-serverne og identificerer IP-adressen på din app.
3. Browseren sender en HTTP-forespørgsel til din app.
4. Din app svarer med det korrekte indhold (normalt en webside).
5. Browseren gengiver websiden på skærmen.

Hvis du skal dykke lidt dybere ned, kan du se her, hvordan en webapplikation håndterer en forespørgsel:

1. Brugeren sender en anmodning til din app via din brugergrænseflade i frontend.
2. Hvis du har oprettet en relevant cache, vil appen først kontrollere den for at se, om den har en gyldig post, der kan sendes direkte tilbage til klienten. Hvis ja, sendes det cachede indhold tilbage, og anmodningen markeres som afsluttet.
3. Hvis der ikke er nogen cache, videresendes anmodningen til load balanceren.
4. Load balanceren identificerer en serverinstans, der er tilgængelig til at håndtere anmodningen, og videresender den.
5. Serverinstansen behandler anmodningen og kalder eventuelle eksterne API’er, hvis det er nødvendigt.
6. Når resultaterne er samlet ét sted, sender serveren svaret tilbage til load balanceren.
7. Lastbalancereren returnerer svaret til API-gatewayen, som igen sender det ned til brugeren i frontend-klienten. Anmodningen markeres derefter som afsluttet.

Typer af webapplikationsarkitektur

Nu hvor du har en grundlæggende idé om, hvad webapplikationsarkitektur er, lad os se nærmere på nogle af de populære typer af webapplikationsarkitektur, der anvendes på nettet.

Single-Page-arkitektur

Arkitekturen for en single-page application (SPA) er lige så enkel som dens navn: Hele applikationen er baseret på en enkelt side. Når brugeren først har hentet din app, behøver han/hun ikke at navigere til andre websider. Appen er gjort dynamisk nok til at hente og gengive skærme, der opfylder brugernes krav, efterhånden som de navigerer gennem selve appen.

SPA’er er fantastiske, når det drejer sig om at give slutbrugerne eller forbrugerne en hurtig og problemfri oplevelse. De mangler dog det touch, som et traditionelt websted har, og de kan være vanskelige at optimere med hensyn til SEO.

Fordele ved SPA-arkitektur

Nogle af fordelene ved SPA-arkitektur er bl.a:

• Du kan bygge meget interaktive webapps.
• SPA’er er nemme at skalere.
• Optimering af SPA’er med henblik på ydeevne kræver ikke en stor indsats.

Ulemper ved SPA-arkitektur

Nogle af ulemperne ved SPA-arkitektur er:

• SPA’er begrænser fleksibiliteten med hyperlinks og SEO.
• Den første rendering er normalt langsom.
• Navigation gennem appen ikke kan være intuitiv.

Progressive Web Application Architecture

PWA-arkitekturen (Progressive Web Application) bygger oven på Single Page Architecture ved at give din webapp offline-funktioner. Teknologier som Capacitor og Ionic bruges til at bygge PWA’er, der kan give brugerne en ensartet oplevelse på tværs af platforme.

I lighed med SPA’er er PWA’er glatte og problemfri. Med den ekstra mulighed for at blive installeret på brugerens enheder (via service workers) får dine brugere en mere ensartet oplevelse med din applikation.

Samtidig kan det være svært at optimere sådanne apps til SEO, og opdateringer på installerede apps kan være svære at skubbe ud.

Fordele ved PWA-arkitektur

Der er mange fordele ved PWA-arkitektur, bl.a:

• Apps kører meget smidigt og tilbyder kompatibilitet på tværs af platforme.
• Skalerbarhed er enkel.
• Offlineadgang og enheds-native API’er som baggrundsarbejdere og push-meddelelser er tilgængelige for udviklere.

Ulemper ved PWA-arkitektur

Nogle af ulemperne ved PWA-arkitektur kan omfatte:

• Der er begrænset understøttelse af linkstyring og SEO.
• Det er mere komplekst at skubbe opdateringer til offline PWA’er end med native apps.
• Der er begrænset understøttelse af PWA’er på tværs af webbrowsere og operativsystemer.

Server-side-renderet arkitektur

Ved server-side rendering (SSR) bliver frontend-websiderne gengivet på en backend-server, efter at brugeren har anmodet om dem. Dette bidrager til at reducere belastningen på klientenheden, da den modtager en statisk HTML-, CSS- og JS-webside.

SSR-apps er meget populære blandt blogs og e-handelswebsteder. Det skyldes, at de gør linkstyring og SEO ganske enkelt. Desuden er den første rendering for SSR-apps ret hurtig, da klienten ikke skal behandle nogen JS-kode for at rendere skærmene.

Fordele ved SSR-arkitektur

Nogle af fordelene ved SSR-arkitektur er anført nedenfor:

• Disse apps er gode til SEO-tunge websteder.
• Indlæsningen af første side er næsten øjeblikkelig i de fleste tilfælde.
• Du kan parre den sammen med en caching-tjeneste for at forbedre din apps ydeevne yderligere.

Ulemper ved SSR-arkitektur

Der er nogle få ulemper ved at bruge SSR-arkitekturen, bl.a:

• Det anbefales ikke til komplekse eller tunge websider, da serveren kan tage tid om at generere siden fuldt ud, hvilket resulterer i en forsinket første rendering.
• Det anbefales mest til apps, der ikke fokuserer meget på brugergrænsefladen, og som kun er på udkig efter øget skalerbarhed eller sikkerhed.

Forudrendte applikationer Arkitektur

Arkitekturen for pre-renderede applikationer er også kendt som arkitektur til generering af statiske websteder. I denne arkitektur genereres appens websider på forsiden på forhånd og gemmes som HTML-, CSS- og JS-filer på serveren. Når en bruger anmoder om en side, hentes den direkte og vises for brugeren. Dette gør webappen meget hurtig, med minimale indlæsningstider af enhver art. Denne arkitektur øger dog appens byggetid, da websiderne renderes under byggeprocessen.

Pre-renderede webapps er gode til, når du ønsker at generere statisk indhold som f.eks. blogs eller produktoplysninger, der ikke ændres ofte. Du kan også gøre brug af skabeloner for at forenkle dit websidedesign. Det er dog næsten umuligt at opbygge dynamiske webapps med denne arkitektur. Hvis du ønsker at opbygge en søgeside, der tager forespørgslen i sin vej (noget i stil med https://myapp.com/search/foo+bar), er du kommet til det forkerte sted.

Da hver mulig rute i appen er pre-renderet under byggeprocessen, er det umuligt at have dynamiske ruter som ovenfor, da der er uendelige muligheder, som ikke kan pre-renderes under opbygningen (og det giver heller ikke mening at gøre det).

Fordele ved pre-renderet arkitektur

Et par af de største fordele ved en arkitektur med pre-renderede applikationer er:

• Websider genereres i ren HTML, CSS og JS, og derfor svarer deres ydeevne til den af apps, der er bygget med vanilla JS.
• Hvis du kender din app’s mulige ruter, bliver SEO super nemt.

Ulemper ved præ-renderet arkitektur

Som med enhver arkitektonisk model har pre-rendered sin del af ulemper:

• Dynamisk indhold kan ikke serveres med disse apps.
• Hvis der foretages ændringer i webappen, betyder det, at appen skal bygges helt om og implementeres fra bunden.

Isomorphic applikationsarkitektur

Isomorphic apps er apps, der er en blanding af server-side renderede apps og SPA’er. Det betyder, at sådanne apps først renderes på serveren som en normal server-side renderede app. Når de modtages af klienten, hydrerer appen sig selv og tilknytter den virtuelle DOM for at opnå en hurtigere og mere effektiv klientbehandling. Dette forvandler i det væsentlige appen til en applikation med en enkelt side.

Isomorphic bringer det bedste fra begge verdener sammen. Du får superhurtig behandling og brugergrænseflade på klienten takket være SPA’en. Du får også hurtig første rendering og fuldgyldig SEO- og linking-understøttelse takket være server-side rendering.

Fordele ved isomorphic Architecture

Her er blot nogle af fordelene ved at bruge isomorphic applikationsarkitektur:

• Isomorphic apps har super hurtig første rendering og fuld understøttelse af SEO.
• Disse apps fungerer også godt på klienten, da de forvandles til en SPA efter indlæsning.

Ulemper ved isomorphic arkitektur

Nogle af ulemperne ved isomorphic applikationsarkitektur kan være:

• Opsætning af en sådan app kræver dygtige talenter.
• Mulighederne for tech stack er begrænsede, når det drejer sig om at designe en isomorphic app. Du kan kun vælge mellem en håndfuld (for det meste) JS-baserede biblioteker og frameworks.

Tjenesteorienteret arkitektur

Den serviceorienterede arkitektur er blandt de mest populære alternativer til den traditionelle monolit-form for opbygning af apps. I denne arkitektur er webapps opdelt i tjenester, der hver især repræsenterer en funktionel forretningsenhed. Disse tjenester er løst koblet sammen og interagerer med hinanden ved hjælp af message passing.

Tjenesteorienteret arkitektur tilføjer stabilitet og skalerbarhed til din applikations teknologiske stak. Størrelsen af tjenesterne i SOA er imidlertid ikke klart defineret og er normalt knyttet til forretningskomponenter og ikke til tekniske komponenter, og derfor kan vedligeholdelse nogle gange være et problem.

Fordele ved serviceorienteret arkitektur

De vigtigste fordele ved serviceorienteret arkitektur er bl.a:

• Denne arkitektur er med til at bygge meget skalerbare og pålidelige apps.
• Komponenterne kan genbruges og deles for at forbedre udviklings- og vedligeholdelsesarbejdet.

Ulemper ved serviceorienteret arkitektur

Her er en liste over potentielle ulemper ved at bruge serviceorienteret arkitektur:

• SOA-apps er stadig ikke 100% fleksible, da størrelsen og omfanget af hver tjeneste ikke er fastlagt. Der kan være tjenester på størrelse med virksomhedsapplikationer, som kan være vanskelige at vedligeholde.
• Deling af komponenter medfører afhængighed mellem tjenesterne.

Microservices-arkitektur

Microservices-arkitekturen blev designet til at løse problemerne med den serviceorienterede arkitektur. Microservices er endnu mere modulære komponenter, der passer sammen for at opbygge en webapp. Microservices fokuserer dog på at holde hver enkelt komponent lille og med en afgrænset kontekst. Begrænset kontekst betyder grundlæggende, at hver mikroservice har sin kode og sine data koblet sammen med minimale afhængigheder af andre mikroservices.

Microservices-arkitekturen er sandsynligvis den bedste arkitektur til at bygge apps, der har til formål at skalere til tusindvis og millioner af brugere en dag. Hver komponent er modstandsdygtig, skalerbar og nem at vedligeholde. Men vedligeholdelse af DevOps-livscyklusen for en microservices-baseret app kræver en ekstra indsats; derfor passer den måske ikke godt til mindre brugssager.

Fordele ved microservices-arkitektur

Nogle fordele ved microservices-arkitektur omfatter:

• App-komponenter er meget modulære, uafhængige og kan genbruges i højere grad end komponenterne i den serviceorienterede arkitektur.
• Hver komponent kan skaleres uafhængigt af hinanden for at imødekomme varierende brugertrafik.
• Microservices-baserede apps er meget fejltolerante.

Ulemper ved microservices-arkitektur

En ulempe ved microservices-arkitektur kan være:

• For mindre projekter kan microservices-arkitekturen kræve for meget arbejde at vedligeholde.

Serverless arkitektur

Serverless-arkitekturen er en anden varm nyhed i verden af webapp-arkitekturer. Denne arkitektur fokuserer på at opdele din applikation i forhold til de funktioner, som den skal udføre. Derefter hostes disse funktioner på FaaS (Function-as-a-Service)-platforme som funktioner, der påkaldes, når der kommer forespørgsler ind.

I modsætning til de fleste andre arkitekturer på denne liste bliver apps, der er bygget ved hjælp af den serverless arkitektur, ikke kørt hele tiden. De opfører sig ligesom funktioner ville gøre – de venter på at blive kaldt, og når de bliver kaldt, kører de den definerede proces og returnerer et resultat. På grund af denne karakter skærer de ned på vedligeholdelsesomkostningerne og er meget skalerbare uden større indsats. Det er dog vanskeligt at udføre langvarige opgaver ved hjælp af sådanne komponenter.

Fordele ved serverløs arkitektur

Her er de vigtigste fordele ved serverless-arkitektur:

• Serverless apps er meget og let skalerbare. De kan endda tilpasse sig den indkommende trafik i realtid for at reducere belastningen på din infrastruktur.
• Sådanne apps kan gøre brug af prismodellen med betaling pr. brug på serverløse platforme for at reducere infrastrukturomkostningerne.
• Serverless apps er ret nemme at bygge og implementere, da det eneste, du skal gøre, er at skrive en funktion og hoste den på en platform som Firebase-funktioner, AWS Lambda osv.

Ulemper ved serverless arkitektur

Nedenfor er nogle af ulemperne ved serverless-arkitektur:

• Langvarige opgaver kan være dyre at udføre på en sådan arkitektur.
• Når en funktion modtager en anmodning efter lang tid, kaldes det en koldstart. Koldstarter er langsomme og kan give en dårlig oplevelse for din slutbruger.

Lag af webapplikationsarkitektur

Selv om de webapplikationsarkitekturer, du så ovenfor, måske alle ser ret forskellige ud fra hinanden, kan deres komponenter logisk set grupperes sammen i bestemte lag, der hjælper med at nå et forretningsmål.

Præsentationslag

Præsentationslaget står for alt i en webapplikation, der er eksponeret for slutbrugerne. Præsentationslaget består først og fremmest af frontend-klienten. Det indeholder dog også al logik, som du har skrevet på din backend for at gøre din frontend dynamisk. Dette giver dig plads til at betjene dine brugere med en brugergrænseflade, der er skræddersyet til deres profil og krav.

Der anvendes tre grundlæggende teknologier til at opbygge dette lag: HTML, CSS og JavaScript. HTML udstikker din frontend, CSS stilarter den, og JS giver den liv (dvs. styrer dens adfærd, når brugerne interagerer med den). Oven på disse tre teknologier kan du bruge en hvilken som helst framework til at gøre din udvikling let. Nogle almindelige frontend-frameworks omfatter Laravel, React, NextJS, Vue, GatsbyJS osv.

Forretningslag

Forretningslaget er ansvarlig for at holde og administrere din app’s arbejdslogik. Det er normalt en backend-tjeneste, der accepterer anmodninger fra klienten og behandler dem. Det styrer, hvad brugeren kan få adgang til, og bestemmer, hvordan infrastrukturen udnyttes til at betjene brugernes anmodninger.

I tilfælde af en hotelbooking-app fungerer din klient-app som en portal, hvor brugerne kan indtaste hotelnavne og andre relevante data. Men så snart brugeren klikker på søgeknappen, modtager forretningslaget anmodningen og sætter logikken i gang for at søge efter ledige hotelværelser, der matcher dine krav. Klienten modtager derefter blot en liste over hotelværelser uden nogen viden om, hvordan denne liste er blevet genereret, eller endog hvorfor listens elementer er arrangeret på den måde, som de er blevet sendt.

Tilstedeværelsen af et sådant lag sikrer, at din forretningslogik ikke er eksponeret for din klient og i sidste ende for brugerne. Isolering af forretningslogikken hjælper enormt meget i følsomme operationer som f.eks. håndtering af betalinger eller forvaltning af sundhedsjournaler.

Persistenslag

Persistenslaget er ansvarligt for at kontrollere adgangen til dine datalagre. Det fungerer som et ekstra abstraktionslag mellem dine datalagre og dit forretningslag. Det modtager alle datarelaterede kald fra forretningslagene og behandler dem ved at oprette sikre forbindelser til databasen.

Dette lag består normalt af en databaseserver. Du kan selv opsætte dette lag ved at stille en database og en databaseserver til rådighed i din on-prem-infrastruktur eller vælge en ekstern/administreret løsning fra en af de førende cloud-infrastrukturudbydere som AWS, GCP, Microsoft Azure osv.

Webapplikationskomponenter

Nu hvor du forstår, hvad der indgår i en webapplikationsarkitektur, skal vi se nærmere på hver enkelt af de komponenter, der indgår i en webapplikation. Vi vil gruppere denne diskussion i to hovedoverskrifter – komponenter på serversiden og komponenter på klientsiden, eller backend- og frontend-komponenter.

Server-side-komponenter

Server-side komponenter er de komponenter, der befinder sig i backend-delen af din webapplikation. De er ikke eksponeret direkte for brugerne og indeholder den vigtigste forretningslogik og de vigtigste ressourcer for din webapplikation.

DNS og routing

DNS er ansvarlig for at styre, hvordan din app eksponeres for internettet. DNS-poster bruges af HTTP-klienter, som også kan være en browser, til at finde og sende forespørgsler til din apps komponenter. DNS bruges også af dine frontend-klienter internt til at opløse placeringen af dine webservere og API-slutpunkter for at sende anmodninger og behandle brugeroperationer.

Belastningsudligning er en anden populær komponent i webapplikationsarkitekturen. En load balancer bruges til at fordele HTTP-forespørgsler mellem flere identiske webservere. Hensigten med at have flere webservere er at opretholde redundans, der bidrager til at øge fejltolerancen og distribuere trafikken for at opretholde en høj ydeevne.

API-slutpunkter bruges til at eksponere backend-tjenester til frontend-applikationen. De er med til at lette kommunikationen mellem klienten og serveren, og nogle gange endda også mellem flere servere.

Datalagring

Datalagring er en vigtig del af de fleste moderne applikationer, da der altid er nogle applikationsdata, der skal bevares på tværs af brugersessioner. Datalagring er af to typer:

• Databaser: Databaser bruges til at lagre data med henblik på hurtig adgang. Normalt understøtter de lagring af en lille mængde data, som din applikation har regelmæssig adgang til.
• Data warehouses: Data warehouses er beregnet til opbevaring af historiske data. Disse er normalt ikke nødvendige særlig ofte i appen, men behandles regelmæssigt for at generere forretningsindsigt.

Caching

Caching er en valgfri funktion, der ofte implementeres i webapp-arkitekturer for at levere indhold hurtigere til brugerne. En stor del af app-indholdet er ofte gentaget i et vist tidsrum, hvis ikke altid. I stedet for at få adgang til det fra et datalager og behandle det, før det sendes tilbage til brugeren, lagres det ofte i cache. Her er de to mest populære typer caching, der anvendes på tværs af webapplikationer:

• Data caching: Data caching introducerer en måde, hvorpå din app nemt og hurtigt kan få adgang til regelmæssigt anvendte data, der ikke ændres ofte. Teknologier som Redis og Memcache muliggør caching af data for at spare dyre databaseforespørgsler, der blot skal hente de samme data igen og igen.
• Caching af websider: Et CDN (Content Delivery Network) cacher websider på samme måde som Redis cacher data. På samme måde som data, der ikke ændres ofte, kun lagres i cachen, anbefales det normalt kun at lagre statiske websider i cachen. For server-side-renderede webapplikationer hjælper caching ikke meget, da deres indhold forventes at være meget dynamisk.

Jobs og tjenester

Ud over at eksponere en grænseflade for brugerne (frontend) og håndtere deres anmodninger (backend) er der en anden lidt mindre populær kategori af webapp-komponenter. Jobs er ofte baggrundstjenester, der skal udføre opgaver, som ikke er tidsfølsomme eller synkrone.

CRON-jobs er dem, der køres på et fast tidsrum igen og igen. Disse jobs er planlagt i backenden til at køre vedligeholdelsesrutiner automatisk på faste tidspunkter. Nogle almindelige eksempler på brug af disse job omfatter sletning af dubletter/gamle poster fra databasen, udsendelse af påmindelsesmails til kunder osv.

Komponenter på klientsiden

Komponenter på klientsiden er de komponenter, der er eksponeret for dine brugere enten direkte eller indirekte.

Der er hovedsageligt to typer komponenter i denne kategori.

Frontend-brugergrænseflade

Brugergrænsefladen er det visuelle aspekt af din applikation. Det er det, som dine brugere ser og interagerer med for at få adgang til dine tjenester.

Frontend-grænsefladen er for det meste bygget på tre populære teknologier: HTML, CSS og JavaScript. Frontend-brugergrænsefladen kan være en applikation i sig selv med sin egen softwareudviklingslivscyklus.

Disse brugergrænseflader rummer ikke en stor del af din forretningslogik, da de er eksponeret direkte for dine brugere. Hvis en ondsindet bruger forsøger at reverse engineer din frontend-applikation, kan vedkommende få oplysninger om, hvordan din virksomhed fungerer, og udføre ulovlige aktiviteter som f.eks. brand impersonation og datatyveri.

Da brugergrænsefladen i frontend-applikationen er direkte udsat for brugerne, skal du også optimere den for minimal indlæsningstid og reaktionsevne. Nogle gange kan dette hjælpe dig med at give dine brugere en bedre oplevelse og dermed øge din virksomheds vækst.

Client-side forretningslogik

Nogle gange har du måske brug for at gemme noget forretningslogik på din klient for at kunne udføre enklere operationer hurtigt. Logik på klientsiden, som normalt befinder sig i din frontend-applikation, kan hjælpe dig med at springe turen til serveren over og give dine brugere en hurtigere oplevelse.

Dette er en valgfri funktion i klientsidekomponenterne. I nogle tilfælde gemmes appens forretningslogik udelukkende på klientsiden (især når du bygger uden en traditionel backend-server). Moderne løsninger som BaaS hjælper dig med at få adgang til almindelige operationer som f.eks. autentificering, datalagring, fillagring osv. på farten i din frontend-app.

Der er måder at obfuscate eller minificere denne kode på, før du ruller den ud til dine brugere for at minimere risikoen for reverse-engineering.

Modeller af webapplikationskomponenter

Der findes flere modeller af webapplikationsarkitekturer, som hver især er baseret på, hvordan webservere opretter forbindelse til deres datalagre.

Én server, én database

Den enkleste model er en webserver, der forbinder til en databaseinstans. En sådan model er nem at implementere og vedligeholde, og det er også ret nemt at tage den i produktion.

På grund af sin enkelhed er denne model velegnet til indlæring og til små eksperimentelle applikationer, som ikke vil blive udsat for stor trafik. Nybegyndere kan nemt opsætte og pille ved disse apps for at lære de grundlæggende principper for udvikling af webapps.

Denne model bør dog ikke bruges i produktion, da den er meget upålidelig. Et problem i enten serveren eller databasen kan resultere i nedetid og tabt forretning.

Flere servere, én database

Denne model tager applikationen et skridt opad ved at opsætte flere servere for redundans med en enkelt fælles databaseinstans.

Da flere webservere har adgang til databasen samtidig, kan der opstå problemer med inkonsekvens. For at undgå dette er webserverne designet til at være stateless. Det betyder, at serverne ikke beholder data på tværs af sessioner; de behandler dem blot og lagrer dem i databasen.

Apps, der er lavet ved hjælp af denne model, er helt sikkert mere pålidelige end dem med den tidligere model, da tilstedeværelsen af flere webservere øger webappens fejltolerance. Da databasen imidlertid stadig er én fælles instans, er den det svageste led i arkitekturen og kan være en kilde til fejl.

Flere servere, flere databaser

Denne model er en af de mest almindelige, traditionelle modeller for udformning af webapplikationer.

I dette tilfælde skal du implementere din applikationslogik som flere identiske webserverinstanser, der er samlet bag en load balancer. Dit datalager vedligeholdes også på tværs af flere databaseinstanser for at øge fejltolerancen.

Du kan også vælge at opdele din database mellem de tilgængelige instanser for at forbedre ydeevnen eller opretholde dubletter af hele datalageret for at sikre redundans. I begge tilfælde vil en fejl i en enkelt instans af din database ikke føre til en fuldstændig afbrydelse af programmet.

Denne model er meget værdsat på grund af dens pålidelighed og skalerbarhed. Det er dog relativt kompliceret at udvikle og vedligeholde applikationer ved hjælp af denne model, og det kræver dyre og erfarne udviklere. Som sådan foreslås denne model kun, når du bygger i stor skala.

App-tjenester

Mens de tre ovennævnte modeller er velegnede til monolitiske applikationer, er der en anden model til modulære applikationer.

Applikationsservicemodellen opdeler en app i mindre moduler baseret på forretningsfunktionalitet. Disse moduler kan være så små som en funktion eller så store som en tjeneste.

Ideen her er at gøre hver enkelt forretningsfunktion uafhængig og skalerbar. Hvert af disse moduler kan oprette forbindelse til databasen på egen hånd. Du kan endda have dedikerede databaseinstanser for at matche dit moduls skalerbarhedsbehov.

Blandt ikke-monolitiske apps er denne model ret populær. Gamle monolitter migreres ofte til denne model for at udnytte dens skalerbarhed og modulære fordele. Administration af apps, der er bygget på en sådan model, kræver dog ofte erfarne udviklere, især erfaring med DevOps og CI/CD.

Bedste praksis for webapplikationsarkitektur

Her er nogle bedste praksis, som du kan implementere i dit webapplikationsprojekt for at få mest muligt ud af den valgte webapp-arkitektur.

1. Gør din frontend responsiv

Dette kan ikke understreges nok: Sigt altid efter responsive frontends. Uanset hvor stor og kompleks din webapp internt er, er det hele eksponeret for dine brugere via frontend-websider, -apps og -skærme.

Hvis dine brugere synes, at disse skærme er uintuitive eller langsomme, vil de ikke blive hængende længe nok til at se og beundre det tekniske vidunder, som din webapp er.

Derfor er det meget vigtigt at designe tilgængelige, brugervenlige og lette frontends.

Der findes masser af UI/UX-best practice på nettet til at hjælpe dig med at forstå, hvad der fungerer bedst for dine brugere. Du kan finde fagfolk, der er dygtige til at lave brugervenlige designs og arkitekturer, der kan gøre det muligt for dine brugere at få mest muligt ud af dine apps.

Vi anbefaler, at du gør dig seriøse overvejelser om din frontend’s responsivitet, inden du udruller dit produkt til dine brugere.

2. Overvåg loadtider

Ud over at være let at forstå skal dine frontends også være hurtige til at indlæse.

Ifølge Portent sker de højeste e-handelskonverteringsrater på sider med loadtider på mellem 0-2 sekunder, og ifølge Unbounce indrømmer ca. 70% af forbrugerne, at sidens loadtid er en vigtig faktor i deres valg af at købe fra en online-sælger.

Når du designer mobile-native applikationer, kan du normalt ikke være sikker på dine brugeres enhedsspecifikationer. En enhed, der ikke opfylder kravene til din app, erklæres typisk for ikke at understøtte appen.

Dette er dog helt anderledes med web.

Når det drejer sig om webapplikationer, kan dine brugere bruge alt fra den nyeste Apple Macbook M1 Pros til gamle Blackberry- og Nokia-telefoner til at se din app. Det kan til tider være svært at optimere din frontend-oplevelse til en så bred vifte af brugere.

Tjenester som LightHouse og Google PageSpeed kommer man til at tænke på, når man taler om frontend-ydelse. Du bør bruge sådanne værktøjer til at benchmarke din frontend-app, før du udruller den i produktion. De fleste af disse værktøjer giver dig en liste med handlingsanvisninger, der kan hjælpe dig med at forbedre din app’s ydeevne mest muligt.

De sidste 5-10% af appens ydeevne er normalt specifikke for dit brugsscenarie og kan kun løses af en person, der kender din app og dens teknologier godt. Det skader aldrig at investere i webydelse!

3. Foretrækker PWA, hvor det er muligt

Som tidligere omtalt er PWA’er fremtidens design. De kan passe godt til de fleste brugssager, og de giver den mest ensartede oplevelse på tværs af de store platforme.

Du bør overveje at bruge PWA til din app så ofte som muligt. Den native oplevelse på tværs af web og mobil er enormt effektiv for dine brugere og kan også reducere en stor del af din egen arbejdsbyrde.

PWA’er er også hurtige at indlæse, nemme at optimere og hurtige at bygge. Hvis du vælger PWA’er, kan det hjælpe dig med at flytte meget af dit fokus fra udvikling til forretning tidligt i forløbet.

4. Hold din kodebase ren og kortfattet

En ren kodebase kan hjælpe dig med at opdage og løse de fleste problemer, før de forårsager skade. Her er nogle tips, du kan følge for at sikre, at din kodebase ikke giver dig flere problemer, end den burde.

• Fokus på genbrug af kode: Det er ikke kun overflødigt at vedligeholde kopier af den samme kode i hele kodebasen, men det kan også medføre, at der sniger sig uoverensstemmelser ind, hvilket gør kodebasen vanskelig at vedligeholde. Fokuser altid på at genbruge kode, hvor det er muligt.
• Planlæg din projektstruktur: Softwareprojekter kan vokse sig meget store med tiden. Hvis du ikke begynder med en planlagt struktur for kodeorganisering og ressourcer, kan du ende med at bruge mere tid på at finde filer end på at skrive nyttig kode.
• Skriv enhedstests: Ethvert stykke kode har en chance for at gå i stykker. Det er ikke muligt at teste det hele manuelt, så du har brug for en fast strategi for automatisering af tests for din kodebase. Test runners og kodeoverdækningsværktøjer kan hjælpe dig med at identificere, om dine bestræbelser på at teste enheder giver de ønskede resultater.
• Høj modularitet: Når du skriver kode, skal du altid fokusere på modularitet. Hvis du skriver kode, der er tæt koblet til andre kodestykker, er det svært at teste, genbruge og ændre den efter behov.

5. Automatisér dine CI/CD-processer

CI/CD står for Continuous Integration/Continuous Deployment (kontinuerlig integration/kontinuerlig implementering). CI/CD-processer er afgørende for udviklingen af din applikation, da de hjælper dig med at bygge, teste og implementere dit projekt uden besvær.

Du ønsker dog ikke at skulle køre dem manuelt hver gang. Du bør i stedet opsætte pipelines, der udløses automatisk baseret på dit projekts aktiviteter. Du kan f.eks. opsætte en pipeline, der kører dine tests automatisk, når du overfører din kode til dit versionskontrolsystem. Der er også masser af mere komplekse anvendelsestilfælde, f.eks. generering af artefakter på tværs af platforme fra dit kodelager, når der oprettes en udgivelse.

Mulighederne er uendelige, så det er op til dig at finde ud af, hvordan du kan få det bedste ud af dine CI/CD-pipelines.

6. Indarbejd sikkerhedsfunktioner

De fleste moderne apps er lavet af flere komponenter. Tag følgende app som et eksempel:

Klientforespørgsler ledes til appen via en API-gateway. Mens denne i øjeblikket kun tillader direkte anmodninger til appens hjemmemodul, kan den i fremtiden give adgang til flere komponenter uden at gå gennem hjemmemodulet.

Dernæst kontrollerer hjemmemodulet et eksternt autentifikations-BaaS, før det giver adgang. Når klienten er autentificeret, kan den få adgang til siderne “Opdater profil” eller “Vis profil”. Begge disse sider interagerer med en fælles, administreret databaseløsning, der håndterer profildataene.

Som du kan se, ligner applikationen en meget grundlæggende og minimal version af et online personregister. Du kan tilføje/opdatere din egen profil eller se andre tilgængelige profiler.

Her er en hurtig legende over de forskellige komponenter i arkitekturen:

• Blå bokse: App-moduler, som eventuelt hostes som mikrotjenester eller serverløse funktioner.
• Røde bokse: Eksterne BaaS-komponenter, der sørger for autentificering og database.
• Grøn kasse: Routingkomponent, der modererer indgående anmodninger fra klienten.
• Sort boks: Din klientapplikation, der udsættes for brugeren.

Komponenterne i hver af farverne ovenfor er sårbare over for forskellige former for sikkerhedstrusler. Her er nogle få sikkerhedskonstruktioner, som du kan indføre for at minimere din eksponering:

• App-moduler (blå): Da disse er serverløse funktioner, er her et par tips til at styrke deres sikkerhed:
  • Isolér app-hemmeligheder og administrer dem uafhængigt af din kildekode
  • Oprethold adgangskontrol via IAM-tjenester
  • Forbedr din testindsats for også at finde sikkerhedstrusler ved hjælp af teknikker som SAST
• Eksterne tjenester (rød):
  • Opsætning af adgangskontrol via deres IAM-moduler for at regulere adgangen
  • Vælg API-hastighedsbegrænsning
  • For tjenester som databaser skal du opsætte finere kontroltilladelser, f.eks. hvem der kan få adgang til profilernes data, hvem der kan se brugernes data osv. Mange tjenester, som Firebase, leverer et detaljeret sæt af sådanne regler.
• Rutekomponent (grøn):
  • Som alle andre komponenter skal du implementere adgangskontrol
  • Opsæt autorisation
  • Dobbelttjek på bedste standardpraksis såsom CORS
• Klient:
  • Sørg for, at ingen app-hemmeligheder er tilgængelige for din klient
  • Skjul din klientkode for at minimere risikoen for reverse engineering

Selv om der kun er tale om en håndfuld forslag, viser de, at appsikkerhed er kompliceret, og det er dit ansvar at sikre, at du ikke efterlader nogen løse ender, som angribere kan trække i. Du kan ikke stole på en central sikkerhedskomponent til at beskytte din virksomhed; appsikkerhed er fordelt på tværs af din app-arkitektur.

7. Indsaml brugerfeedback

Brugerfeedback er et afgørende værktøj til at forstå, hvor godt din app klarer sig med hensyn til forretningsmæssig og teknisk ydeevne. Du kan bygge den letteste og smidigste app i verden, men hvis den ikke lader dine brugere gøre det, de forventer, så går alle dine anstrengelser til spilde.

Der er flere måder at indsamle brugerfeedback på. Mens en hurtig og anonymiseret undersøgelse er den konventionelle tilgang, kan du også vælge en mere sofistikeret løsning, f.eks. et heatmap over dine brugeres aktivitet.

Valget af metode til indsamling af feedback er mindre vigtigt end at tage handling på den indsamlede feedback. Kunderne elsker virksomheder, der lytter til deres problemer. Giganter som McDonald’s og Tesla gør det, og det er en af grundene til, at de fortsat har succes på deres markeder.

Opsummering

Internettet er en enorm legeplads med en række forskellige applikationer, der alle er designet på hver sin måde. Flere typer af arkitekturer gør plads til, at webapplikationer kan diversificeres, trives og tilbyde tjenester til brugere over hele verden.

I denne guide har vi opdelt de forskellige modeller for webapp-arkitektur og vist dig, hvor afgørende de er for en applikations vækst.

Er der en webapp-arkitektur, som du virkelig var vild med? Eller er der en anden, som du gerne vil dele med verden? Lad os vide det i kommentarerne nedenfor!