Hvad er webapplikationsarkitektur?<\/h2>\n
Lad os starte diskussionen med at starte med definitionen af webapplikationsarkitektur.<\/p>\n
Med enkle ord er webapplikationsarkitektur en oversigt over, hvordan de forskellige komponenter i din webapplikation interagerer med hinanden.<\/p>\n
Det kan v\u00e6re s\u00e5 simpelt som at definere forholdet mellem klienten og serveren. Det kan ogs\u00e5 v\u00e6re s\u00e5 komplekst som at definere de indbyrdes relationer mellem en sv\u00e6rm af containeriserede backend-servere, load balancers, API-gateways og brugervendte single-page frontends.<\/p>\n
N\u00e5r det er sagt, handler det sj\u00e6ldent om at v\u00e6lge det programmeringssprog<\/a>, som du vil skrive din kode i.<\/p>\n Hvordan du designer din webapp spiller en afg\u00f8rende rolle for b\u00e5de dens brugervenlighed og din omkostningsoptimering. Her er et eksempel p\u00e5, hvordan en webapp-arkitektur ser ud p\u00e5 papiret:<\/p>\n Webapplikationsarkitektur er uden tvivl en af de vigtigste dele af din webapplikation. Hvis du v\u00e6lger at udvikle din webapplikation med en bestemt arkitektur i tankerne, er du sikker p\u00e5 at f\u00e5 mange fordele, n\u00e5r det kommer til vedligeholdelse og v\u00e6kst af din applikation.<\/p>\n Men ved at v\u00e6lge den rigtige arkitektur forst\u00e6rkes disse fordele yderligere.<\/p>\n Her er nogle af de vigtigste grunde til, at du seri\u00f8st b\u00f8r overveje at indf\u00f8re en webapplikationsarkitektur.<\/p>\n Din app er en vigtig indgang til din virksomhed, og forretningsbehovene udvikler sig i takt med det skiftende marked. For at kunne f\u00f8lge med, skal din app v\u00e6re fleksibel nok til at kunne tilpasses dine skiftende forretningsbehov. Og hvis du bygger en app uden at tage h\u00f8jde for indbygget fleksibilitet, vil du helt sikkert stadig skulle bruge mere tid og kr\u00e6fter p\u00e5 at foretage sm\u00e5 justeringer i din app senere hen.<\/p>\n Den rigtige webapplikationsarkitektur tager allerede h\u00f8jde for nogle af de \u00e6ndringer, som din virksomhed kan f\u00e5 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\u00e6lge en mikroservice-arkitektur frem for en monolitisk arkitektur.<\/p>\n Hvis du derimod bygger en intern app til din virksomhed med kun et eller to faste krav, kan du v\u00e6lge en enklere monolit for at fremskynde udviklingen og holde din kodebase ren.<\/p>\n Som vi n\u00e6vnte tidligere, giver den rigtige webapp-arkitektur dig en mere praktisk k\u00f8replan for udvikling. Arkitekturen giver nok modularitet i dit system til at isolere komponenter efter behov, og du f\u00e5r frihed til at v\u00e6lge den rigtige projektstruktur for hvert af dine moduler og komponenter efter behov.<\/p>\n Hvis du kaster dig ud i app-udvikling uden at have en arkitektur i tankerne, risikerer du at spilde tid og penge p\u00e5 at omorganisere dine komponenter og opstille nye regler for at lette samarbejdet mellem dine teammedlemmer<\/a> – tid og penge, som ellers kunne v\u00e6re brugt andre steder.<\/p>\n Udover at skrive koden til din app bruger du ogs\u00e5 en betydelig m\u00e6ngde tid p\u00e5 at administrere den. Organisering af dine projektfiler, opdeling af din app i moduler og ops\u00e6tning af brugerdefinerede pipelines er blot nogle af de opgaver, der kr\u00e6ver aktiv vedligeholdelse for at sikre en gnidningsfri\u00a0udvikling.<\/p>\n Den rigtige webapparkitektur g\u00f8r det nemt for dig at foretage \u00e6ndringer. Du f\u00e5r mulighed for at implementere komponentspecifikke best practices, adskille din apps smertepunkter fra hinanden og holde hver enkelt funktion uafh\u00e6ngig og l\u00f8st koblet. Det er ikke s\u00e5dan, at disse ting ikke kan g\u00f8res uden arkitektur; det skyldes blot, at den rigtige arkitektur g\u00f8r det hele meget enklere.<\/p>\n Hvis du f\u00f8lger en foruddefineret arkitektur, er det ogs\u00e5 lettere for dig at udvikle dine applikationer hurtigere. Den rigtige arkitektur kombineret med en god versionskontrolstrategi<\/a> kan g\u00f8re det muligt for dine udviklere at arbejde parallelt med hinanden og bygge funktioner hurtigere.<\/p>\n En webapparkitektur sikrer ogs\u00e5 din applikation mod fremtiden. N\u00e5r du f\u00f8rst 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.<\/p>\n De fleste webapparkitekturer tager h\u00f8jde for sikkerheden, n\u00e5r komponenterne struktureres. Udviklerne kan p\u00e5 forh\u00e5nd planl\u00e6gge de foranstaltninger og metoder, der skal implementeres for at forbedre appens sikkerhed<\/a>, inden den rulles ud til brugerne.<\/p>\n Det giver f.eks. mere mening at opbygge en OTT-videostreaming-app<\/a>, der b\u00e5de tilbyder betalt og gratis indhold, ved hj\u00e6lp af mikrotjenester, da mikrotjenestearkitekturen g\u00f8r det muligt at opdele din app i forretningsvenlige komponenter, f.eks. brugergodkendelse<\/a> og streaming af gratis eller betalt indhold. Hvis dit brugergodkendelsesmodul nogensinde g\u00e5r ned, kan du nemt konfigurere din app til at begr\u00e6nse adgangen til modulet med betalt indhold<\/a>, indtil auth er oppe at k\u00f8re, mens modulet med gratis indhold stadig er tilg\u00e6ngeligt for dine brugere.<\/p>\n I et alternativt tilf\u00e6lde, hvor den samme app var designet som en t\u00e6t koblet monolit, ville en nedlagt autentificeringstjeneste enten betyde en nedlagt applikation<\/a> eller at betalt indhold blev stillet gratis til r\u00e5dighed – resultater, som du for enhver pris vil undg\u00e5.<\/p>\n F\u00f8r vi taler om, hvordan webapplikationsarkitektur fungerer, er det vigtigt at forst\u00e5, hvordan et simpelt websted fungerer:<\/p>\n Hvis du skal dykke lidt dybere ned, kan du se her, hvordan en webapplikation<\/em> h\u00e5ndterer en foresp\u00f8rgsel:<\/p>\n Nu hvor du har en grundl\u00e6ggende id\u00e9 om, hvad webapplikationsarkitektur er, lad os se n\u00e6rmere p\u00e5 nogle af de popul\u00e6re typer af webapplikationsarkitektur, der anvendes p\u00e5 nettet.<\/p>\n Arkitekturen for en single-page application (SPA) er lige s\u00e5 enkel som dens navn: Hele applikationen er baseret p\u00e5 en enkelt side. N\u00e5r brugeren f\u00f8rst har hentet din app, beh\u00f8ver han\/hun ikke at navigere til andre websider. Appen er gjort dynamisk nok til at hente og gengive sk\u00e6rme, der opfylder brugernes krav, efterh\u00e5nden som de navigerer gennem selve appen.<\/p>\n SPA’er er fantastiske, n\u00e5r 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\u00e6re vanskelige at optimere med hensyn til SEO<\/a>.<\/p>\n Nogle af fordelene ved SPA-arkitektur er bl.a:<\/p>\n Nogle af ulemperne ved SPA-arkitektur er:<\/p>\n PWA-arkitekturen (Progressive Web Application) bygger oven p\u00e5 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<\/a> p\u00e5 tv\u00e6rs af platforme.<\/p>\n I lighed med SPA’er er PWA’er glatte og problemfri. Med den ekstra mulighed for at blive installeret p\u00e5 brugerens enheder (via service workers) f\u00e5r dine brugere en mere ensartet oplevelse med din applikation.<\/p>\n Samtidig kan det v\u00e6re sv\u00e6rt at optimere s\u00e5danne apps til SEO, og opdateringer p\u00e5 installerede apps kan v\u00e6re sv\u00e6re at skubbe ud.<\/p>\n Der er mange fordele ved PWA-arkitektur, bl.a:<\/p>\n Nogle af ulemperne ved PWA-arkitektur kan omfatte:<\/p>\n Ved server-side rendering (SSR) bliver frontend-websiderne gengivet p\u00e5 en backend-server, efter at brugeren har anmodet om dem. Dette bidrager til at reducere belastningen p\u00e5 klientenheden, da den modtager en statisk HTML-, CSS- og JS-webside.<\/p>\n SSR-apps er meget popul\u00e6re blandt blogs og e-handelswebsteder. Det skyldes, at de g\u00f8r linkstyring og SEO ganske enkelt. Desuden er den f\u00f8rste rendering for SSR-apps ret hurtig, da klienten ikke skal behandle nogen JS-kode for at rendere sk\u00e6rmene.<\/p>\n Nogle af fordelene ved SSR-arkitektur er anf\u00f8rt nedenfor:<\/p>\n Der er nogle f\u00e5 ulemper ved at bruge SSR-arkitekturen, bl.a:<\/p>\n Arkitekturen for pre-renderede applikationer er ogs\u00e5 kendt som arkitektur til generering af statiske websteder. I denne arkitektur genereres appens websider p\u00e5 forsiden p\u00e5 forh\u00e5nd og gemmes som HTML-, CSS- og JS-filer p\u00e5 serveren. N\u00e5r en bruger anmoder om en side, hentes den direkte og vises for brugeren. Dette g\u00f8r webappen meget hurtig, med minimale indl\u00e6sningstider af enhver art. Denne arkitektur \u00f8ger dog appens byggetid, da websiderne renderes under byggeprocessen.<\/p>\n Pre-renderede webapps er gode til, n\u00e5r du \u00f8nsker at generere statisk indhold som f.eks. blogs eller produktoplysninger, der ikke \u00e6ndres ofte. Du kan ogs\u00e5 g\u00f8re brug af skabeloner for at forenkle dit websidedesign. Det er dog n\u00e6sten umuligt at opbygge dynamiske webapps med denne arkitektur. Hvis du \u00f8nsker at opbygge en s\u00f8geside, der tager foresp\u00f8rgslen i sin vej (noget i stil med 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\u00f8re det).<\/p>\n Et par af de st\u00f8rste fordele ved en arkitektur med pre-renderede applikationer er:<\/p>\n Som med enhver arkitektonisk model har pre-rendered sin del af ulemper:<\/p>\n Isomorphic apps er apps, der er en blanding af server-side renderede apps og SPA’er. Det betyder, at s\u00e5danne apps f\u00f8rst renderes p\u00e5 serveren som en normal server-side renderede app. N\u00e5r de modtages af klienten, hydrerer appen sig selv og tilknytter den virtuelle DOM for at opn\u00e5 en hurtigere og mere effektiv klientbehandling. Dette forvandler i det v\u00e6sentlige appen til en applikation med en enkelt side.<\/p>\n Isomorphic bringer det bedste fra begge verdener sammen. Du f\u00e5r superhurtig behandling og brugergr\u00e6nseflade p\u00e5 klienten takket v\u00e6re SPA’en. Du f\u00e5r ogs\u00e5 hurtig f\u00f8rste rendering og fuldgyldig SEO- og linking-underst\u00f8ttelse takket v\u00e6re server-side rendering.<\/p>\n Her er blot nogle af fordelene ved at bruge isomorphic applikationsarkitektur:<\/p>\n Nogle af ulemperne ved isomorphic applikationsarkitektur kan v\u00e6re:<\/p>\n Den serviceorienterede arkitektur er blandt de mest popul\u00e6re alternativer til den traditionelle monolit-form for opbygning af apps. I denne arkitektur er webapps opdelt i tjenester, der hver is\u00e6r repr\u00e6senterer en funktionel forretningsenhed. Disse tjenester er l\u00f8st koblet sammen og interagerer med hinanden ved hj\u00e6lp af message passing.<\/p>\n Tjenesteorienteret arkitektur tilf\u00f8jer stabilitet og skalerbarhed til din applikations teknologiske stak. St\u00f8rrelsen 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\u00e6re et problem.<\/p>\n De vigtigste fordele ved serviceorienteret arkitektur er bl.a:<\/p>\n Her er en liste over potentielle ulemper ved at bruge serviceorienteret arkitektur:<\/p>\n Microservices-arkitekturen blev designet til at l\u00f8se problemerne med den serviceorienterede arkitektur. Microservices er endnu mere modul\u00e6re komponenter, der passer sammen for at opbygge en webapp. Microservices fokuserer dog p\u00e5 at holde hver enkelt komponent lille og med en afgr\u00e6nset kontekst. Begr\u00e6nset kontekst betyder grundl\u00e6ggende, at hver mikroservice har sin kode og sine data koblet sammen med minimale afh\u00e6ngigheder af andre mikroservices.<\/p>\n Microservices-arkitekturen er sandsynligvis den bedste arkitektur til at bygge apps, der har til form\u00e5l 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\u00e6ver en ekstra indsats; derfor passer den m\u00e5ske ikke godt til mindre brugssager.<\/p>\n Nogle fordele ved microservices-arkitektur omfatter:<\/p>\n En ulempe ved microservices-arkitektur kan v\u00e6re:<\/p>\n Serverless-arkitekturen er en anden varm nyhed i verden af webapp-arkitekturer. Denne arkitektur fokuserer p\u00e5 at opdele din applikation i forhold til de funktioner, som den skal udf\u00f8re. Derefter hostes disse funktioner p\u00e5 FaaS (Function-as-a-Service)-platforme<\/a> som funktioner, der p\u00e5kaldes, n\u00e5r der kommer foresp\u00f8rgsler ind.<\/p>\n I mods\u00e6tning til de fleste andre arkitekturer p\u00e5 denne liste bliver apps, der er bygget ved hj\u00e6lp af den serverless arkitektur, ikke k\u00f8rt hele tiden. De opf\u00f8rer sig ligesom funktioner ville g\u00f8re – de venter p\u00e5 at blive kaldt, og n\u00e5r de bliver kaldt, k\u00f8rer de den definerede proces og returnerer et resultat. P\u00e5 grund af denne karakter sk\u00e6rer de ned p\u00e5 vedligeholdelsesomkostningerne og er meget skalerbare uden st\u00f8rre indsats. Det er dog vanskeligt at udf\u00f8re langvarige opgaver ved hj\u00e6lp af s\u00e5danne komponenter.<\/p>\n Her er de vigtigste fordele ved serverless-arkitektur:<\/p>\n Nedenfor er nogle af ulemperne ved serverless-arkitektur:<\/p>\n Selv om de webapplikationsarkitekturer, du s\u00e5 ovenfor, m\u00e5ske alle ser ret forskellige ud fra hinanden, kan deres komponenter logisk set grupperes sammen i bestemte lag, der hj\u00e6lper med at n\u00e5 et forretningsm\u00e5l.<\/p>\n Pr\u00e6sentationslaget st\u00e5r for alt i en webapplikation, der er eksponeret for slutbrugerne. Pr\u00e6sentationslaget best\u00e5r f\u00f8rst og fremmest af frontend-klienten. Det indeholder dog ogs\u00e5 al logik, som du har skrevet p\u00e5 din backend for at g\u00f8re din frontend dynamisk. Dette giver dig plads til at betjene dine brugere med en brugergr\u00e6nseflade, der er skr\u00e6ddersyet til deres profil og krav.<\/p>\n Der anvendes tre grundl\u00e6ggende 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\u00e6rd, n\u00e5r brugerne interagerer med den). Oven p\u00e5 disse tre teknologier kan du bruge en hvilken som helst framework<\/a> til at g\u00f8re din udvikling let. Nogle almindelige frontend-frameworks omfatter Laravel<\/a>, React, NextJS, Vue, GatsbyJS osv.<\/p>\n 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\u00e5 adgang til, og bestemmer, hvordan infrastrukturen udnyttes til at betjene brugernes anmodninger.<\/p>\n I tilf\u00e6lde af en hotelbooking-app fungerer din klient-app som en portal, hvor brugerne kan indtaste hotelnavne og andre relevante data. Men s\u00e5 snart brugeren klikker p\u00e5 s\u00f8geknappen, modtager forretningslaget anmodningen og s\u00e6tter logikken i gang for at s\u00f8ge efter ledige hotelv\u00e6relser, der matcher dine krav. Klienten modtager derefter blot en liste over hotelv\u00e6relser uden nogen viden om, hvordan denne liste er blevet genereret, eller endog hvorfor listens elementer er arrangeret p\u00e5 den m\u00e5de, som de er blevet sendt.<\/p>\n Tilstedev\u00e6relsen af et s\u00e5dant lag sikrer, at din forretningslogik ikke er eksponeret for din klient og i sidste ende for brugerne. Isolering af forretningslogikken hj\u00e6lper enormt meget i f\u00f8lsomme operationer som f.eks. h\u00e5ndtering af betalinger eller forvaltning af sundhedsjournaler.<\/p>\n 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.<\/p>\n Dette lag best\u00e5r normalt af en databaseserver<\/a>. Du kan selv ops\u00e6tte dette lag ved at stille en database og en databaseserver til r\u00e5dighed i din on-prem-infrastruktur eller v\u00e6lge en ekstern\/administreret l\u00f8sning fra en af de f\u00f8rende cloud-infrastrukturudbydere som AWS, GCP, Microsoft Azure osv.<\/p>\n Nu hvor du forst\u00e5r, hvad der indg\u00e5r i en webapplikationsarkitektur, skal vi se n\u00e6rmere p\u00e5 hver enkelt af de komponenter, der indg\u00e5r i en webapplikation. Vi vil gruppere denne diskussion i to hovedoverskrifter – komponenter p\u00e5 serversiden og komponenter p\u00e5 klientsiden, eller backend- og frontend-komponenter<\/a>.<\/p>\n 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.<\/p>\n DNS er ansvarlig for at styre, hvordan din app eksponeres for internettet. DNS-poster bruges af HTTP-klienter, som ogs\u00e5 kan v\u00e6re en browser, til at finde og sende foresp\u00f8rgsler til din apps komponenter. DNS bruges ogs\u00e5 af dine frontend-klienter internt til at opl\u00f8se placeringen af dine webservere og API-slutpunkter for at sende anmodninger og behandle brugeroperationer.<\/p>\n Belastningsudligning er en anden popul\u00e6r komponent i webapplikationsarkitekturen. En load balancer bruges til at fordele HTTP-foresp\u00f8rgsler mellem flere identiske webservere. Hensigten med at have flere webservere er at opretholde redundans, der bidrager til at \u00f8ge fejltolerancen og distribuere trafikken for at opretholde en h\u00f8j ydeevne.<\/p>\n 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\u00e5 mellem flere servere.<\/p>\n Datalagring er en vigtig del af de fleste moderne applikationer, da der altid er nogle applikationsdata, der skal bevares p\u00e5 tv\u00e6rs af brugersessioner. Datalagring er af to typer:<\/p>\n 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\u00e5 adgang til det fra et datalager og behandle det, f\u00f8r det sendes tilbage til brugeren, lagres det ofte i cache. Her er de to mest popul\u00e6re typer caching, der anvendes p\u00e5 tv\u00e6rs af webapplikationer:<\/p>\n Ud over at eksponere en gr\u00e6nseflade for brugerne (frontend) og h\u00e5ndtere deres anmodninger (backend) er der en anden lidt mindre popul\u00e6r kategori af webapp-komponenter. Jobs er ofte baggrundstjenester, der skal udf\u00f8re opgaver, som ikke er tidsf\u00f8lsomme eller synkrone.<\/p>\n CRON-jobs er dem, der k\u00f8res p\u00e5 et fast tidsrum igen og igen. Disse jobs er planlagt i backenden til at k\u00f8re vedligeholdelsesrutiner automatisk p\u00e5 faste tidspunkter. Nogle almindelige eksempler p\u00e5 brug af disse job omfatter sletning af dubletter\/gamle poster fra databasen, udsendelse af p\u00e5mindelsesmails til kunder osv.<\/p>\n Komponenter p\u00e5 klientsiden er de komponenter, der er eksponeret for dine brugere enten direkte eller indirekte.<\/p>\n Der er hovedsageligt to typer komponenter i denne kategori.<\/p>\n Brugergr\u00e6nsefladen er det visuelle aspekt af din applikation. Det er det, som dine brugere ser og interagerer med for at f\u00e5 adgang til dine tjenester.<\/p>\n Frontend-gr\u00e6nsefladen er for det meste bygget p\u00e5 tre popul\u00e6re teknologier: HTML, CSS og JavaScript<\/a>. Frontend-brugergr\u00e6nsefladen kan v\u00e6re en applikation i sig selv med sin egen softwareudviklingslivscyklus.<\/p>\n Disse brugergr\u00e6nseflader rummer ikke en stor del af din forretningslogik, da de er eksponeret direkte for dine brugere. Hvis en ondsindet bruger fors\u00f8ger at reverse engineer din frontend-applikation, kan vedkommende f\u00e5 oplysninger om, hvordan din virksomhed fungerer, og udf\u00f8re ulovlige aktiviteter som f.eks. brand impersonation<\/a> og datatyveri.<\/p>\n Da brugergr\u00e6nsefladen i frontend-applikationen er direkte udsat for brugerne, skal du ogs\u00e5 optimere den for minimal indl\u00e6sningstid<\/a> og reaktionsevne. Nogle gange kan dette hj\u00e6lpe dig med at give dine brugere en bedre oplevelse og dermed \u00f8ge din virksomheds v\u00e6kst.<\/p>\n Nogle gange har du m\u00e5ske brug for at gemme noget forretningslogik p\u00e5 din klient for at kunne udf\u00f8re enklere operationer hurtigt. Logik p\u00e5 klientsiden, som normalt befinder sig i din frontend-applikation, kan hj\u00e6lpe dig med at springe turen til serveren over og give dine brugere en hurtigere oplevelse.<\/p>\n Dette er en valgfri funktion i klientsidekomponenterne. I nogle tilf\u00e6lde gemmes appens forretningslogik udelukkende p\u00e5 klientsiden (is\u00e6r n\u00e5r du bygger uden en traditionel backend-server<\/a>). Moderne l\u00f8sninger som BaaS hj\u00e6lper dig med at f\u00e5 adgang til almindelige operationer som f.eks. autentificering, datalagring, fillagring osv. p\u00e5 farten i din frontend-app.<\/p>\n Der er m\u00e5der at obfuscate eller minificere denne kode<\/a> p\u00e5, f\u00f8r du ruller den ud til dine brugere for at minimere risikoen for reverse-engineering.<\/p>\n Der findes flere modeller af webapplikationsarkitekturer, som hver is\u00e6r er baseret p\u00e5, hvordan webservere opretter forbindelse til deres datalagre.<\/p>\n Den enkleste model er en webserver, der forbinder til en databaseinstans. En s\u00e5dan model er nem at implementere og vedligeholde, og det er ogs\u00e5 ret nemt at tage den i produktion.<\/p>\n P\u00e5 grund af sin enkelhed er denne model velegnet til indl\u00e6ring og til sm\u00e5 eksperimentelle applikationer, som ikke vil blive udsat for stor trafik. Nybegyndere kan nemt ops\u00e6tte og pille ved disse apps for at l\u00e6re de grundl\u00e6ggende principper for udvikling af webapps<\/a>.<\/p>\n Denne model b\u00f8r dog ikke bruges i produktion, da den er meget up\u00e5lidelig. Et problem i enten serveren eller databasen kan resultere i nedetid og tabt forretning.<\/p>\n Denne model tager applikationen et skridt opad ved at ops\u00e6tte flere servere for redundans med en enkelt f\u00e6lles databaseinstans.<\/p>\n Da flere webservere har adgang til databasen samtidig, kan der opst\u00e5 problemer med inkonsekvens. For at undg\u00e5 dette er webserverne designet til at v\u00e6re stateless. Det betyder, at serverne ikke beholder data p\u00e5 tv\u00e6rs af sessioner; de behandler dem blot og lagrer dem i databasen.<\/p>\n Apps, der er lavet ved hj\u00e6lp af denne model, er helt sikkert mere p\u00e5lidelige end dem med den tidligere model, da tilstedev\u00e6relsen af flere webservere \u00f8ger webappens fejltolerance. Da databasen imidlertid stadig er \u00e9n f\u00e6lles instans, er den det svageste led i arkitekturen og kan v\u00e6re en kilde til fejl.<\/p>\n Denne model er en af de mest almindelige, traditionelle modeller for udformning af webapplikationer.<\/p>\n I dette tilf\u00e6lde skal du implementere din applikationslogik som flere identiske webserverinstanser, der er samlet bag en load balancer. Dit datalager vedligeholdes ogs\u00e5 p\u00e5 tv\u00e6rs af flere databaseinstanser for at \u00f8ge fejltolerancen.<\/p>\n Du kan ogs\u00e5 v\u00e6lge at opdele din database mellem de tilg\u00e6ngelige instanser for at forbedre ydeevnen eller opretholde dubletter af hele datalageret for at sikre redundans. I begge tilf\u00e6lde vil en fejl i en enkelt instans af din database ikke f\u00f8re til en fuldst\u00e6ndig afbrydelse af programmet.<\/p>\n Denne model er meget v\u00e6rdsat p\u00e5 grund af dens p\u00e5lidelighed og skalerbarhed. Det er dog relativt kompliceret at udvikle og vedligeholde applikationer ved hj\u00e6lp af denne model, og det kr\u00e6ver dyre og erfarne udviklere<\/a>. Som s\u00e5dan foresl\u00e5s denne model kun, n\u00e5r du bygger i stor skala.<\/p>\n Mens de tre ovenn\u00e6vnte modeller er velegnede til monolitiske applikationer, er der en anden model til modul\u00e6re applikationer.<\/p>\n Applikationsservicemodellen opdeler en app i mindre moduler baseret p\u00e5 forretningsfunktionalitet. Disse moduler kan v\u00e6re s\u00e5 sm\u00e5 som en funktion eller s\u00e5 store som en tjeneste.<\/p>\n Ideen her er at g\u00f8re hver enkelt forretningsfunktion uafh\u00e6ngig og skalerbar. Hvert af disse moduler kan oprette forbindelse til databasen p\u00e5 egen h\u00e5nd. Du kan endda have dedikerede databaseinstanser for at matche dit moduls skalerbarhedsbehov.<\/p>\n Blandt ikke-monolitiske apps er denne model ret popul\u00e6r. Gamle monolitter migreres ofte til denne model for at udnytte dens skalerbarhed og modul\u00e6re fordele. Administration af apps, der er bygget p\u00e5 en s\u00e5dan model, kr\u00e6ver dog ofte erfarne udviklere<\/a>, is\u00e6r erfaring med DevOps og CI\/CD.<\/p>\n Her er nogle bedste praksis, som du kan implementere i dit webapplikationsprojekt for at f\u00e5 mest muligt ud af den valgte webapp-arkitektur.<\/p>\n Dette kan ikke understreges nok: Sigt altid efter responsive frontends<\/a>. Uanset hvor stor og kompleks din webapp internt er, er det hele eksponeret for dine brugere via frontend-websider, -apps og -sk\u00e6rme.<\/p>\n Hvis dine brugere synes, at disse sk\u00e6rme er uintuitive eller langsomme, vil de ikke blive h\u00e6ngende l\u00e6nge nok til at se og beundre det tekniske vidunder, som din webapp er.<\/p>\n Derfor er det meget vigtigt at designe tilg\u00e6ngelige, brugervenlige og lette frontends.<\/p>\n Der findes masser af UI\/UX-best practice<\/a> p\u00e5 nettet til at hj\u00e6lpe dig med at forst\u00e5, hvad der fungerer bedst for dine brugere. Du kan finde fagfolk, der er dygtige til at lave brugervenlige designs og arkitekturer, der kan g\u00f8re det muligt for dine brugere at f\u00e5 mest muligt ud af dine apps.<\/p>\n Vi anbefaler, at du g\u00f8r dig seri\u00f8se overvejelser om din frontend’s responsivitet, inden du udruller dit produkt til dine brugere.<\/p>\n Ud over at v\u00e6re let at forst\u00e5 skal dine frontends ogs\u00e5 v\u00e6re hurtige til at indl\u00e6se<\/a>.<\/p>\n If\u00f8lge Portent<\/a> sker de h\u00f8jeste e-handelskonverteringsrater p\u00e5 sider med loadtider p\u00e5 mellem 0-2 sekunder, og if\u00f8lge Unbounce<\/a> indr\u00f8mmer ca. 70% af forbrugerne, at sidens loadtid er en vigtig faktor i deres valg af at k\u00f8be fra en online-s\u00e6lger.<\/p>\n N\u00e5r du designer mobile-native applikationer, kan du normalt ikke v\u00e6re sikker p\u00e5 dine brugeres enhedsspecifikationer. En enhed, der ikke opfylder kravene til din app, erkl\u00e6res typisk for ikke at underst\u00f8tte appen.<\/p>\n Dette er dog helt anderledes med web.<\/p>\n N\u00e5r 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\u00e6re sv\u00e6rt at optimere din frontend-oplevelse til en s\u00e5 bred vifte af brugere.<\/p>\n Tjenester som LightHouse og Google PageSpeed<\/a> kommer man til at t\u00e6nke p\u00e5, n\u00e5r man taler om frontend-ydelse. Du b\u00f8r bruge s\u00e5danne v\u00e6rkt\u00f8jer<\/a> til at benchmarke din frontend-app, f\u00f8r du udruller den i produktion. De fleste af disse v\u00e6rkt\u00f8jer giver dig en liste med handlingsanvisninger, der kan hj\u00e6lpe dig med at forbedre din app’s ydeevne mest muligt.<\/p>\n De sidste 5-10% af appens ydeevne er normalt specifikke for dit brugsscenarie og kan kun l\u00f8ses af en person, der kender din app og dens teknologier godt. Det skader aldrig at investere i webydelse<\/a>!<\/p>\n Som tidligere omtalt er PWA’er fremtidens design. De kan passe godt til de fleste brugssager, og de giver den mest ensartede oplevelse p\u00e5 tv\u00e6rs af de store platforme.<\/p>\n Du b\u00f8r overveje at bruge PWA til din app s\u00e5 ofte som muligt. Den native oplevelse p\u00e5 tv\u00e6rs af web og mobil er enormt effektiv for dine brugere og kan ogs\u00e5 reducere en stor del af din egen arbejdsbyrde.<\/p>\n PWA’er er ogs\u00e5 hurtige at indl\u00e6se, nemme at optimere og hurtige at bygge. Hvis du v\u00e6lger PWA’er, kan det hj\u00e6lpe dig med at flytte meget af dit fokus fra udvikling til forretning tidligt i forl\u00f8bet.<\/p>\n En ren kodebase kan hj\u00e6lpe dig med at opdage og l\u00f8se de fleste problemer, f\u00f8r de for\u00e5rsager skade. Her er nogle tips, du kan f\u00f8lge for at sikre, at din kodebase ikke giver dig flere problemer, end den burde.<\/p>\n CI\/CD st\u00e5r for Continuous Integration\/Continuous Deployment (kontinuerlig integration\/kontinuerlig implementering). CI\/CD-processer er afg\u00f8rende for udviklingen af din applikation, da de hj\u00e6lper dig med at bygge, teste og implementere dit projekt uden besv\u00e6r.<\/p>\n Du \u00f8nsker dog ikke at skulle k\u00f8re dem manuelt hver gang. Du b\u00f8r i stedet ops\u00e6tte pipelines, der udl\u00f8ses automatisk baseret p\u00e5 dit projekts aktiviteter. Du kan f.eks. ops\u00e6tte en pipeline, der k\u00f8rer dine tests automatisk, n\u00e5r du overf\u00f8rer din kode til dit versionskontrolsystem<\/a>. Der er ogs\u00e5 masser af mere komplekse anvendelsestilf\u00e6lde, f.eks. generering af artefakter p\u00e5 tv\u00e6rs af platforme fra dit kodelager, n\u00e5r der oprettes en udgivelse.<\/p>\n Mulighederne er uendelige, s\u00e5 det er op til dig at finde ud af, hvordan du kan f\u00e5 det bedste ud af dine CI\/CD-pipelines.<\/p>\n De fleste moderne apps er lavet af flere komponenter. Tag f\u00f8lgende app som et eksempel:<\/p>\n Klientforesp\u00f8rgsler ledes til appen via en API-gateway. Mens denne i \u00f8jeblikket kun tillader direkte anmodninger til appens hjemmemodul, kan den i fremtiden give adgang til flere komponenter uden at g\u00e5 gennem hjemmemodulet.<\/p>\n Dern\u00e6st kontrollerer hjemmemodulet et eksternt autentifikations-BaaS, f\u00f8r det giver adgang. N\u00e5r klienten er autentificeret, kan den f\u00e5 adgang til siderne “Opdater profil” eller “Vis profil”. Begge disse sider interagerer med en f\u00e6lles, administreret databasel\u00f8sning, der h\u00e5ndterer profildataene.<\/p>\n Som du kan se, ligner applikationen en meget grundl\u00e6ggende og minimal version af et online personregister<\/a>. Du kan tilf\u00f8je\/opdatere din egen profil eller se andre tilg\u00e6ngelige profiler.<\/p>\n Her er en hurtig legende over de forskellige komponenter i arkitekturen:<\/p>\n Komponenterne i hver af farverne ovenfor er s\u00e5rbare over for forskellige former for sikkerhedstrusler. Her er nogle f\u00e5 sikkerhedskonstruktioner, som du kan indf\u00f8re for at minimere din eksponering:<\/p>\n Selv om der kun er tale om en h\u00e5ndfuld forslag, viser de, at appsikkerhed er kompliceret, og det er dit ansvar at sikre, at du ikke efterlader nogen l\u00f8se ender, som angribere kan tr\u00e6kke i. Du kan ikke stole p\u00e5 en central sikkerhedskomponent til at beskytte din virksomhed; appsikkerhed er fordelt p\u00e5 tv\u00e6rs af din app-arkitektur.<\/p>\n Brugerfeedback<\/a> er et afg\u00f8rende v\u00e6rkt\u00f8j til at forst\u00e5, hvor godt din app klarer sig med hensyn til forretningsm\u00e6ssig og teknisk ydeevne. Du kan bygge den letteste og smidigste app i verden, men hvis den ikke lader dine brugere g\u00f8re det, de forventer, s\u00e5 g\u00e5r alle dine anstrengelser til spilde.<\/p>\n Der er flere m\u00e5der at indsamle brugerfeedback p\u00e5. Mens en hurtig og anonymiseret unders\u00f8gelse<\/a> er den konventionelle tilgang, kan du ogs\u00e5 v\u00e6lge en mere sofistikeret l\u00f8sning, f.eks. et heatmap over dine brugeres aktivitet.<\/p>\n![\"Komponentdiagram](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/10\/web-app-architecture-components.jpg\")
Hvorfor er webapplikationsarkitektur vigtig?<\/h2>\n
Tilpasning til virksomhedens behov nemt<\/h3>\n
Organiseret udvikling<\/h3>\n
Bedre styring af kodebasen<\/h3>\n
Forbedret sikkerhed<\/h3>\n
Hvordan fungerer webapplikationsarkitektur?<\/h2>\n
\n
\n
Typer af webapplikationsarkitektur<\/h2>\n
Single-Page-arkitektur<\/h3>\n
Fordele ved SPA-arkitektur<\/h4>\n
\n
Ulemper ved SPA-arkitektur<\/h4>\n
\n
Progressive Web Application Architecture<\/h3>\n
Fordele ved PWA-arkitektur<\/h4>\n
\n
Ulemper ved PWA-arkitektur<\/h4>\n
\n
Server-side-renderet arkitektur<\/h3>\n
Fordele ved SSR-arkitektur<\/h4>\n
\n
Ulemper ved SSR-arkitektur<\/h4>\n
\n
Forudrendte applikationer Arkitektur<\/h3>\n
https:\/\/myapp.com\/search\/foo+bar<\/code>), er du kommet til det forkerte sted.<\/p>\nFordele ved pre-renderet arkitektur<\/h4>\n
\n
Ulemper ved pr\u00e6-renderet arkitektur<\/h4>\n
\n
Isomorphic applikationsarkitektur<\/h3>\n
Fordele ved isomorphic Architecture<\/h4>\n
\n
Ulemper ved isomorphic arkitektur<\/h4>\n
\n
Tjenesteorienteret arkitektur<\/h3>\n
Fordele ved serviceorienteret arkitektur<\/h4>\n
\n
Ulemper ved serviceorienteret arkitektur<\/h4>\n
\n
Microservices-arkitektur<\/h3>\n
Fordele ved microservices-arkitektur<\/h4>\n
\n
Ulemper ved microservices-arkitektur<\/h4>\n
\n
Serverless arkitektur<\/h3>\n
Fordele ved serverl\u00f8s arkitektur<\/h4>\n
\n
Ulemper ved serverless arkitektur<\/h4>\n
\n
Lag af webapplikationsarkitektur<\/h2>\n
Pr\u00e6sentationslag<\/h3>\n
Forretningslag<\/h3>\n
Persistenslag<\/h3>\n
Webapplikationskomponenter<\/h2>\n
Server-side-komponenter<\/h3>\n
DNS og routing<\/h4>\n
Datalagring<\/h4>\n
\n
Caching<\/h4>\n
\n
Jobs og tjenester<\/h4>\n
Komponenter p\u00e5 klientsiden<\/h3>\n
Frontend-brugergr\u00e6nseflade<\/h4>\n
Client-side forretningslogik<\/h4>\n
Modeller af webapplikationskomponenter<\/h3>\n
\u00c9n server, \u00e9n database<\/h4>\n
Flere servere, \u00e9n database<\/h4>\n
Flere servere, flere databaser<\/h4>\n
App-tjenester<\/h4>\n
Bedste praksis for webapplikationsarkitektur<\/h2>\n
1. G\u00f8r din frontend responsiv<\/h3>\n
2. Overv\u00e5g loadtider<\/h3>\n
3. Foretr\u00e6kker PWA, hvor det er muligt<\/h3>\n
4. Hold din kodebase ren og kortfattet<\/h3>\n
\n
5. Automatis\u00e9r dine CI\/CD-processer<\/h3>\n
6. Indarbejd sikkerhedsfunktioner<\/h3>\n
![\"Komponentdiagram](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/09\/example-serverless-architecture.png\")
\n
\n
\n
\n
\n
\n
7. Indsaml brugerfeedback<\/h3>\n