Världen har flyttat över till internet och webbapplikationer har blivit de nya arbetsplatserna och kommersiella butikerna. För att tillgodose de många olika ändamålen som moderna webbapplikationer har så måste var och en av dem utformas för hög prestanda och anpassningsbarhet.

Webbapplikationsarkitekturer löser detta problem.

Webbapplikationsarkitektur definierar hur de olika komponenterna i en webbaserad applikation är strukturerade. Denna arkitektur är väldigt specifik för webbapplikationens karaktär och syfte. Om du väljer fel arkitektur för din webbapplikation så kan din verksamhet skadas.

I den här guiden så kommer vi att bryta ner begreppet webbapplikationsarkitektur och förstå hur det påverkar slutanvändarens upplevelse av din applikation. Mot slutet så kommer vi även att titta på några av de bästa metoderna som du kan implementera för att få ut så mycket som möjligt av din webbapplikation.

Vad är webbapplikationsarkitektur?

För att inleda diskussionen så börjar vi med en definition av webbapplikationsarkitektur.

Om man ska uttrycka sig enkelt så är webbapplikationsarkitektur en översikt över hur olika komponenter i din webbapplikation interagerar med varandra.

Det kan vara så enkelt som att definiera förhållandet mellan klienten och servern. Det kan även vara så komplext som att definiera förhållandet mellan en svärm av containeriserade backend-servrar, laddningsbalanserare, API-gateways och frontend-servrar med en enda sida som vänder sig till användaren.

Med detta sagt så handlar det sällan om att välja det programmeringsspråk som du ska skriva din kod i.

Hur du utformar din webbapplikation spelar dock en viktig roll för både dess användbarhet och din kostnadsoptimering. Här är ett exempel på hur en webbapplikationsarkitektur ser ut:

Arkitekturdiagram för en rekommendationsapplikation. (Bildkälla: Wikipedia)
Arkitekturdiagram för en rekommendationsapplikation. (Bildkälla: Wikipedia)

Varför är det viktigt med arkitektur för webbapplikationer?

Webbapplikationsarkitekturen är utan tvekan en av de viktigaste delarna av din webbapplikation. Om du väljer att utveckla din webbapplikation med en specifik arkitektur i åtanke så kommer du garanterat att få många fördelar när det gäller att underhålla och utveckla din applikation.

Om du väljer rätt arkitektur så förstärker du dock dessa fördelar ytterligare.

Här är några av de främsta skälen till att du allvarligt bör överväga att anta en arkitektur för webbapplikationer.

Enkel anpassning till verksamhetens behov

Din app är en viktig inkörsport till din verksamhet, och verksamhetens behov utvecklas i takt med att marknaden förändras. För att hänga med så bör du se till att din app är tillräckligt flexibel för att kunna anpassas till dina föränderliga affärsbehov. Om du bygger en app utan att ta hänsyn till den inbyggda flexibiliteten så kommer du att behöva lägga ner allt mer tid och kraft på att göra små justeringar i din app.

Rätt arkitektur för webbapplikationer tar redan hänsyn till vissa av de förändringar som ditt företag kan behöva i framtiden. Om du exempelvis vet att du bygger en e-handelsapplikation som en dag kommer att skalas och erbjuda ett brett utbud av tjänster till ett stort antal kunder, så skulle du få mer flexibilitet om du valde en mikrotjänstarkitektur framför en monolitisk arkitektur.

Om du däremot bygger en intern app för ditt företag med endast ett eller två fasta krav så kan du välja en enklare monolit för att snabba upp utvecklingen och hålla din kodbas ren.

Organiserad utveckling

Som vi nämnde tidigare så skapar rätt webbapplikationsarkitektur en bekvämare färdplan för utvecklingen. Arkitekturen ger tillräckligt med modularitet i ditt system för att isolera komponenter vid behov, och du får friheten att välja rätt projektstruktur för var och en av dina moduler och komponenter.

Om du ger dig in i apputveckling utan att ha en arkitektur i åtanke så riskerar du att slösa tid och pengar på att omorganisera dina komponenter och fastställa nya regler för att underlätta samarbetet mellan dina teammedlemmar — tid och pengar som annars kunde ha använts på annat håll.

Bättre hantering av kodbasen

Förutom att skriva koden till din app så kommer du även att spendera en avsevärd mängd tid på att hantera den. Att organisera dina projektfiler, dela upp din app i moduler och ställa in anpassade pipelines är bara några av de uppgifter som kräver aktivt underhåll för att säkerställa en smidig utveckling.

Rätt webbapplikationsarkitektur gör det enkelt för dig att göra ändringar. Du får implementera de komponentspecifikt bästa metoderna, separera appens smärtpunkter från varandra och hålla varje funktion oberoende och löst kopplad. Dessa saker kan utföras även utan arkitektur; rätt arkitektur gör det bara så mycket enklare.

Att följa en fördefinierad arkitektur gör det även lättare för dig att utveckla dina applikationer snabbare. Rätt arkitektur i kombination med en bra versionskontrollstrategi kan göra det möjligt för dina utvecklare att arbeta parallellt med varandra och bygga funktionerna snabbare.

En arkitektur för webbapplikationer kan även framtidssäkra din applikation. När du har definierat en solid strategi för hur du ska organisera appens komponenter kan du enkelt migrera dessa komponenter till nyare teknik en efter en utan att behöva göra om hela din applikation.

Förbättrad säkerhet

De flesta webbapplikationsarkitekturer tar hänsyn till säkerheten när komponenterna struktureras. Utvecklare kan i förväg planera vilka åtgärder och metoder som ska genomföras för att förbättra appens säkerhet innan den skickas ut till användarna.

Att bygga en app för OTT-videoströmning som både erbjuder betalat och kostnadsfritt innehåll med hjälp av mikrotjänster är exempelvis mer meningsfullt eftersom mikrotjänstarkitekturen gör det möjligt att dela upp appen i företagsvänliga komponenter. Detta kan exempelvis handla om användarautentisering och strömning av kostnadsfritt eller betalt innehåll. Om din användarautentiseringsmodul någonsin går ner så kan du enkelt konfigurera din app så att den begränsar åtkomsten till modulen för betalt innehåll tills autentiseringen är igång, medan modulen för kostnadsfritt innehåll fortfarande är tillgänglig för dina användare.

I ett alternativt fall där samma app utformades som en tätt sammankopplad monolit så skulle en nedlagd autentiseringstjänst antingen innebära att applikationen läggs ner eller att betalat innehåll blir tillgängligt kostnadsfritt — något som du vill undvika till varje pris.

Hur fungerar webbapplikationsarkitektur?

Innan vi talar om hur arkitekturen för webbapplikationer fungerar så är det viktigt att förstå hur en enkel webbplats fungerar:

  1. Användaren skriver in appens webbadress i webbläsarens adressfält eller klickar på en länk.
  2. Webbläsaren söker upp webbadressen i DNS-servrarna och identifierar appens IP-adress.
  3. Webbläsaren skickar en HTTP-förfrågan till din app.
  4. Din app svarar med rätt innehåll (vanligtvis en webbsida).
  5. Webbläsaren visar webbsidan på skärmen.

Om vi djupdyker lite mer, så är det här hur en webbapplikation skulle hantera en begäran:

  1. Användaren skickar en begäran till din app via ditt användargränssnitt i frontend.
  2. Om du har inrättat ett relevant cacheminne så kontrollerar appen först om den har en giltig post som kan skickas tillbaka direkt till klienten. Om så är fallet skickas det cachelagrade innehållet tillbaka och begärandet markeras som slutfört.
  3. Om det inte finns någon cache så skickas begärandet vidare till enheten för laddningsbalansering.
  4. Laddningsbalanseraren identifierar en serverinstans som är tillgänglig för att hantera begärandet och vidarebefordrar detta.
  5. Serverinstansen bearbetar begärandet och anropar vid behov eventuella externa API:er.
  6. När resultaten har samlats på ett ställe skickar servern tillbaka svaret till enheten för laddningsbalansering.
  7. Laddningsbalanseraren returnerar svaret till API-gatewayen, som i sin tur skickar det vidare till användaren i frontend-klienten. Begärandet markeras sedan som slutfört.

Typer av webbapplikationsarkitekturer

Nu när du har en grundläggande uppfattning om vad webbapplikationsarkitekturer är så ska vi ta en detaljerad titt på några av de populära typerna av webbapplikationsarkitekturer som används på webben.

Arkitektur med en enda sida

Arkitekturen för en enkelsidid applikation (SPA) är lika enkel som namnet: hela applikationen är baserad på en enda sida. När användaren väl har öppnat din applikation så behöver han eller hon inte navigera till några andra webbsidor. Appen är tillräckligt dynamisk för att hämta och återge skärmar som uppfyller användarnas krav när de navigerar i själva appen.

SPA:er är utmärkta när det gäller att ge slutanvändare eller konsumenter en snabb och sömlös upplevelse. De saknar dock den känsla som en traditionell webbplats har, och de kan vara svåra att optimera för SEO.

Fördelar med SPA-arkitektur

Några av fördelarna med SPA-arkitektur är följande:

  • Du kan bygga väldigt interaktiva webbapplikationer.
  • SPA:er är lätta att skala upp.
  • Att optimera SPA:er för prestanda kräver inte så mycket ansträngning.

Nackdelar med SPA-arkitektur

Några av nackdelarna med SPA-arkitekturen är:

  • SPAs begränsar flexibiliteten med hyperlänkar och SEO.
  • Den första renderingen är vanligtvis långsam.
  • Navigering i appen är ibland inte så intuitiv.

Arkitektur för progressiva webbapplikationer

PWA-arkitekturen (Progressive Web Application) bygger på den enkelsidiga arkitekturen genom att ge din webbapplikation offline-funktioner. Tekniker som Capacitor och Ionic används för att bygga PWA:er som kan ge användarna en enhetlig upplevelse på olika plattformar.

I likhet med SPAs så är PWAs smidiga och sömlösa. Tack vare att de även kan installeras på användarens enheter (via service workers) så får dina användare en mer enhetlig upplevelse av din applikation.

Det kan samtidigt vara svårt att optimera sådana appar för SEO, och uppdateringar av installerade appar kan vara svåra att driva igenom.

Fördelar med PWA-arkitektur

Det finns många fördelar med PWA-arkitektur, bland annat:

  • Appar körs väldigt smidigt och erbjuder plattformsoberoende kompatibilitet.
  • Skalbarheten är enkel.
  • Offlineåtkomst och enhetsinbyggda API:er som bakgrundsarbetare och push-notiser finns tillgängliga för utvecklare.

Nackdelar med PWA-arkitektur

Några av nackdelarna med PWA-arkitektur kan vara:

  • Det finns ett begränsat stöd för länkhantering och SEO.
  • Det är mer komplicerat att skicka uppdateringar till offline-PWA: er än med inbyggda appar.
  • Det finns ett begränsat stöd för PWA: er i olika webbläsare och operativsystem.

Serversides-renderad arkitektur

Vid serversides-rendering (SSR) renderas webbsidor på frontend-sidan på en backend-server efter att de har begärts av användaren. Detta bidrar till att minska belastningen på klientenheten eftersom den får en statisk HTML-, CSS- och JS-webbplats.

SSR-appar är väldigt populära bland bloggar och e-handelswebbplatser. Detta beror på att de förenklar länkhantering och SEO. Den första renderingen för SSR-appar är dessutom ganska snabb eftersom klienten inte behöver bearbeta någon JS-kod för att rendera skärmarna.

Fördelar med SSR-arkitektur

Några av fördelarna med SSR-arkitektur anges nedan:

  • Dessa appar är bra för SEO-tunga webbplatser.
  • Den första sidladdningen är i de flesta fall nästan omedelbar.
  • Du kan para ihop den med en cachelagringstjänst för att ytterligare förbättra appens prestanda.

Nackdelar med SSR-arkitektur

Några nackdelar med SSR-arkitekturen är följande:

  • Den rekommenderas inte för komplexa eller tunga webbsidor eftersom servern kan ta tid på sig att generera sidan helt och hållet. Detta resulterar i en fördröjd första visning.
  • Den rekommenderas främst för appar som inte fokuserar så mycket på användargränssnittet och som endast är ute efter en ökad skalbarhet eller säkerhet.

Arkitektur med förrenderade tillämpningar

Arkitekturen för förrenderade tillämpningar är även känd som en arkitektur för statisk webbplatsgenerering. I den här arkitekturen så genereras appens webbsidor i förväg och lagras som HTML-, CSS- och JS-filer på servern. När en användare begär en sida så hämtas den direkt och visas för användaren. Detta gör webbappen väldigt snabb, med minimala laddningstider. Denna arkitektur ökar dock appens byggtid eftersom webbsidorna renderas under byggprocessen.

Förrenderade webbappar är bra när du vill generera statiskt innehåll som bloggar eller produktinformation som inte ändras så ofta. Du kan även använda dig av mallar för att förenkla utformningen av webbsidor. Det är dock nästan omöjligt att bygga dynamiska webbappar med den här arkitekturen. Om du vill bygga en söksida (något som https://myapp.com/search/foo+bar) så har du valt fel.

Eftersom varje möjlig rutt i appen förrenderas under byggprocessen så är det omöjligt att ha dynamiska rutter som ovan eftersom det finns oändliga möjligheter som inte kan förrenderas under byggandet (och det är inte heller meningsfullt att göra detta).

Fördelar med förrenderad arkitektur

Några av de främsta fördelarna med en förrenderad applikationsarkitektur är följande:

  • Webbsidorna genereras i en ren HTML, CSS och JS, vilket innebär att deras prestanda liknar den som finns hos de appar som byggs med vanilla JS.
  • Om du känner till din apps alla möjliga vägar så blir det väldigt enkelt med SEO.

Nackdelar med en förrenderad arkitektur

Som med alla arkitektoniska modeller så har förrendering även en del nackdelar:

  • Dynamiskt innehåll kan inte serveras med dessa appar.
  • Om man gör någon ändring i webbappen så måste man bygga om den helt och distribuera appen från grunden.

Isomorfisk applikationsarkitektur

Isomorfiska appar är en blandning av serverside-renderade appar och SPAs. Det innebär att sådana appar först renderas på servern som en vanlig serverside-renderad app. När de tas emot av klienten så kopplar appen den virtuella DOM: n för snabbare och effektivare klientbehandling. Detta förvandlar i princip appen till en enkelsidig applikation.

Isomorfism sammanför det bästa av båda världarna. Du får en supersnabb bearbetning och ett snabbt användargränssnitt på klienten tack vare SPA. Du får även en snabb första rendering och ett fullvärdigt stöd för SEO och länkning tack vare den serverbaserade renderingen.

Fördelar med isomorfisk arkitektur

Här är bara några av fördelarna med att använda en isomorfisk applikationsarkitektur:

  • Isomorfiska appar har en supersnabb första rendering och fullt stöd för SEO.
  • Dessa appar fungerar även bra på klienten eftersom de förvandlas till en SPA efter laddning.

Nackdelar med isomorfisk arkitektur

Några av nackdelarna med en isomorfisk applikationsarkitektur kan vara:

  • Att sätta upp en sådan app kräver en stor talang.
  • Valmöjligheterna av teknisk stack är begränsade när det gäller att utforma en isomorfisk app. Du får endast välja mellan en handfull (mestadels) JS-baserade bibliotek och ramverk.

Tjänsteorienterad arkitektur

Den tjänsteorienterade arkitekturen är ett av de mest populära alternativen till det traditionella monolit-sättet när det gäller byggandet av appar. I den här arkitekturen delas webbapplikationerna upp i tjänster som var och en representerar en funktionell affärsenhet. Dessa tjänster är löst kopplade till varandra och interagerar med varandra via meddelandeöverföring.

Tjänsteorienterad arkitektur skapar en stabilitet och skalbarhet åt din tekniska applikationsstack. Storleken på tjänsterna i SOA är dock inte tydligt definierad och är vanligtvis knuten till affärskomponenter, inte tekniska komponenter. Detta gör att underhållet ibland kan vara ett problem.

Fördelar med tjänsteorienterad arkitektur

De viktigaste fördelarna med tjänsteorienterad arkitektur är bland annat följande:

  • Den här arkitekturen hjälper till att bygga väldigt skalbara och tillförlitliga appar.
  • Komponenterna är återanvändbara och delas för att förbättra utvecklings- och underhållsarbetet.

Nackdelar med tjänsteorienterad arkitektur

Här är en lista över potentiella nackdelar med att använda tjänsteorienterad arkitektur:

  • SOA-appar är fortfarande inte 100 % flexibla eftersom storleken och omfattningen av varje tjänst inte är fastställd. Det kan finnas tjänster som är lika stora som företagsapplikationer och som kan vara svåra att underhålla.
  • Delning av komponenter medför beroenden mellan tjänsterna.

Arkitektur för mikrotjänster

Mikrotjänst-arkitekturen utformades för att lösa problemen med den tjänsteorienterade arkitekturen. Mikrotjänster är ännu mer modulära komponenter som förs ihop för att bygga en webbapplikation. Mikrotjänster fokuserar dock på att hålla varje komponent liten och med ett avgränsat sammanhang. Med avgränsat sammanhang menas i huvudsak att varje mikrotjänst har sin kod och sina data kopplade till varandra med minimala beroenden av andra mikrotjänster.

Arkitekturen för mikrotjänster är förmodligen den bästa arkitekturen för att bygga appar som syftar till att skala upp till tusentals och miljoner användare under en och samma dag. Varje komponent är motståndskraftig, skalbar och lätt att underhålla. Att upprätthålla DevOps-livscykeln för en mikrotjänstbaserad app kräver dock ytterligare insatser, och den passar därför kanske inte så bra för mindre användningsområden.

Fördelar med mikrotjänstarkitektur

Några av fördelarna med mikrotjänstarkitektur är följande:

  • App-komponenterna är väldigt modulära, oberoende och kan återanvändas i en större utsträckning än komponenterna i den tjänsteorienterade arkitekturen.
  • Varje komponent kan skalas oberoende av varandra för att möta varierande användartrafik.
  • Mikrotjänstbaserade appar är väldigt feltoleranta.

Nackdelar med mikrotjänstarkitektur

En nackdel med mikrotjänstarkitektur kan vara:

  • För mindre projekt kan mikrotjänstarkitekturen kräva för mycket arbete när det gäller underhåll.

Serverlös arkitektur

Den serverlösa arkitekturen är en annan het nykomling i världen av webbapplikationsarkitekturer. Den här arkitekturen fokuserar på att bryta ner din applikation till termer av de funktioner som den ska utföra. Dessa funktioner hostar sedan FaaS-plattformar (Function-as-a-Service) som funktioner som anropas när förfrågningar kommer in.

Till skillnad från de flesta andra arkitekturer på den här listan, så är applikationer som byggs med hjälp av den serverlösa arkitekturen inte igång hela tiden. De beter sig precis som funktioner skulle göra — de väntar på att bli anropade och när de blir anropade så kör de den definierade processen och returnerar ett resultat. Tack vare detta så minskar underhållskostnaderna och de är väldigt skalbara utan så mycket ansträngning. Det är dock svårt att utföra långvariga uppgifter med hjälp av sådana komponenter.

Fördelar med en serverlös arkitektur

Här är de viktigaste fördelarna med en serverlös arkitektur:

  • Serverlösa appar är väldigt lätta att skala. De kan till och med anpassa sig till den inkommande trafiken i realtid för att minska belastningen på din infrastruktur.
  • Sådana appar kan använda sig av prismodellen för serverlösa plattformar med betalning per användning för att minska infrastrukturkostnaderna.
  • Serverlösa appar är ganska enkla att bygga och distribuera eftersom allt som du behöver göra är att skriva en funktion och lägga upp den på en plattform som Firebase-funktioner, AWS Lambda osv.

Nackdelar med serverlös arkitektur

Nedan följer några av nackdelarna med serverlös arkitektur:

  • Långvariga uppgifter kan vara kostsamma att utföra på en sådan arkitektur.
  • När en funktion tar emot en begäran efter lång tid kallas det för kallstart. Kallstarter är långsamma och kan ge en dålig upplevelse för din slutanvändare.

Skikt i webbapplikationsarkitekturen

Även om webbapplikationsarkitekturerna som du såg ovan kan se ganska olika ut, så kan deras komponenter logiskt sett grupperas i bestämda lager som hjälper till att uppnå ett affärsmål.

Presentationsskikt

Presentationsskiktet omfattar allt i en webbapplikation som exponeras för slutanvändarna. Presentationsskiktet består främst av frontend-klienten. Det innehåller dock även all logik som du har skrivit i din backend för att göra din frontend dynamisk. Detta ger dig utrymme att betjäna dina användare med ett användargränssnitt som är skräddarsytt för deras profil och krav.

Tre grundläggande tekniker används för att bygga detta skikt: HTML, CSS och JavaScript. HTML lägger upp din front-end, CSS stylar den och JS ger liv åt den (dvs. styr dess beteende när användarna interagerar med den). Utöver dessa tre tekniker så kan du använda vilken typ av ram som helst för att underlätta utvecklingen. Några vanliga ramverk för frontend är Laravel, React, NextJS, Vue, GatsbyJS osv.

Affärsskikt

Affärsskiktet ansvarar för att hålla igång och hantera appens arbetslogik. Det är vanligtvis en backend-tjänst som tar emot förfrågningar från klienten och behandlar dem. Den kontrollerar vad användaren har tillgång till och bestämmer hur infrastrukturen ska utnyttjas för att betjäna användarnas förfrågningar.

I fallet med en hotellboknings-app så fungerar din klientapp som en portal där användarna kan skriva in hotellnamn och andra relevanta uppgifter. Men så snart användaren klickar på sökknappen tar affärsskiktet emot begärandet och startar logiken för att leta efter tillgängliga hotellrum som matchar användarens krav. Klienten får då endast en lista över hotellrum utan att veta hur denna lista har genererats eller ens varför listelementen är ordnade som de är.

Förekomsten av ett sådant skikt säkerställer att din affärslogik inte exponeras för din klient och i slutändan för användarna. Att isolera affärslogiken är till stor hjälp vid känslig verksamhet som hantering av betalningar eller hantering av hälsoregister.

Beständighetsskikt

Beständighetsskiktet ansvarar för att kontrollera åtkomsten till dina dataskikt. Det fungerar som ett extra abstraktionsskikt mellan datalagren och affärslagret. Det tar emot alla datarelaterade anrop från affärsskikten och bearbetar dem genom att göra säkra anslutningar till databasen.

Det här skiktet består vanligtvis av en databasserver. Du kan själv ställa in det här skiktet genom att tillhandahålla en databas och en databasserver i din lokala infrastruktur eller välja en fjärrstyrd/hanteradlösning från en av de ledande leverantörerna av molninfrastruktur som AWS, GCP, Microsoft Azure osv.

Komponenter för webbapplikationer

Nu när du förstår vad som ingår i en webbapplikationsarkitektur så ska vi ta en detaljerad titt på varje komponent som ingår i en webbapplikation. Vi kommer att gruppera den här diskussionen i två huvudrubriker — komponenter på serversidan och komponenter på klientsidan, eller backend- och frontend-komponenter.

Serverbaserade komponenter

Komponenter på serversidan är de komponenter som finns på din webbapplikations backend. Dessa är inte direkt exponerade för användarna och innehåller den viktigaste affärslogiken och de mest kritiska resurserna för din webbapplikation.

DNS och routning

DNS ansvarar för att kontrollera hur din app exponeras för webben. DNS-poster används av HTTP-klienter, vilket även kan vara en webbläsare, för att hitta och skicka förfrågningar till appens komponenter. DNS används även internt av dina frontend-klienter för att fastställa var dina webbservrar och API-slutpunkter befinner sig för att skicka förfrågningar och bearbeta användaroperationer.

Laddningsutjämning är en annan populär komponent i arkitekturen för webbapplikationer. En laddningsbalanserare används för att fördela HTTP-förfrågningar mellan flera identiska webbservrar. Syftet med att ha flera webbservrar är att upprätthålla en redundans som bidrar till att öka feltoleransen samt att fördela trafiken för att upprätthålla en hög prestanda.

API-slutpunkter används för att exponera backend-tjänster för frontend-applikationen. Dessa hjälper till att underlätta kommunikationen mellan klienten och servern, och ibland även mellan flera servrar.

Datalagring

Datalagring är en viktig del av de flesta moderna tillämpningar eftersom det alltid finns en viss applikationsdata som måste bevaras över användarsessioner. Det finns två typer av datalagring:

  • Databaser: Databaser används för att lagra data för snabb åtkomst. De stödjer vanligtvis lagring av en liten mängd data som regelbundet nås av applikationen.
  • Datalager: Datalager är avsedda för bevarande av historiska data. Dessa behövs vanligtvis inte särskilt ofta i appen men bearbetas regelbundet för att generera affärsinsikter.

Cachelagring

Cachelagring är en valfri funktion som ofta implementeras i webbapplikationsarkitekturer för att snabbare servera innehåll till användarna. En stor del av appens innehåll är ofta repetitivt under en viss tid, om inte alltid. Istället för att få tillgång till innehållet från ett dataskikt och behandla det innan det skickas tillbaka till användaren, cachelagras det ofta. Här är de två mest populära typerna av cachelagring som används i webbapplikationer:

  • Datacachelagring: Datacachelagring introducerar ett sätt för din app att enkelt och snabbt få tillgång till data som används ofta och som inte ändras frekvent. Tekniker som Redis och Memcache gör det möjligt att cachelagra data för att spara in på dyra databasförfrågningar som bara hämtar samma data om och om igen.
  • Cachelagring av webbsidor: Ett CDN (Content Delivery Network) lagrar webbsidor på samma sätt som Redis lagrar data. Av samma skäl som det rekommenderas att data som inte ändras så ofta cachelagras, rekommenderas det vanligtvis att man cachelagrar statiska webbsidor. För serverside-renderade webbapplikationer är cachelagring inte särskilt bra eftersom deras innehåll förväntas att vara väldigt dynamiskt.

Jobs och tjänster

Förutom exponering av ett gränssnitt för användarna (frontend) och hantering av deras förfrågningar (backend) så finns det en annan något mindre populär kategori av webbapplikationskomponenter. Jobs är ofta bakgrundstjänster som är avsedda att utföra uppgifter som inte är tidskänsliga eller synkrona.

CRON-jobs är tjänster som körs under en fast tidsperiod om och om igen. Dessa jobs schemaläggs i backend för att köra underhållsrutiner automatiskt vid bestämda tidpunkter. Några vanliga exempel på användningsområden för dessa är radering av dubbletter/gamla poster från databasen, utskick av påminnelsemejl till kunder osv.

Komponenter på klientsidan

Komponenter på klientsidan är de komponenter som antingen direkt eller indirekt exponeras för användarna.

Det finns huvudsakligen två typer av komponenter i denna kategori.

Frontend-användargränssnitt

Användargränssnittet är den visuella aspekten av din applikation. Det är det som användarna ser och interagerar med för att få tillgång till dina tjänster.

Frontend-gränssnittet byggs oftast på tre populära tekniker: HTML, CSS och JavaScript. Frontend-användargränssnittet kan vara en applikation i sig självt med en egen livscykel för programvaruutvecklingen.

Dessa användargränssnitt rymmer inte så mycket av din affärslogik eftersom de exponeras direkt för dina användare. Om en illasinnad användare försöker göra en ”reverse engineer” av din frontend-applikation så kan han eller hon få information om hur din verksamhet fungerar och utföra olagliga aktiviteter som varumärkesimitation och datastöld.

Eftersom frontend-användargränssnittet exponeras direkt för användarna saå bör du optimera det för minimal laddningstid och responsivitet. Ibland kan detta hjälpa dig att ge dina användare en bättre upplevelse och därmed öka din företagstillväxt.

Affärslogik på klientsidan

Ibland så kan du behöva lagra viss affärslogik på din klient för att snabbt kunna utföra enklare operationer. Logik på klientsidan som vanligtvis finns i din frontend-applikation kan hjälpa dig att hoppa över resan till servern och ge dina användare en snabbare upplevelse.

Detta är en valfri funktion för klientsideskomponenterna. I vissa fall så lagras appens affärslogik helt och hållet på klientsidan (särskilt när man bygger utan en traditionell backend-server). Moderna lösningar som BaaS hjälper dig att få tillgång till vanliga operationer som autentisering, datalagring, fillagring osv. på språng i din frontend-app.

Det finns sätt att fördunkla eller förminska denna kod innan den skickas ut till dina användare för att minimera risken för ”reverse-engineering”.

Modeller av webbapplikationskomponenter

Det finns flera olika modeller för arkitekturer för webbapplikationer, var och en baserad på hur webbservrar ansluter till sina datalager.

En server, en databas

Den enklaste modellen är en webbserver som ansluter till en databasinstans. En sådan modell är lätt att implementera och underhålla, och den är även ganska enkel att sätta i produktion.

Tack vare sin enkelhet så lämpar sig denna modell för inlärning och för små experimentella tillämpningar som inte kommer att utsättas för så stor trafik. Nybörjarutvecklare kan enkelt sätta upp och pyssla med dessa appar för att lära sig grunderna i utveckling av webbapplikationer.

Den här modellen bör dock inte användas i produktion eftersom den är väldigt opålitlig. Ett problem i antingen servern eller databasen kan leda till driftstopp och förlorad verksamhet.

Flera servrar, en databas

Den här modellen tar applikationen ett steg uppåt genom att sätta upp flera servrar för redundans med en enda gemensam databasinstans.

Eftersom flera webbservrar har tillgång till databasen samtidigt så kan det uppstå problem med inkonsekvens. För att undvika detta så är webbservrarna utformade för att vara tillståndslösa. Detta innebär att servrarna inte behåller data mellan sessioner, utan endast bearbetar dem och lagrar dem i databasen.

Appar som görs med den här modellen är definitivt mer tillförlitliga än de som görs med den tidigare modellen, eftersom förekomsten av flera webbservrar ökar webbapplikationens feltolerans. Eftersom databasen fortfarande är en gemensam instans så är den dock den svagaste länken i arkitekturen och kan vara en källa till fel.

Flera servrar, flera databaser

Denna modell är en av de vanligaste, traditionella modellerna för utformning av webbapplikationer.

I det här fallet så distribuerar du din programlogik som flera identiska webbserverinstanser som är sammanfogade bakom en laddningsbalanserare. Ditt datalager upprätthålls även i flera databasinstanser för att öka feltoleransen.

Du kan även välja att dela upp din databas mellan de tillgängliga instanserna för att förbättra prestandan eller att behålla dubbletter av hela datalagret för redundans. I båda fallen så leder fel i en instans av din databas inte till att hela applikationen stängs av.

Den här modellen är väldigt uppskattad för sin tillförlitlighet och skalbarhet. Det är dock relativt komplicerat att utveckla och underhålla appar som använder den här modellen och det kräver kostsamma, erfarna utvecklare. Av den anledningen så föreslås den här modellen endast när du bygger i stor skala.

App-tjänster

De tre modellerna som nämns ovan är väl lämpade för monolitiska applikationer, men det finns ytterligare en modell för modulära applikationer.

Applikationstjänstmodellen bryter ner en applikation i mindre moduler baserat på affärsfunktionalitet. Dessa moduler kan vara så små som en funktion eller så stora som en tjänst.

Tanken här är att göra varje affärsfunktion oberoende och skalbar. Var och en av dessa moduler kan ansluta till databasen på egen hand. Du kan till och med ha dedikerade databasinstanser för att matcha modulens skalbarhetsbehov.

Bland icke-monolitiska appar så är den här modellen ganska populär. Gamla monoliter migreras ofta till den här modellen för att utnyttja dess skalbarhet och modularitet. För att hantera appar som är byggda på en sådan modell krävs dock ofta erfarna utvecklare särskilt dem som har erfarenhet av DevOps och CI/CD.

Bästa praxis för webbapplikationsarkitekturer

Här är några bra metoder som du kan implementera i ditt webbapplikationsprojekt för att få ut så mycket som möjligt av den valda webbapplikationsarkitekturen.

1. Gör din Frontend responsiv

Detta kan inte nog betonas: Sträva alltid efter responsiva frontend. Oavsett hur stor och komplex din webbapplikation är internt så exponeras allt för dina användare via webbsidor, appar och skärmar i frontend.

Om användarna tycker att skärmarna inte är så intuitiva eller att de är långsamma kså ommer de inte att stanna kvar tillräckligt länge för att se och beundra det tekniska underverk som din webbapplikation är.

Det är därför mycket viktigt att utforma lättillgängliga och lättviktiga frontends.

Det finns gott om bästa praxis för UI/UX på webben för att hjälpa dig att förstå vad som fungerar bäst för dina användare. Du kan hitta yrkesverksamma som är skickliga på att skapa användarvänlig design och arkitektur som gör att dina användare kan få ut så mycket som möjligt av dina appar.

Vi rekommenderar att du tänker igenom hur din frontend reagerar innan du skickar ut din produkt till dina användare.

2. Övervaka laddningstiderna

Förutom att de ska vara enkla att förstå så måste dina frontends även vara snabba att ladda.

Enligt Portent så är det sidor med laddningstider på mellan 0 och 2 sekunder som har den högsta konverteringsfrekvensen för e-handel. Enligt Unbounce så erkänner cirka 70 % av konsumenterna att laddningstiden för sidor är en viktig faktor när de väljer att handla från en onlineförsäljare.

När du utformar mobilanpassade applikationer så kan du vanligtvis inte vara säker på användarnas enhetsspecifikationer. En enhet som inte uppfyller appens krav får vanligtvis ett meddelande om att den inte stödjer appen.

Det fungerar dock helt annorlunda med webben.

När det gäller webbapplikationer så kan dina användare använda allt från den senaste Apple Macbook M1 Pros till gamla Blackberry- och Nokia-telefoner för att se din app. Det kan ibland vara svårt att optimera din frontend-upplevelse för ett så stort antal användare.

Tjänster som LightHouse och Google PageSpeed är perfekta när man vill ta reda på prestandan för frontend. Du bör använda sådana verktyg för att jämföra din frontend-app innan du distribuerar den i produktion. De flesta sådana verktyg ger dig en lista med tips som kan användas för att förbättra appens prestanda så mycket som möjligt.

De sista 5-10 % av appens prestanda är vanligtvis specifika för ditt användningsområde och kan endast åtgärdas av någon som känner din app och dess teknik väl. Det skadar aldrig att investera i webbprestanda!

3. Välj PWA närhelst som det är möjligt

Som vi har diskuterat tidigare så är PWA: er framtidens design. De kan passa de flesta användningsområden bra och ger den mest enhetliga upplevelsen på alla större plattformar.

Du bör överväga att använda PWA för din app så ofta som möjligt. Den inbyggda upplevelsen över webb och mobil är enormt betydelsefull för dina användare och kan dessutom minska en hel del av din egen arbetsbörda.

PWA: er är även snabba att ladda, lätta att optimera och snabba att bygga. Att välja PWA: er kan hjälpa dig att i ett tidigt skede flytta mycket av ditt fokus från utveckling till affärsverksamhet.

4. Håll din kodbas ren och kortfattad

En ren kodbas kan hjälpa dig att upptäcka och lösa de flesta problem innan de orsakar skada. Här är några tips som du kan följa för att se till att din kodbas inte orsakar dig mer problem än vad den borde.

  • Fokusera på återanvändning av kod: Att behålla kopior av samma kod i hela kodbasen är inte bara överflödigt, utan kan även leda till att avvikelser smyger sig in, vilket gör kodbasen svår att underhålla. Fokusera alltid på att återanvända kod när det är möjligt.
  • Planera din projektstruktur: Programvaruprojekt kan bli väldigt stora med tiden. Om du inte börjar med en planerad struktur för kodorganiseringen och resurserna så kan det sluta med att du ägnar mer tid åt att hitta filer än åt att skriva en användbar kod.
  • Skriv enhetstester: Det finns en risk att varje bit av kod går sönder. Att testa allt manuellt är inte genomförbart, så du behöver en fast strategi för att automatisera tester för din kodbas. Testkörare och kodtäckningsverktyg kan hjälpa dig att identifiera om dina enhetstester ger önskat resultat.
  • Hög modularitet: När du skriver kod så ska du alltid fokusera på modularitet. Att skriva kod som är tätt kopplad till andra kodstycken gör den svår att testa, återanvända och ändra vid behov.

5. Automatisera dina CI/CD-processer

CI/CD står för Continuous Integration/Continuous Deployment. CI/CD-processer är avgörande för utvecklingen av din applikation eftersom de hjälper dig att enkelt bygga, testa och distribuera ditt projekt.

Du bör dock inte köra dem manuellt varje gång. Du bör istället sätta upp pipelines som triggas automatiskt baserat på projektets aktiviteter. Du kan exempelvis sätta upp en pipeline som kör dina tester automatiskt när du lägger in din kod i ditt versionskontrollsystem. Det finns många mer komplexa användningsområden, exempelvis generering av plattformsoberoende artefakter från ditt kodförråd när en utgåva skapas.

Möjligheterna är oändliga, så det är upp till dig att ta reda på hur du kan få ut så mycket som möjligt av dina CI/CD-pipelines.

6. Införliva säkerhetsfunktioner

De flesta moderna appar består av flera komponenter. Ta följande app som exempel:

Exempel på en serverlös webbapparkitektur.
Exempel på en serverlös webbapparkitektur.

Klientförfrågningar skickas till appen via en API-gateway. Denna tillåter för närvarande endast direkta förfrågningar till appens hemmodul, men i framtiden kan den ge tillgång till fler komponenter utan att gå via hemmodulen.

Nästa steg är att hemmodulen kontrollerar en extern autentiserings-Baas innan den tillåter åtkomst. När klienten har autentiserats så kan den få tillgång till sidorna ”Uppdatera profil” eller ”Visa profil”. Båda dessa sidor interagerar med en gemensam, hanterad databaslösning som hanterar profildata.

Som du kan se så verkar applikationen vara en mycket grundläggande och minimal version av en personkatalog på nätet. Du kan lägga till/uppdatera din egen profil eller visa andra tillgängliga profiler.

Här är en snabb titt på de olika komponenterna i arkitekturen:

  • Blå rutor: Appmoduler, som eventuellt hostar mikrotjänster eller serverlösa funktioner.
  • Röda rutor: Externa BaaS-komponenter som tillhandahåller autentisering och databas.
  • Grön ruta: Routingkomponent som modererar inkommande förfrågningar från klienten.
  • Svart ruta: Din klientapplikation som exponeras för användaren.

Komponenterna i var och en av färgerna ovan är sårbara för olika typer av säkerhetshot. Här är några säkerhetskonstruktioner som du kan införa för att minimera din exponering:

    • Appmoduler (blåa): Eftersom det här är serverlösa funktioner så finns det några sätt att stärka deras säkerhet:
      • Isolera appens hemligheter och hantera dem oberoende av din källkod
      • Behåll åtkomstkontroller med hjälp av IAM-tjänster
      • Förbättra dina testningsinsatser så att du även letar efter säkerhetshot med hjälp av tekniker som SAST
    • Externa tjänster (röda):
      • Sätt upp åtkomstkontroller genom deras IAM-moduler för att reglera åtkomsten
      • Välj API-hastighetsbegränsning
      • För tjänster som databaser, ställ in finare kontrollbehörigheter, exempelvis vem som kan få tillgång till profildata, vem som kan se användardata med mera. Många tjänster, som Firebase, tillhandahåller en detaljerad uppsättning av sådana regler.
    • Ruttkomponent (gröna):
      • Liksom alla andra komponenter, implementera åtkomstkontroller
      • Inrätta auktorisering
      • Dubbelkontrollera de bästa standardmetoderna som CORS
    • Klient:
      • Se till att inga apphemligheter är tillgängliga för din klient
      • Förvräng din klientkod för att minimera risken för ”reverse engineering”

Även om det här bara är en handfull förslag, så visar de att app-säkerhet är komplicerat och att det är ditt ansvar att se till att du inte lämnar några lösa trådar som angriparna kan få tag i. Du kan inte förlita dig på en central säkerhetskomponent för att skydda ditt företag, utan app-säkerheten är fördelad över hela app-arkitekturen.

7. Samla in användarfeedback

Användarfeedback är ett viktigt verktyg för att förstå hur väl din app fungerar när det gäller affärsmässig och teknisk prestanda. Du kan bygga den lättaste och smidigaste appen i världen, men om den inte låter dina användare göra det som de förväntar sig går alla dina ansträngningar om intet.

Det finns flera sätt att samla in användarfeedback. Medan en snabb och anonymiserad enkät är det konventionella tillvägagångssättet så kan du även välja en mer sofistikerad lösning. Det kan exempelvis vara en värmekarta över dina användares aktivitet.

Valet av metod för insamling av feedback är mindre viktigt än att vidta åtgärder på den insamlade feedbacken. Kunderna älskar företag som lyssnar på deras problem. Jättar som McDonald’s och Tesla gör det, och det är en av anledningarna till att de fortsätter att lyckas på sina marknader.

Sammanfattning

Webben är en enorm lekplats med en mängd olika tillämpningar som alla är utformade på sitt eget unika sätt. Flera olika typer av arkitekturer gör det möjligt för webbapplikationer att diversifieras, blomstra och erbjuda tjänster till användare över hela världen.

I den här guiden så har vi delat upp de olika modellerna för webbapplikationsarkitektur och visat hur avgörande de är för en applikations tillväxt.

Finns det en webbapplikationsarkitektur som du verkligen älskade? Eller finns det en annan som du skulle vilja dela med dig av till världen? Låt oss veta detta i kommentarerna nedan!

Kumar Harsh

Kumar är en mjukvaruutvecklare och en teknisk författare som är baserad i Indien. Han är specialiserad på JavaScript och DevOps. Du kan lära dig mer om hans arbete på hans hemsida.