Che cos'è l'architettura dell'applicazione Web? Scomporre un'app Web

Il mondo si è spostato su Internet e le applicazioni web sono diventate i nuovi luoghi di lavoro e negozi commerciali. Per soddisfare la varietà di scopi che servono le moderne app Web, ognuna di esse deve essere progettata per prestazioni elevate e personalizzazione.

Le architetture delle applicazioni Web risolvono questo problema.
Vuoi saperne di più sull'architettura delle applicazioni web? Sei nel posto giusto Clicca per twittare
L'architettura dell'applicazione Web definisce come sono strutturati i vari componenti di un'applicazione basata sul Web. Questa architettura è altamente specifica per la natura e lo scopo dell'applicazione web. La scelta dell'architettura sbagliata per la tua app Web può devastare la tua attività.

In questa guida, analizzeremo il concetto di architettura dell'applicazione Web e capiremo come influisce sull'esperienza dell'utente finale della tua applicazione. Verso la fine, esamineremo anche alcune delle migliori pratiche che puoi implementare per ottenere il massimo dalla tua applicazione web.

Che cos'è l'architettura dell'applicazione Web?

Per dare il via alla discussione, iniziamo con la definizione dell'architettura dell'applicazione web.

In parole semplici, l'architettura dell'applicazione Web è uno schema di come i vari componenti dell'app Web interagiscono tra loro.

Può essere semplice come definire la relazione tra il client e il server. Può anche essere complesso come definire le interrelazioni tra uno sciame di server back-end containerizzati, bilanciatori del carico, gateway API e front-end a pagina singola rivolti agli utenti.

Detto questo, raramente si tratta di scegliere il linguaggio di programmazione in cui scriverai il tuo codice.

Il modo in cui progetti la tua app web gioca un ruolo chiave sia nella sua usabilità che nell'ottimizzazione dei costi. Ecco come appare su carta un'architettura di un'app Web di esempio:

Perché l'architettura dell'applicazione Web è importante?

L'architettura delle applicazioni Web è, senza dubbio, una delle parti più importanti della tua applicazione Web. Se scegli di sviluppare la tua app Web pensando a un'architettura specifica, sarai certo di ricevere molti vantaggi quando si tratta di mantenere e far crescere la tua applicazione.

Tuttavia, la scelta dell'architettura giusta amplifica ulteriormente questi vantaggi.

Ecco alcuni dei principali motivi per cui dovresti prendere seriamente in considerazione l'adozione di un'architettura per applicazioni web.

Adattarsi facilmente alle esigenze aziendali

La tua app è un gateway chiave per la tua attività e le esigenze aziendali si evolvono con il mercato in evoluzione. Per tenere il passo, vorrai che la tua app sia sufficientemente flessibile da adattarsi alle mutevoli esigenze aziendali. E se crei un'app senza considerare la flessibilità integrata, sei destinato a dedicare una quantità crescente di tempo e sforzi a piccoli aggiustamenti nella tua app su tutta la linea.

La giusta architettura dell'applicazione Web tiene già conto di alcune delle modifiche di cui la tua azienda potrebbe aver bisogno in futuro. Ad esempio, se sai che stai creando un'applicazione di e-commerce in grado di scalare e soddisfare un'ampia gamma di servizi per un gran numero di clienti un giorno, la scelta di un'architettura di microservizi rispetto a una monolitica ti offrirebbe maggiore flessibilità.

D'altra parte, se stai creando un'app interna per la tua azienda con solo uno o due requisiti fissi, puoi optare per un monolite più semplice per accelerare lo sviluppo e mantenere pulita la tua base di codice.

Sviluppo organizzato

Come accennato in precedenza, la giusta architettura dell'app Web fornisce una tabella di marcia più conveniente per lo sviluppo. L'architettura fornisce una modularità sufficiente nel tuo sistema per isolare i componenti secondo necessità e hai la libertà di scegliere la struttura del progetto giusta per ciascuno dei tuoi moduli e componenti, se necessario.

Se ti immergi nello sviluppo di app senza un'architettura in mente, rischi di sprecare tempo e denaro per riorganizzare i tuoi componenti e stabilire nuove regole per facilitare la collaborazione tra i membri del tuo team, tempo e denaro che altrimenti avrebbero potuto essere spesi altrove.

Migliore gestione della base di codici

Oltre a scrivere il codice della tua app, trascorrerai anche molto tempo a gestirla. L'organizzazione dei file di progetto, la suddivisione dell'app in moduli e l'impostazione di pipeline personalizzate sono solo alcune delle attività che richiedono una manutenzione attiva per garantire uno sviluppo regolare.

La giusta architettura dell'app Web ti consente di apportare modifiche facilmente. Puoi implementare best practice specifiche per i componenti, separare i punti deboli della tua app l'uno dall'altro e mantenere ogni funzionalità indipendente e liberamente accoppiata. Non è che queste cose non si possano fare senza l'architettura; è solo che la giusta architettura rende tutto molto più semplice.

Seguire un'architettura predefinita semplifica anche lo sviluppo delle applicazioni più velocemente. La giusta architettura combinata con una strategia di controllo della versione audio può consentire ai tuoi sviluppatori di lavorare in parallelo tra loro e creare funzionalità più velocemente.

Un'architettura per app Web rende la tua applicazione a prova di futuro. Dopo aver definito una solida strategia su come organizzare i componenti della tua app, puoi facilmente migrare questi componenti alle nuove tecnologie uno per uno senza dover ripetere l'intera applicazione.

Sicurezza avanzata

La maggior parte delle architetture di app Web tiene conto della sicurezza durante la strutturazione dei componenti. Gli sviluppatori possono pianificare, in anticipo, le misure e le pratiche da implementare per migliorare la sicurezza dell'app prima che venga distribuita agli utenti.

Ad esempio, la creazione di un'app di streaming video OTT che offra contenuti sia a pagamento che gratuiti utilizzando i microservizi ha più senso in quanto l'architettura dei microservizi consente di suddividere l'app in componenti business-friendly, come l'autenticazione dell'utente e lo streaming di contenuti gratuito o a pagamento. Se il tuo modulo di autenticazione utente si interrompe, puoi configurare facilmente la tua app per limitare l'accesso al modulo di contenuto a pagamento fino a quando l'autenticazione non è attiva mentre il modulo di contenuto gratuito è ancora disponibile per i tuoi utenti.

In un caso alternativo in cui questa stessa app è stata progettata come un monolite strettamente accoppiato, un servizio di autenticazione disattivato significherebbe che un'applicazione bloccata o un contenuto a pagamento reso disponibile gratuitamente, risultati che vorrai evitare a tutti i costi.

Come funziona l'architettura delle applicazioni Web?

Prima di parlare di come funziona l'architettura delle applicazioni web, è importante capire come funziona un semplice sito web:

1. L'utente inserisce l'URL dell'app nella barra degli indirizzi del browser o fa clic su un collegamento.
2. Il browser cerca l'URL nei server DNS e identifica l'indirizzo IP della tua app.
3. Il browser invia una richiesta HTTP alla tua app.
4. La tua app risponde con il contenuto corretto (di solito una pagina web).
5. Il browser esegue il rendering della pagina Web sullo schermo.

Se dovessi immergerti un po' più a fondo, ecco come un'app web gestirebbe una richiesta:

1. L'utente invia una richiesta alla tua app tramite l'interfaccia utente frontend.
2. Se hai impostato una cache pertinente, l'app la verificherà prima per vedere se ha un record valido che può essere rispedito direttamente al client. In caso affermativo, il contenuto memorizzato nella cache verrà rispedito e la richiesta verrà contrassegnata come completata.
3. Se non è presente la cache, la richiesta viene inoltrata al servizio di bilanciamento del carico.
4. Il servizio di bilanciamento del carico identifica un'istanza del server disponibile per gestire la richiesta e la inoltra.
5. L'istanza del server elabora la richiesta e chiama eventuali API esterne, se necessario.
6. Una volta che i risultati sono stati raccolti in un'unica posizione, il server restituisce la risposta al sistema di bilanciamento del carico.
7. Il sistema di bilanciamento del carico restituisce la risposta al gateway API, che a sua volta la invia all'utente nel client frontend. La richiesta viene quindi contrassegnata come completata.

Tipi di architettura di applicazioni Web

Ora che hai un'idea di base di cosa sia l'architettura dell'applicazione Web, diamo uno sguardo dettagliato ad alcuni dei tipi più diffusi di architettura dell'applicazione Web utilizzati nel Web.

Architettura a pagina singola

L'architettura per un'applicazione a pagina singola (SPA) è semplice come il suo nome: l'intera applicazione si basa su una singola pagina. Una volta che l'utente ha richiamato l'app, non è necessario che acceda ad altre pagine Web. L'app è resa sufficientemente dinamica da recuperare e visualizzare schermate che soddisfano i requisiti degli utenti mentre navigano nell'app stessa.

Le SPA sono ottime quando si tratta di fornire un'esperienza rapida e senza interruzioni agli utenti finali o ai consumatori. Tuttavia, mancano del tocco di un sito Web tradizionale e possono essere difficili da ottimizzare per la SEO.

I vantaggi dell'architettura SPA

Alcuni dei vantaggi dell'architettura SPA includono:

• Puoi creare app Web altamente interattive.
• Le SPA sono facili da scalare.
• L'ottimizzazione delle SPA per le prestazioni non richiede molto sforzo.

Contro di SPA Architecture

Alcuni degli svantaggi dell'architettura SPA sono:

• Le SPA limitano la flessibilità con collegamenti ipertestuali e SEO.
• Il rendering iniziale è generalmente lento.
• La navigazione attraverso l'app può non essere intuitiva.

Architettura dell'applicazione Web progressiva

L'architettura dell'applicazione Web progressiva (PWA) si basa sull'architettura a pagina singola fornendo funzionalità offline per la tua app Web. Tecnologie come Capacitor e Ionic vengono utilizzate per creare PWA in grado di fornire agli utenti un'esperienza uniforme su tutte le piattaforme.

Simile alle SPA, le PWA sono fluide e senza interruzioni. Con la possibilità aggiuntiva di essere installato sui dispositivi degli utenti (tramite i service worker), i tuoi utenti ottengono un'esperienza più uniforme con la tua applicazione.

Allo stesso tempo, può essere difficile ottimizzare tali app per la SEO e gli aggiornamenti sulle app installate possono essere difficili da inviare.

Pro dell'architettura PWA

Ci sono molti vantaggi dell'architettura PWA, tra cui:

• Le app funzionano in modo molto fluido e offrono compatibilità multipiattaforma.
• La scalabilità è semplice.
• L'accesso offline e le API native del dispositivo come i lavoratori in background e le notifiche push sono accessibili agli sviluppatori.

Contro dell'architettura PWA

Alcuni dei contro dell'architettura PWA possono includere:

• Il supporto per la gestione dei link e la SEO è limitato.
• L'invio degli aggiornamenti alle PWA offline è più complesso rispetto alle app native.
• Il supporto per le PWA è limitato nei browser Web e nei sistemi operativi.

Architettura con rendering lato server

Nel rendering lato server (SSR), le pagine Web front-end vengono visualizzate su un server back-end dopo che sono state richieste dall'utente. Ciò aiuta a ridurre il carico sul dispositivo client poiché riceve una pagina Web statica HTML, CSS e JS.

Le app SSR sono molto popolari tra i blog e i siti di e-commerce. Questo perché rendono abbastanza semplici la gestione dei link e la SEO. Inoltre, il primo rendering per le app SSR è abbastanza veloce poiché al client non è richiesto di elaborare alcun codice JS per eseguire il rendering delle schermate.

Pro dell'architettura SSR

Alcuni dei vantaggi dell'architettura SSR sono elencati di seguito:

• Queste app sono ottime per i siti web ad alto contenuto di SEO.
• Il caricamento della prima pagina è quasi istantaneo nella maggior parte dei casi.
• Puoi associarlo a un servizio di memorizzazione nella cache per migliorare ulteriormente le prestazioni della tua app.

Contro dell'architettura SSR

Alcuni svantaggi dell'utilizzo dell'architettura SSR includono:

• Non è consigliato per pagine Web complesse o pesanti poiché il server può richiedere tempo per generare completamente la pagina con conseguente ritardo del primo rendering.
• È consigliato principalmente per le app che non si concentrano molto sull'interfaccia utente e cercano solo una maggiore scalabilità o sicurezza.

Architettura delle applicazioni pre-renderizzate

L'architettura delle applicazioni prerenderizzate è anche nota come architettura di generazione di siti statici. In questa architettura, le pagine Web front-end dell'app sono pregenerate e archiviate come semplici file HTML, CSS e JS sul server. Una volta che un utente richiede una pagina, questa viene direttamente recuperata e mostrata a loro. Ciò rende l'app web molto veloce, con tempi di caricamento minimi di qualsiasi tipo. Tuttavia, questa architettura aumenta il tempo di compilazione dell'app poiché le pagine Web vengono visualizzate durante il processo di compilazione.

Le app Web pre-renderizzate sono ottime per quando stai cercando di generare contenuti statici come blog o dettagli di prodotto che non cambiano spesso. Puoi anche utilizzare modelli per semplificare la progettazione della tua pagina web. Tuttavia, è quasi impossibile creare app Web dinamiche con questa architettura. Se stai cercando di creare una pagina di ricerca che tenga la query nel suo percorso (qualcosa come https://myapp.com/search/foo+bar ), sei nel posto sbagliato.

Poiché ogni possibile percorso dell'app viene pre-renderizzato durante il processo di compilazione, è impossibile avere percorsi dinamici come sopra poiché ci sono infinite possibilità che non possono essere pre-renderizzate durante la compilazione (e non ha senso farlo così anche).

Pro dell'architettura pre-renderizzata

Alcuni dei principali vantaggi dell'architettura delle applicazioni pre-renderizzate sono:

• Le pagine Web sono generate in puro HTML, CSS e JS; quindi le loro prestazioni sono simili a quelle delle app create utilizzando JS vaniglia.
• Se conosci tutti i percorsi possibili della tua app, la SEO diventa semplicissima.

Contro dell'architettura pre-renderizzata

Come con qualsiasi modello architettonico, il prerendering ha la sua parte di inconvenienti:

• Il contenuto dinamico non può essere servito con queste app.
• Apportare qualsiasi modifica all'app Web significa ricostruire e distribuire completamente l'app da zero.

Architettura dell'applicazione isomorfa

Le app isomorfiche sono quelle che sono una combinazione di app e SPA con rendering lato server. Ciò significa che tali app vengono prima visualizzate sul server come una normale app con rendering lato server. Una volta ricevuti dal client, l'app si idrata e collega il DOM virtuale per un'elaborazione del client più rapida ed efficiente. Questo essenzialmente trasforma l'app in un'applicazione a pagina singola.

Isomorphic unisce il meglio di entrambi i mondi. Ottieni un'elaborazione e un'interfaccia utente super veloci sul client, grazie alla SPA. Ottieni anche un rapido rendering iniziale e un completo supporto SEO e collegamento, grazie al rendering lato server.

Pro dell'architettura isomorfa

Ecco solo alcuni dei vantaggi dell'utilizzo dell'architettura dell'applicazione isomorfa:

• Le app isomorfiche hanno un rendering iniziale super veloce e un supporto completo per la SEO.
• Queste app funzionano bene anche sul client poiché si trasformano in una SPA dopo il caricamento.

Contro dell'architettura isomorfa

Alcuni dei contro dell'architettura dell'applicazione isomorfa possono essere:

• La configurazione di un'app del genere richiede talento qualificato.
• Le opzioni dello stack tecnologico sono limitate quando si tratta di progettare un'app isomorfa. Puoi scegliere solo tra una manciata di librerie e framework (per lo più) basati su JS.

Architettura orientata ai servizi

L'architettura orientata ai servizi è tra le alternative più popolari al tradizionale modo monolitico di creare app. In questa architettura, le web app sono scomposte in servizi che rappresentano ciascuna un'unità funzionale di business. Questi servizi sono liberamente accoppiati e interagiscono tra loro tramite il passaggio di messaggi.

L'architettura orientata ai servizi aggiunge stabilità e scalabilità allo stack tecnologico dell'applicazione. Tuttavia, la dimensione dei servizi in SOA non è chiaramente definita e di solito è legata a componenti aziendali, non a componenti tecniche; quindi la manutenzione a volte può essere un problema.

Vantaggi dell'architettura orientata ai servizi

I principali vantaggi dell'architettura orientata ai servizi includono:

• Questa architettura aiuta a creare app altamente scalabili e affidabili.
• I componenti sono riutilizzabili e condivisi per migliorare gli sforzi di sviluppo e manutenzione.

Contro dell'architettura orientata ai servizi

Ecco un elenco di potenziali svantaggi dell'utilizzo dell'architettura orientata ai servizi:

• Le app SOA non sono ancora flessibili al 100% poiché le dimensioni e l'ambito di ciascun servizio non sono fisse. Possono essere presenti servizi delle dimensioni di applicazioni aziendali che possono essere difficili da mantenere.
• La condivisione dei componenti introduce le dipendenze tra i servizi.

Architettura dei microservizi

L'architettura dei microservizi è stata progettata per risolvere i problemi con l'architettura orientata ai servizi. I microservizi sono componenti ancora più modulari che si integrano per creare un'app Web. Tuttavia, i microservizi si concentrano sul mantenere ogni componente piccolo e con un contesto limitato. Il contesto limitato significa essenzialmente che ogni microservizio ha il proprio codice e dati accoppiati con dipendenze minime da altri microservizi.

L'architettura dei microservizi è probabilmente la migliore architettura per creare app che mirano a raggiungere migliaia e milioni di utenti un giorno. Ogni componente è resiliente, scalabile e di facile manutenzione. Tuttavia, il mantenimento del ciclo di vita DevOps per un'app basata su microservizi richiede sforzi aggiuntivi; quindi potrebbe non adattarsi bene a casi d'uso più piccoli.

Vantaggi dell'architettura dei microservizi

Alcuni vantaggi dell'architettura dei microservizi includono:

• I componenti dell'app sono altamente modulari, indipendenti e possono essere riutilizzati in misura maggiore rispetto a quelli dell'architettura orientata ai servizi.
• Ciascun componente può essere ridimensionato in modo indipendente per soddisfare il traffico utente variabile.
• Le app basate su microservizi sono altamente tolleranti ai guasti.

Contro dell'architettura dei microservizi

Uno svantaggio dell'architettura dei microservizi può essere:

• Per i progetti più piccoli, l'architettura dei microservizi potrebbe richiedere uno sforzo eccessivo per la manutenzione.

Architettura senza server

L'architettura serverless è un altro importante concorrente nel mondo delle architetture delle app Web. Questa architettura si concentra sulla scomposizione dell'applicazione in termini di funzioni che dovrebbe svolgere. Quindi queste funzioni sono ospitate su piattaforme FaaS (Function-as-a-Service) come funzioni che vengono invocate quando e quando arrivano le richieste.

A differenza della maggior parte delle altre architetture in questo elenco, le app create utilizzando l'architettura serverless non rimangono sempre in esecuzione. Si comportano esattamente come farebbero le funzioni: aspettano di essere chiamate e, dopo essere state chiamate, eseguono il processo definito e restituiscono un risultato. A causa di questa natura, riducono i costi di manutenzione e sono altamente scalabili senza troppi sforzi. Tuttavia, è difficile eseguire attività di lunga durata utilizzando tali componenti.

Vantaggi dell'architettura serverless

Ecco i principali vantaggi dell'architettura serverless:

• Le app serverless sono altamente e facilmente scalabili. Possono persino adattarsi al traffico in entrata in tempo reale per ridurre il carico sull'infrastruttura.
• Tali app possono utilizzare il modello di tariffazione pay-per-use delle piattaforme serverless per ridurre i costi di infrastruttura.
• Le app serverless sono abbastanza facili da creare e distribuire poiché tutto ciò che devi fare è scrivere una funzione e ospitarla su una piattaforma come le funzioni Firebase, AWS Lambda, ecc.

Contro dell'architettura serverless

Di seguito sono riportati alcuni degli svantaggi dell'architettura serverless:

• Le attività di lunga durata possono essere costose da eseguire su una tale architettura.
• Quando una funzione riceve una richiesta dopo molto tempo, è nota come avvio a freddo. Gli avviamenti a freddo sono lenti e possono fornire una brutta esperienza all'utente finale.

Livelli di architettura dell'applicazione Web

Mentre le architetture delle applicazioni Web che hai visto sopra potrebbero sembrare tutte molto diverse l'una dall'altra, i loro componenti possono essere logicamente raggruppati insieme in livelli definiti che aiutano a raggiungere un obiettivo aziendale.

Livello di presentazione

Il livello di presentazione tiene conto di tutto ciò che è esposto agli utenti finali in un'app Web. In primo luogo, il livello di presentazione è composto dal client frontend. Tuttavia, incorpora anche qualsiasi logica che hai scritto sul tuo back-end per rendere dinamico il tuo front-end. Questo ti dà lo spazio per servire i tuoi utenti con un'interfaccia utente personalizzata in base al loro profilo e ai loro requisiti.

Per costruire questo livello vengono utilizzate tre tecnologie fondamentali: HTML, CSS e JavaScript. HTML definisce il tuo frontend, CSS lo stilizza e JS ci dà vita (cioè controlla il suo comportamento quando gli utenti interagiscono con esso). Oltre a queste tre tecnologie, puoi utilizzare qualsiasi tipo di framework per semplificare il tuo sviluppo. Alcuni framework frontend comuni includono Laravel, React, NextJS, Vue, GatsbyJS, ecc.

Livello aziendale

Il livello aziendale è responsabile della conservazione e della gestione della logica di lavoro dell'app. Di solito è un servizio di back-end che accetta le richieste del client e le elabora. Controlla ciò a cui l'utente può accedere e determina come viene utilizzata l'infrastruttura per soddisfare le richieste degli utenti.

Nel caso di un'app per la prenotazione di hotel, l'app client funge da portale per consentire agli utenti di digitare i nomi degli hotel e altri dati rilevanti. Tuttavia, non appena l'utente fa clic sul pulsante di ricerca, il livello aziendale riceve la richiesta e avvia la logica per la ricerca di camere d'albergo disponibili che soddisfano le tue esigenze. Il cliente riceve quindi solo un elenco di camere d'albergo senza alcuna conoscenza di come questo elenco sia stato generato o anche del motivo per cui le voci dell'elenco sono disposte nel modo in cui sono state inviate.

La presenza di un tale livello garantisce che la tua logica aziendale non sia esposta al tuo cliente e, in definitiva, agli utenti. L'isolamento della logica aziendale è di grande aiuto in operazioni sensibili come la gestione dei pagamenti o la gestione delle cartelle cliniche.

Strato di persistenza

Il livello di persistenza è responsabile del controllo dell'accesso ai tuoi archivi dati. Questo funge da ulteriore livello di astrazione tra i tuoi datastore e il tuo livello aziendale. Riceve tutte le chiamate relative ai dati dai livelli aziendali e le elabora creando connessioni sicure al database.

Questo livello di solito è costituito da un server di database. Puoi impostare tu stesso questo livello effettuando il provisioning di un database e di un server di database nella tua infrastruttura on-premise oppure optare per una soluzione gestita in remoto da uno dei principali fornitori di infrastrutture cloud come AWS, GCP, Microsoft Azure, ecc.

Componenti dell'applicazione Web

Ora che hai compreso cosa succede nell'architettura di un'applicazione Web, diamo uno sguardo dettagliato a ciascuno dei componenti che compongono un'app Web. Raggrupperemo questa discussione in due titoli principali: componenti lato server e componenti lato client o componenti back-end e front-end.

Componenti lato server

I componenti lato server sono quelli che risiedono sul back-end della tua applicazione web. Questi non sono esposti direttamente agli utenti e contengono la logica aziendale e le risorse più importanti per la tua app Web.

DNS e routing

Il DNS è responsabile del controllo del modo in cui la tua app viene esposta al Web. I record DNS vengono utilizzati dai client HTTP, che potrebbero essere anche un browser, per trovare e inviare richieste ai componenti della tua app. Il DNS viene utilizzato anche internamente dai client front-end per risolvere la posizione dei server Web e degli endpoint API per inviare richieste ed elaborare le operazioni degli utenti.

Il bilanciamento del carico è un altro componente popolare dell'architettura delle applicazioni web. Un sistema di bilanciamento del carico viene utilizzato per distribuire le richieste HTTP tra più server Web identici. L'intento alla base di avere più server Web è mantenere la ridondanza che aiuta ad aumentare la tolleranza agli errori e distribuire il traffico per mantenere prestazioni elevate.

Gli endpoint API vengono utilizzati per esporre i servizi di back-end all'applicazione front-end. Questi aiutano a facilitare la comunicazione tra il client e il server, e talvolta anche tra più server.

Archivio dati

L'archiviazione dei dati è una parte cruciale della maggior parte delle applicazioni moderne poiché ci sono sempre alcuni dati delle app che devono essere mantenuti tra le sessioni utente. La memorizzazione dei dati è di due tipi:

• Database: i database vengono utilizzati per archiviare i dati per un accesso rapido. Di solito, supportano l'archiviazione di una piccola quantità di dati a cui l'applicazione accede regolarmente.
• Data warehouse: i data warehouse sono pensati per la conservazione dei dati storici. Questi di solito non sono necessari molto spesso nell'app, ma vengono elaborati regolarmente per generare approfondimenti aziendali.

Memorizzazione nella cache

La memorizzazione nella cache è una funzionalità facoltativa spesso implementata nelle architetture di app Web per offrire agli utenti il ​​contenuto più rapidamente. Una gran parte del contenuto dell'app è spesso ripetitiva per un certo periodo di tempo, se non sempre. Invece di accedervi da un archivio dati ed elaborarlo prima di rispedirlo all'utente, viene spesso memorizzato nella cache. Di seguito sono riportati i due tipi più popolari di memorizzazione nella cache utilizzati nelle applicazioni Web:

• Memorizzazione nella cache dei dati: la memorizzazione nella cache dei dati introduce un modo per la tua app di accedere facilmente e rapidamente ai dati utilizzati regolarmente che non cambiano spesso. Tecnologie come Redis e Memcache consentono di memorizzare nella cache i dati per risparmiare su costose query di database solo per recuperare gli stessi dati ancora e ancora.
• Memorizzazione nella cache delle pagine Web: una CDN (Content Delivery Network) memorizza nella cache le pagine Web allo stesso modo in cui Redis memorizza nella cache i dati. Simile a come vengono memorizzati nella cache solo i dati che non cambiano spesso, di solito si consiglia di memorizzare nella cache solo le pagine Web statiche. Per le app Web con rendering lato server, la memorizzazione nella cache non fa molto bene poiché il loro contenuto dovrebbe essere altamente dinamico.

Lavori e servizi

Oltre a esporre un'interfaccia agli utenti (frontend) e gestire le loro richieste (backend), esiste un'altra categoria leggermente meno popolare di componenti di app Web. I lavori sono spesso servizi in background che hanno lo scopo di completare attività che non sono temporanee o sincrone.

I lavori CRON sono quelli che vengono eseguiti continuamente in un periodo di tempo fisso. Questi lavori sono pianificati sul back-end per eseguire automaticamente le routine di manutenzione a orari prestabiliti. Alcuni esempi di casi d'uso comuni per questi includono l'eliminazione di duplicati/vecchi record dal database, l'invio di e-mail di promemoria ai clienti, ecc.

Componenti lato client

I componenti lato client sono quelli che sono esposti agli utenti direttamente o indirettamente.

Ci sono principalmente due tipi di componenti in questa categoria.

Interfaccia utente front-end

L'interfaccia utente è l'aspetto visivo dell'applicazione. È ciò con cui i tuoi utenti vedono e interagiscono per accedere ai tuoi servizi.

L'interfaccia frontend è principalmente basata su tre tecnologie popolari: HTML, CSS e JavaScript. L'interfaccia utente frontend può essere un'applicazione in sé con il proprio ciclo di vita di sviluppo del software.

Queste interfacce utente non ospitano gran parte della tua logica aziendale poiché sono esposte direttamente ai tuoi utenti. Se un utente malintenzionato tenta di decodificare la tua applicazione frontend, può ottenere informazioni su come funziona la tua attività e svolgere attività illegali come la rappresentazione del marchio e il furto di dati.

Inoltre, poiché l'interfaccia utente frontend è esposta direttamente agli utenti, ti consigliamo di ottimizzarla per tempi di caricamento e reattività minimi. A volte questo può aiutarti a fornire un'esperienza migliore ai tuoi utenti, aumentando così la crescita della tua attività.

Logica di business lato client

A volte potrebbe essere necessario archiviare alcune logiche di business sul client per eseguire rapidamente operazioni più semplici. La logica lato client che di solito risiede all'interno dell'applicazione frontend può aiutarti a saltare il viaggio verso il server e fornire ai tuoi utenti un'esperienza più rapida.

Questa è una funzionalità opzionale dei componenti lato client. In alcuni casi, la logica aziendale dell'app viene archiviata interamente sul lato client (soprattutto quando si compila senza un server back-end tradizionale). Soluzioni moderne come BaaS ti aiutano ad accedere a operazioni comuni come l'autenticazione, l'archiviazione dei dati, l'archiviazione dei file, ecc., in movimento nella tua app frontend.

Esistono modi per offuscare o minimizzare questo codice prima di distribuirlo agli utenti per ridurre al minimo le possibilità di reverse engineering.

Modelli di componenti di applicazioni Web

Esistono più modelli di architetture di applicazioni Web, ciascuno basato su come i server Web si connettono ai loro archivi dati.

Un server, un database

Il modello più semplice di tutti è un server Web che si connette a un'istanza di database. Un tale modello è facile da implementare e mantenere, e anche andare in produzione con esso è abbastanza semplice.

Per la sua semplicità, questo modello è adatto per l'apprendimento e per piccole applicazioni sperimentali che non saranno esposte a traffico elevato. Gli sviluppatori inesperti possono facilmente configurare e armeggiare con queste app per apprendere i fondamenti dello sviluppo di app Web.

Tuttavia, questo modello non dovrebbe essere utilizzato in produzione poiché è altamente inaffidabile. Un problema nel server o nel database può causare tempi di inattività e perdita di attività.

Più server, un database

Questo modello migliora l'applicazione configurando più server per la ridondanza con un'unica istanza di database comune.

Poiché più server Web accedono al database contemporaneamente, possono verificarsi problemi di incoerenza. Per evitarlo, i server web sono progettati per essere stateless. Ciò significa che i server non conservano i dati tra le sessioni; semplicemente lo elaborano e lo memorizzano nel database.

Le app realizzate con questo modello sono sicuramente più affidabili di quelle con il modello precedente, in quanto la presenza di più web server si aggiunge alla tolleranza agli errori della web app. Tuttavia, poiché il database è ancora un'istanza comune, è l'anello più debole dell'architettura e può essere una fonte di errore.

Più server, più database

Questo modello è uno dei modelli tradizionali più comuni di progettazione di applicazioni web.

In questo caso, distribuisci la logica dell'applicazione come più istanze di server Web identiche unite insieme dietro un sistema di bilanciamento del carico. Il tuo archivio dati viene inoltre mantenuto su più istanze di database per una maggiore tolleranza agli errori.

Puoi anche scegliere di dividere il tuo database tra le istanze disponibili per migliorare le prestazioni o mantenere duplicati dell'intero datastore per la ridondanza. In entrambi i casi, l'errore in una qualsiasi istanza del database non comporterà un'interruzione completa dell'applicazione.

Questo modello è molto apprezzato per la sua affidabilità e scalabilità. Tuttavia, lo sviluppo e la manutenzione di app che utilizzano questo modello sono relativamente complicati e richiedono sviluppatori esperti e costosi. In quanto tale, questo modello è consigliato solo quando stai costruendo su larga scala.

Servizi app

Mentre i tre modelli sopra menzionati sono adatti per applicazioni monolitiche, esiste un altro modello per applicazioni modulari.

Il modello dei servizi applicativi suddivide un'app in moduli più piccoli in base alla funzionalità aziendale. Questi moduli possono essere piccoli come una funzione o grandi come un servizio.

L'idea qui è di rendere ogni funzionalità aziendale indipendente e scalabile. Ciascuno di questi moduli può connettersi al database da solo. Puoi persino avere istanze di database dedicate per soddisfare le esigenze di scalabilità del tuo modulo.

Tra le app non monolitiche, questo modello è piuttosto popolare. I monoliti legacy vengono spesso migrati a questo modello per sfruttarne i vantaggi di scalabilità e modularità. Tuttavia, la gestione delle app basate su tale modello spesso richiede sviluppatori esperti, in particolare esperienza in DevOps e CI/CD.

Procedure consigliate per l'architettura delle applicazioni Web

Di seguito sono riportate alcune procedure consigliate che puoi implementare nel progetto di applicazione Web per ottenere il massimo dall'architettura dell'app Web scelta.

1. Rendi il tuo frontend reattivo

Questo non può essere sottolineato abbastanza: punta sempre a frontend reattivi. Non importa quanto sia grande e complessa la tua app web internamente, è tutta esposta ai tuoi utenti tramite pagine web, app e schermate front-end.

Se i tuoi utenti trovano queste schermate poco intuitive o lente, non rimarranno in giro abbastanza a lungo per visualizzare e ammirare la meraviglia ingegneristica che è la tua app web.

Pertanto, la progettazione di frontend accessibili, facili da usare e leggeri è molto importante.

Sul Web sono disponibili numerose best practice per l'interfaccia utente/UX per aiutarti a capire cosa funziona meglio per i tuoi utenti. Puoi trovare professionisti esperti nella realizzazione di progetti e architetture user-friendly che possono consentire ai tuoi utenti di ottenere il massimo dalle tue app.

We advise giving serious thought to your frontend's responsiveness before rolling out your product to your users.

2. Monitor Load Times

Apart from being easy to understand, your frontends also need to be quick to load.

According to Portent, the highest ecommerce conversion rates occur on pages with load times between 0–2 seconds, and according to Unbounce, around 70% of consumers admit that page loading time is an important factor in their choice to purchase from an online seller.

When designing mobile-native applications, you can't usually be certain of your users' device specifications. Any device that doesn't meet your app's requirements is typically declared to not support the app.

However, this is quite different with the web.

When it comes to web applications, your users could be using anything from the latest Apple Macbook M1 Pros to vintage Blackberry and Nokia phones to view your app. Optimizing your frontend experience for such a wide range of users can be tough at times.

Services like LightHouse and Google PageSpeed come to mind when talking about frontend performance. You should use such tools to benchmark your frontend app before deploying it in production. Most such tools provide you with a list of actionable tips to help improve your app's performance as much as possible.

The final 5–10% of the app's performance is usually specific to your use case and can only be fixed by somebody who knows your app and its technologies well. It never hurts to invest in web performance!

3. Prefer PWA Wherever Possible

As discussed earlier, PWAs are the designs of the future. They can fit most use cases well, and they provide the most uniform experience across major platforms.

You should consider using PWA for your app as frequently as possible. The native experience across web and mobile is hugely impactful for your users and can reduce a lot of your own workload as well.

PWAs are also fast to load, easy to optimize, and quick to build. Opting for PWAs can help you shift a lot of your focus from development to business early on.

Keep Your Codebase Clean and Succinct

A clean codebase can help you spot and resolve most issues before they cause damage. Here are some tips you can follow to ensure that your codebase isn't causing you any more trouble than it should.

• Focus on code reuse: Maintaining copies of the same code throughout your codebase is not only redundant, but it can also cause discrepancies to creep in, making your codebase difficult to maintain. Always focus on re-using code wherever possible.
• Plan your project structure: Software projects can grow very large with time. If you don't begin with a planned structure of code organization and resources, you might end up spending more time finding files than writing useful code.
• Write unit tests: Every piece of code has a chance of breaking. Testing all of it manually is not feasible, so you need a fixed strategy for automating tests for your codebase. Test runners and code coverage tools can help you identify if your unit testing efforts are yielding the desired results.
• High modularity: When writing code, always focus on modularity. Writing code that is tightly coupled to other pieces of code makes it difficult to test, re-use, and alter when needed.

5. Automate Your CI/CD Processes

CI/CD stands for Continuous Integration/Continuous Deployment. CI/CD processes are crucial to the development of your application as they help you to build, test, and deploy your project with ease.

However, you don't want to have to run them manually each time. You should instead set up pipelines that trigger automatically based on your project's activities. For instance, you could set up a pipeline that runs your tests automatically whenever you commit your code to your version control system. There are plenty of more complex use cases, too, such as generating cross-platform artifacts from your code repository whenever a release is created.

The possibilities are endless, so it's up to you to figure out how you can make the most out of your CI/CD pipelines.

6. Incorporate Security Features

Most modern apps are made of multiple components. Take the following app as an example:

Client requests are routed to the app through an API gateway. While this one currently only allows direct requests to the home module of the app, in the future, it could allow for access to more components without going through the home module.

Next up, the home module checks an external authentication BaaS before allowing access. Once authenticated, the client can access the “Update Profile” or “View Profile” pages. Both these pages interact with a common, managed database solution that handles the profile data.

As you can see, the application seems like a very basic and minimal version of an online people directory. You can add/update your own profile or view other profiles available.

Here's a quick legend of the various components in the architecture:

• Blue boxes: App modules, which are possibly hosted as microservices or serverless functions.
• Red boxes: External BaaS components that provide for authentication and database.
• Green box: Routing component that moderates incoming requests from the client.
• Black box: Your client application exposed to the user.

The components of each of the colors above are vulnerable to various kinds of security threats. Here are a few security constructs you can put in place to minimize your exposure:

• App modules (blue): Since these are serverless functions, here are a few tips to strengthen their security:
  • Isolate app secrets and manage them independently of your source code
  • Maintain access controls through IAM services
  • Improve your testing efforts to also look for security threats through techniques such as SAST
• External services (red):
  • Set up access controls through their IAM modules to regulate access
  • Opt for API rate limiting
  • For services such as databases, set up finer control permissions, such as who can access the profiles' data, who can view the users' data, and more. Many services, like Firebase, provide a detailed set of such rules.
• Routing component (green):
  • Like all other components, implement access controls
  • Set up authorization
  • Double-check on standard best practices such as CORS
• Client:
  • Ensure that no app secrets are available to your client
  • Obfuscate your client code to minimize the chances of reverse engineering

While these are just a handful of suggestions, they stand to make the point that app security is complicated, and it's your responsibility to ensure that you're not leaving any loose ends for attackers to pull on. You cannot rely on a central security component to protect your business; app security is distributed across your app architecture.

7. Collect User Feedback

User feedback is a crucial tool to understand how well your app is doing in terms of business and technical performance. You can build the lightest and the smoothest app in the world, but if it doesn't let your users do what they expect, then all your efforts go down the drain.

There are multiple ways to collect user feedback. While a quick and anonymized survey is the conventional approach, you could also go for a more sophisticated solution, such as a heat map of your users' activity.

The choice of feedback collection method is less important than taking action on the collected feedback. Customers love businesses that listen to their problems. Giants like McDonald's and Tesla do it, and that's one of the reasons why they continue to succeed in their markets.

Riepilogo

The web is a huge playground of a variety of applications, each designed in its own unique way. Multiple types of architectures make way for web apps to diversify, thrive, and offer services to users all across the globe.
Learn how web application architecture affects the end-user experience and see best practices you can implement, all in this guide Click to Tweet
In this guide, we broke down the different models of web app architecture and showed you how crucial they are to an application's growth.

Is there a web app architecture that you really loved? Or is there another that you'd like to share with the world? Let us know in the comments below!