Cos’è l’Architettura delle Applicazioni Web? Analisi di un’Applicazione Web

Il mondo si è trasferito su internet e le applicazioni web sono diventate i nuovi luoghi di lavoro e negozi. Per soddisfare la varietà di scopi che le moderne applicazioni web servono, ognuna di esse deve essere progettata per ottenere alte prestazioni e personalizzazione.

Le architetture delle applicazioni web risolvono questo problema.

L’architettura delle applicazioni web definisce come sono strutturati i vari componenti di un’applicazione basata sul web. Questa architettura è molto specifica per la natura e lo scopo dell’applicazione web. La scelta di un’architettura sbagliata per l’applicazione web può creare problemi alla vostra attività.

In questa guida analizzeremo il concetto di architettura delle applicazioni web e capiremo come influisce sull’esperienza utente finale della vostra applicazione. Infine, esamineremo anche alcune delle migliori pratiche che potete implementare per ottenere il massimo dalla vostra applicazione web.

Cos’È l’Architettura delle Applicazioni Web?

Per iniziare la discussione, partiamo dalla definizione di architettura delle applicazioni web.

In parole povere, l’architettura dell’applicazione web è uno schema di come i vari componenti della vostra applicazione web interagiscono tra loro.

Può essere semplice come definire la relazione tra il client e il server. Può anche essere complessa, come definire le interrelazioni tra uno sciame di server back-end containerizzati, load balancer, gateway API e frontend a pagina singola rivolti all’utente.

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

Il modo in cui progettate la vostra applicazione web gioca un ruolo fondamentale sia per la sua usabilità che per l’ottimizzazione dei costi. Ecco un esempio di architettura di un’applicazione web sulla carta:

Perché l’Architettura delle Applicazioni Web È Importante?

L’architettura delle applicazioni web è, senza dubbio, una delle parti più importanti della vostra applicazione web. Se scegliete di sviluppare la vostra applicazione web tenendo conto di un’architettura specifica, otterrete sicuramente molti vantaggi per quanto riguarda la manutenzione e la crescita della vostra applicazione.

Tuttavia, la scelta della giusta architettura amplifica ulteriormente questi vantaggi.

Ecco alcuni dei principali motivi per cui dovreste prendere in seria considerazione l’adozione di un’architettura per applicazioni web.

Si Adatta Facilmente alle esigenze aziendali

La vostra applicazione è una porta d’accesso fondamentale al vostro business e le esigenze aziendali si evolvono con il mutare del mercato. Per stare al passo, è importante che la vostra app sia abbastanza flessibile da adattarsi alle mutevoli esigenze aziendali. Se costruite un’app senza considerare la flessibilità incorporata, vi ritroverete a spendere sempre più tempo e fatica per apportare piccole modifiche alla vostra applicazione.

La giusta architettura di un’applicazione web tiene già conto di alcuni cambiamenti che la vostra azienda potrebbe richiedere in futuro. Per esempio, se sapete che state costruendo un’applicazione di ecommerce che un giorno scalerà e fornirà un’ampia gamma di servizi a un gran numero di clienti, la scelta di un’architettura a microservizi rispetto a una monolitica vi garantirà una maggiore flessibilità.

D’altro canto, se state realizzando un’applicazione interna alla vostra azienda con solo uno o due requisiti fissi, potete optare per un monolite più semplice per accelerare lo sviluppo e mantenere pulita la vostra codebase.

Sviluppo Organizzato

Come abbiamo detto in precedenza, la giusta architettura di un’applicazione web vi offre una tabella di marcia più comoda per lo sviluppo. L’architettura fornisce una modularità sufficiente al vostro sistema per isolare i componenti in base alle necessità e voi avete la libertà di scegliere la giusta struttura di progetto per ogni modulo e componente.

Se vi tuffate nello sviluppo di un’app senza avere in mente un’architettura, rischiate di perdere tempo e denaro per riorganizzare i componenti e stabilire nuove regole per facilitare la collaborazione tra i membri del team: tempo e denaro che potrebbero essere spesi altrove.

Migliore Gestione della Base di Codice

Oltre a scrivere il codice della vostra applicazione, passerete anche una notevole quantità di tempo a gestirlo. 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 senza intoppi.

La giusta architettura di un’applicazione web vi permette di apportare facilmente delle modifiche. Potete implementare le best practice specifiche per ogni componente, separare i punti dolenti della vostra app e mantenere ogni funzionalità indipendente e non vincolata. Non è che queste cose non si possano fare senza l’architettura; è solo che l’architettura giusta rende tutto molto più semplice.

Seguire un’architettura predefinita vi permette anche di sviluppare più velocemente le vostre applicazioni. L’architettura giusta, combinata con una valida strategia di controllo delle versioni, può consentire alle persone del vostro team di sviluppo di lavorare in parallelo tra loro e di realizzare le funzionalità più velocemente.

Un’architettura per web app è anche a prova di futuro. Una volta definita una solida strategia per l’organizzazione dei componenti della vostra applicazione, potrete facilmente migrare i componenti alle nuove tecnologie, uno alla volta, senza dover rifare l’intera applicazione.

Sicurezza Migliorata

La maggior parte delle architetture delle applicazioni web tiene conto della sicurezza nella strutturazione dei componenti. Gli sviluppatori possono pianificare in anticipo le misure e le pratiche da implementare per migliorare la sicurezza dell’applicazione prima che venga distribuita agli utenti.

Per esempio, la costruzione di un’app di streaming video OTT che offre contenuti sia a pagamento che gratuiti usando i microservizi ha più senso perché l’architettura a microservizi vi permette di suddividere l’app in componenti business-friendly, come l’autenticazione degli utenti e lo streaming di contenuti gratuiti o a pagamento. Se il modulo di autenticazione dell’utente dovesse andare in tilt, potete facilmente configurare la vostra app in modo da limitare l’accesso al modulo dei contenuti a pagamento fino a quando l’autenticazione non sarà ripristinata, mentre il modulo dei contenuti gratuiti sarà ancora disponibile per i vostri utenti.

In un caso alternativo in cui la stessa applicazione è stata progettata come un monolite strettamente accoppiato, un servizio di autenticazione fuori uso significherebbe o un’applicazione fuori uso o la messa a disposizione gratuita di contenuti a pagamento: risultati che vorrete 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’applicazione nella barra degli indirizzi del browser o fa clic su un link.
2. Il browser cerca l’URL nei server DNS e identifica l’indirizzo IP dell’app.
3. Il browser invia una richiesta HTTP all’app.
4. L’app risponde con il contenuto corretto (di solito una pagina web).
5. Il browser visualizza la pagina web sullo schermo.

Se volete approfondire, ecco come un’applicazione web gestisce una richiesta:

1. L’utente invia una richiesta alla vostra app tramite l’interfaccia utente del frontend.
2. Se avete impostato una cache pertinente, l’app la controlla per vedere se ha un record valido che può essere inviato direttamente al cliente. In caso affermativo, il contenuto della cache verrà inviato e la richiesta verrà contrassegnata come completata.
3. Se non c’è una cache, la richiesta viene inoltrata al load balancer.
4. Il load balancer identifica un’istanza del server disponibile a gestire la richiesta e la inoltra.
5. L’istanza del server elabora la richiesta e chiama eventuali API esterne, se necessario.
6. Una volta raccolti i risultati in un unico punto, il server invia la risposta al load balancer.
7. Il load balancer 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 delle Applicazioni Web

Ora che avete un’idea di base di cosa sia l’architettura di un’applicazione web, diamo un’occhiata dettagliata ad alcuni dei tipi più diffusi di architettura di applicazioni web utilizzati nel web.

Architettura a Pagina Singola (SPA o Single Page Architecture)

L’architettura di un’applicazione a pagina singola (SPA) è semplice come il suo nome: l’intera applicazione si basa su un’unica pagina. Una volta che l’utente accede alla vostra applicazione, non deve navigare in altre pagine web. L’applicazione è sufficientemente dinamica da recuperare e renderizzare le schermate che soddisfano i requisiti degli utenti mentre navigano all’interno dell’applicazione stessa.

Le SPA sono ottime quando si tratta di fornire un’esperienza veloce e senza interruzioni agli utenti finali o ai consumatori. Tuttavia, non hanno il 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 sono:

• Potete creare applicazioni web altamente interattive.
• Le SPA sono facili da scalare.
• L’ottimizzazione delle prestazioni delle SPA non richiede grandi sforzi.

Contro dell’Architettura SPA

Alcuni degli svantaggi dell’architettura SPA sono:

• Le SPA limitano la flessibilità dei collegamenti ipertestuali e della SEO.
• Il rendering iniziale è solitamente lento.
• La navigazione all’interno dell’app può essere poco intuitiva.

Progressive Web Application

L’architettura Progressive Web Application (PWA) si basa sull’Architettura a Pagina Singola e fornisce funzionalità offline alla vostra applicazione web. Tecnologie come Capacitor e Ionic sono utilizzate per costruire PWA in grado di fornire agli utenti un’esperienza uniforme su tutte le piattaforme.

Come le SPA, le PWA sono fluide e senza interruzioni. Con l’aggiunta della possibilità di essere installate sui dispositivi degli utenti (tramite service worker), i vostri utenti avranno un’esperienza più uniforme con la vostra applicazione.

Allo stesso tempo, può essere difficile ottimizzare queste applicazioni per la SEO e gli aggiornamenti delle applicazioni installate possono essere difficili da eseguire.

I Vantaggi dell’Architettura PWA

I vantaggi dell’architettura PWA sono molti, tra cui:

• Le app funzionano in modo molto fluido e offrono compatibilità multipiattaforma.
• La scalabilità è semplice.
• Gli sviluppatori possono accedere all’accesso offline e alle API native dei dispositivi, come i lavoratori in background e le notifiche push.

Contro dell’Architettura PWA

Alcuni dei contro dell’architettura PWA possono includere:

• Il supporto alla gestione dei link e al SEO è limitato.
• L’invio di aggiornamenti alle PWA offline è più complesso rispetto alle app native.
• Il supporto per le PWA è limitato a tutti i browser e sistemi operativi.

Architettura con Rendering Lato Server

Nel rendering lato server (SSR o Server-Side Rendering), le pagine web frontend vengono renderizzate su un server backend dopo essere state richieste dall’utente. Questo aiuta a ridurre il carico sul dispositivo client che riceve una pagina web statica in HTML, CSS e JS.

Le applicazioni SSR sono molto popolari tra i blog e i siti di ecommerce. Questo perché rendono molto semplice la gestione dei link e la SEO. Inoltre, il primo rendering delle app SSR è abbastanza veloce perché il client non deve elaborare alcun codice JS per renderizzare le schermate.

I Vantaggi dell’Architettura SSR

Di seguito sono elencati alcuni dei vantaggi dell’architettura SSR:

• Queste app sono ottime per i siti web che fanno leva sulla SEO.
• Il caricamento della prima pagina è quasi istantaneo nella maggior parte dei casi.
• Potete abbinarle a un servizio di caching per migliorare ulteriormente le prestazioni della vostra app.

Contro dell’Architettura SSR

Alcuni svantaggi dell’utilizzo dell’architettura SSR sono:

• Non è consigliata per pagine web complesse o pesanti, poiché il server può impiegare del tempo per generare completamente la pagina, con conseguente ritardo nel primo rendering.
• È consigliato soprattutto per le applicazioni che non si concentrano molto sull’interfaccia utente e che cercano solo una maggiore scalabilità o sicurezza.

Pre-Rendered Applications Architecture

L’architettura delle applicazioni pre-renderizzate (Pre-rendered applications architecture) è nota anche come architettura di generazione di siti statici. In questa architettura, le pagine web front-end dell’applicazione sono pre-generate e memorizzate come semplici file HTML, CSS e JS sul server. Quando un utente richiede una pagina, questa viene recuperata e mostrata direttamente. Questo rende la web app molto veloce, con tempi di caricamento minimi. Tuttavia, questa architettura aumenta il tempo di costruzione dell’applicazione, poiché le pagine web vengono renderizzate durante il processo di creazione.

Le web app pre-renderizzate sono ideali per generare contenuti statici come blog o dettagli di prodotti che non cambiano spesso. Potete anche usare dei modelli per semplificare il design delle vostre pagine web. Tuttavia, è quasi impossibile creare applicazioni web dinamiche con questa architettura. Se state cercando di creare una pagina di ricerca che prenda la query nel suo percorso (qualcosa come https://myapp.com/search/foo+bar), siete nel posto sbagliato.

Dal momento che ogni possibile percorso dell’app viene prerenderizzato durante il processo di creazione, è impossibile avere percorsi dinamici come quelli descritti sopra, poiché esistono infinite possibilità che non possono essere pre-renderizzate durante la creazione (e non ha nemmeno senso farlo).

I Vantaggi 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; di conseguenza le loro prestazioni sono simili a quelle delle applicazioni realizzate con JS vanilla.
• Se conoscete tutti i percorsi possibili della vostra app, la SEO diventa facilissima.

Contro dell’Architettura Pre-Renderizzata

Come ogni modello architettonico, anche quello pre-renderizzato ha i suoi svantaggi:

• I contenuti dinamici non possono essere serviti con queste app.
• Apportare qualsiasi modifica alla web app significa ricostruire completamente l’app e distribuirla da zero.

Isomorphic Application Architecture

Le applicazioni “isomorfe” sono un misto di applicazioni renderizzate lato server e SPA. Ciò significa che queste applicazioni vengono prima renderizzate sul server come una normale applicazione renderizzata sul lato server. Una volta ricevute dal client, l’app si idrata e attacca il DOM virtuale per un’elaborazione più rapida ed efficiente da parte del client. In questo modo l’applicazione si trasforma essenzialmente in un’applicazione a pagina singola.

L’isomorphic riunisce il meglio di entrambi i mondi. Grazie alla SPA, l’elaborazione e l’interfaccia utente sul client sono superveloci. Inoltre, grazie al rendering lato server, otterrete un rendering iniziale rapido e un supporto SEO e di link completo.

I Vantaggi dell’Architettura Isomorphic

Ecco alcuni dei vantaggi dell’utilizzo dell’architettura isomorphic delle applicazioni:

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

Contro dell’Architettura Isomorphic

Alcuni dei contro dell’architettura applicativa isomorphic possono essere:

• La creazione di un’app di questo tipo richiede talenti qualificati.
• Le opzioni di stack tecnologico sono limitate quando si tratta di progettare un’app isomorphic. Potete scegliere solo tra una manciata di librerie e framework (per lo più) basati su JS.

Architettura Orientata ai Servizi (Service-Oriented Architecture)

L’architettura orientata ai servizi è una delle alternative più diffuse al tradizionale modo di costruire le applicazioni in stile monolite. In questa architettura, le applicazioni web sono suddivise in servizi che rappresentano ciascuno un’unità funzionale del business. Questi servizi sono accoppiati in modo lasco e interagiscono tra loro attraverso 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 ai componenti aziendali, non a quelli tecnici; di conseguenza la manutenzione può essere un problema.

I Vantaggi dell’Architettura Orientata ai Servizi

I principali vantaggi dell’architettura orientata ai servizi includono:

• Aiuta a costruire applicazioni altamente scalabili e affidabili.
• I componenti sono riutilizzabili e condivisi per migliorare lo sviluppo e la manutenzione.

Contro dell’Architettura Orientata ai Servizi

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

• Le applicazioni SOA non sono ancora flessibili al 100% perché le dimensioni e la portata di ogni servizio non sono fisse. Ci possono essere servizi delle dimensioni di applicazioni aziendali che possono essere difficili da mantenere.
• La condivisione dei componenti introduce dipendenze tra i servizi.

Architettura a Microservizi

L’architettura a microservizi è stata progettata per risolvere i problemi dell’architettura orientata ai servizi. I microservizi sono componenti ancora più modulari che si uniscono per costruire un’applicazione web. Tuttavia, i microservizi si concentrano sul mantenere ogni componente piccolo e con un contesto delimitato. Un contesto delimitato significa essenzialmente che ogni microservizio ha il suo codice e i suoi dati accoppiati insieme con dipendenze minime da altri microservizi.

L’architettura a microservizi è probabilmente la migliore per costruire applicazioni che puntano a scalare a migliaia e milioni di utenti un giorno. Ogni componente è resiliente, scalabile e facile da mantenere. Tuttavia, la manutenzione del ciclo di vita DevOps di un’applicazione basata su microservizi richiede un impegno supplementare; per questo motivo potrebbe non essere adatta a casi d’uso di piccole dimensioni.

I Vantaggi dell’Architettura a Microservizi

Alcuni vantaggi dell’architettura a microservizi sono:

• I componenti delle app sono altamente modulari, indipendenti e possono essere riutilizzati in misura maggiore rispetto a quelli dell’architettura orientata ai servizi.
• Ogni componente può essere scalato in modo indipendente per soddisfare il traffico degli utenti.
• Le app basate sui microservizi sono altamente tolleranti agli errori.

Contro dell’Architettura a Microservizi

Uno svantaggio dell’architettura a microservizi può essere:

• Per i progetti più piccoli, l’architettura a microservizi potrebbe richiedere un impegno eccessivo per la manutenzione.

Architettura Serverless

L’architettura serverless è un’altra novità nel mondo delle architetture per applicazioni web. Questa architettura si concentra sulla suddivisione dell’applicazione in termini di funzioni che deve svolgere. Queste funzioni vengono poi ospitate su piattaforme FaaS (Function-as-a-Service) come funzioni che vengono invocate quando arrivano le richieste.

A differenza della maggior parte delle altre architetture presenti in questo elenco, le app realizzate con l’architettura serverless non rimangono in esecuzione per tutto il tempo. Si comportano proprio come le funzioni: aspettano di essere chiamate e, una volta chiamate, eseguono il processo definito e restituiscono un risultato. Grazie a questa natura, riducono i costi di manutenzione e sono altamente scalabili senza grandi sforzi. Tuttavia, è difficile svolgere attività di lunga durata utilizzando questi componenti.

I Vantaggi dell’Architettura Serverless

Ecco i principali vantaggi dell’architettura serverless:

• Le app serverless sono altamente e facilmente scalabili. Possono anche adattarsi al traffico in arrivo in tempo reale per ridurre il carico sull’infrastruttura.
• Queste app possono sfruttare il modello di prezzo pay-per-use delle piattaforme serverless per ridurre i costi dell’infrastruttura.
• Le app serverless sono piuttosto facili da costruire e da distribuire, perché tutto ciò che dovete fare è scrivere una funzione e ospitarla su una piattaforma come Firebase functions, AWS Lambda, ecc.

Contro dell’Architettura Serverless

Di seguito sono elencati alcuni degli svantaggi dell’architettura serverless:

• Le attività di lunga durata possono essere costose su questa architettura.
• Quando una funzione riceve una richiesta dopo molto tempo, si parla di avvio a freddo. Gli avvii a freddo sono lenti e possono creare un’esperienza negativa per l’utente finale.

Livelli dell’Architettura delle Applicazioni Web

Anche se le architetture delle applicazioni web che avete visto sopra possono sembrare tutte molto diverse tra loro, i loro componenti possono essere logicamente raggruppati in livelli definiti che aiutano a raggiungere un obiettivo aziendale.

Livello Presentazione

Il livello presentazione rappresenta tutto ciò che in un’applicazione web è esposto agli utenti finali. Principalmente, il livello presentazione è composto dal client front-end. Tuttavia, incorpora anche la logica che avete scritto nel backend per rendere dinamico il front-end. In questo modo potete offrire agli utenti un’interfaccia utente personalizzata in base al loro profilo e alle loro esigenze.

Per costruire questo livello vengono utilizzate tre tecnologie fondamentali: HTML, CSS e JavaScript. L’HTML disegna il tuo frontend, il CSS lo stilizza e il JS lo anima (cioè ne controlla il comportamento quando gli utenti interagiscono con esso). Oltre a queste tre tecnologie, potete usare qualsiasi tipo di framework per facilitare lo sviluppo. Alcuni framework front-end comuni sono Laravel, React, NextJS, Vue, GatsbyJS, ecc.

Livello Business

Il livello business è responsabile della gestione della logica di funzionamento dell’applicazione. Di solito è un servizio di backend che accetta le richieste del cliente e le elabora. Controlla ciò a cui l’utente può accedere e determina come l’infrastruttura viene utilizzata per servire le richieste degli utenti.

Nel caso di un’app di prenotazione alberghiera, l’applicazione client funge da portale per gli utenti che possono digitare i nomi degli hotel e altri dati rilevanti. Tuttavia, non appena l’utente fa clic sul pulsante di ricerca, il livello business riceve la richiesta e avvia la logica di ricerca delle camere d’albergo disponibili che corrispondono ai vostri requisiti. Il cliente riceve quindi un elenco di camere d’albergo senza sapere come è stato generato o perché le voci dell’elenco sono disposte nel modo in cui sono state inviate.

La presenza di questo livello garantisce che la logica aziendale non sia esposta al cliente e, in ultima analisi, agli utenti. L’isolamento della logica aziendale è di grande aiuto in operazioni delicate come la gestione dei pagamenti o dei dati sanitari.

Livello Persistenza

Il livello persistenza è responsabile del controllo dell’accesso ai vostri archivi di dati. Agisce come un ulteriore livello di astrazione tra i vostri archivi di dati e il vostro livello di business. Riceve tutte le chiamate relative ai dati dai livelli di business e le elabora creando connessioni sicure al database.

Questo livello consiste solitamente in un server di database. Potete creare questo livello da soli, installando un database e un server di database nella vostra infrastruttura on-premise oppure optare per una soluzione remota/gestita da uno dei principali fornitori di infrastrutture cloud come AWS, GCP, Microsoft Azure, ecc.

Componenti dell’Applicazione Web

Ora che avete capito cosa c’è dietro l’architettura di un’applicazione web, diamo uno sguardo dettagliato a ciascuno dei componenti che compongono un’applicazione web. Raggrupperemo questa discussione in due voci 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 nel backend della vostra applicazione web. Non sono esposti direttamente agli utenti e contengono la logica aziendale e le risorse più importanti della vostra applicazione web.

DNS e Routing

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

Il load balancing è un altro componente molto diffuso nell’architettura delle applicazioni web. Un load balancer viene utilizzato per distribuire le richieste HTTP tra più server web identici. L’intento di avere più server web è quello di mantenere una ridondanza che aiuti ad aumentare la tolleranza agli errori e a distribuire il traffico per mantenere alte le prestazioni.

Gli endpoint API sono utilizzati per esporre i servizi backend all’applicazione frontend. Questi aiutano a facilitare la comunicazione tra il client e il server e talvolta anche tra più server.

Memorizzazione dei Dati

L’archiviazione dei dati è una parte cruciale della maggior parte delle applicazioni moderne, poiché ci sono sempre dei dati dell’applicazione che devono essere conservati durante le sessioni dell’utente. L’archiviazione dei dati è di due tipi:

• Database: I database sono utilizzati per memorizzare i dati e accedervi rapidamente. Di solito, permettono di memorizzare una piccola quantità di dati a cui l’applicazione accede regolarmente.
• Data Warehouse: I data warehouse sono destinati alla conservazione dei dati storici. Di solito non vengono utilizzati molto spesso nell’applicazione, ma vengono elaborati regolarmente per generare informazioni di business.

Caching

Il caching è una funzione opzionale spesso implementata nelle architetture delle applicazioni web per servire più velocemente i contenuti agli utenti. Gran parte dei contenuti delle app sono spesso ripetitivi per un certo periodo di tempo, se non sempre. Invece di accedervi da un archivio di dati ed elaborarli prima di inviarli all’utente, spesso vengono messi in cache. Ecco i due tipi più diffusi di caching utilizzati nelle applicazioni web:

• Caching dei dati: il caching dei dati introduce un modo per consentire alla vostra applicazione di accedere facilmente e rapidamente ai dati utilizzati regolarmente che non cambiano spesso. Tecnologie come Redis e Memcache consentono di memorizzare i dati nella cache per evitare costose interrogazioni al database per recuperare sempre gli stessi dati.
• Caching delle pagine web: una CDN (Content Delivery Network) mette in cache le pagine web nello stesso modo in cui Redis mette in cache i dati. Analogamente 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 applicazioni web renderizzate sul lato server, la cache non è molto utile perché il loro contenuto dovrebbe essere altamente dinamico.

Lavori e Servizi

Oltre a esporre un’interfaccia agli utenti (front-end) e a gestire le loro richieste (back-end), esiste un’altra categoria di componenti delle applicazioni web un po’ meno popolare. I lavori sono spesso servizi in background che hanno lo scopo di completare attività non sensibili al tempo o sincrone.

I lavori CRON sono quelli che vengono eseguiti ripetutamente in un periodo di tempo prestabilito. Questi lavori sono programmati sul back-end per eseguire automaticamente le routine di manutenzione a orari prestabiliti. Alcuni casi d’uso comuni sono l’eliminazione di duplicati o vecchi record dal database, l’invio di email di promemoria ai clienti, ecc.

Componenti Lato Client

I componenti lato client sono quelli 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 della vostra applicazione. È ciò che gli utenti vedono e con cui interagiscono per accedere ai vostri servizi.

L’interfaccia front-end si basa principalmente su tre tecnologie popolari: HTML, CSS e JavaScript. L’interfaccia utente front-end può essere un’applicazione a sé stante con un proprio ciclo di vita di sviluppo del software.

Queste interfacce utente non ospitano molta logica aziendale perché sono esposte direttamente agli utenti. Se un utente malintenzionato cerca di decodificare la vostra applicazione front-end, può ottenere informazioni sul funzionamento della vostra azienda e svolgere attività illegali come l’impersonificazione del marchio e il furto di dati.

Inoltre, poiché l’interfaccia utente del front-end è esposta direttamente agli utenti, dovrete ottimizzarla per ridurre al minimo i tempi di caricamento e la reattività. A volte questo può aiutarvi a fornire un’esperienza migliore ai vostri utenti, aumentando così la crescita della vostra attività.

Logica Aziendale Lato Client

A volte potreste aver bisogno di memorizzare alcune logiche aziendali sul vostro client per eseguire rapidamente operazioni più semplici. La logica lato client che di solito risiede all’interno della vostra applicazione front-end può aiutarvi a saltare il viaggio verso il server e a fornire ai vostri utenti un’esperienza più veloce.

Si tratta di una funzione opzionale dei componenti lato client. In alcuni casi, la logica di business dell’applicazione è memorizzata interamente sul lato client (soprattutto quando si costruisce senza un server back-end tradizionale). Le soluzioni moderne come BaaS vi permettono di accedere a operazioni comuni come l’autenticazione, l’archiviazione dei dati, l’archiviazione dei file e così via, in movimento nella vostra app frontend.

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

Modelli di Componenti per Applicazioni Web

Esistono diversi modelli di architetture di applicazioni web, ognuno dei quali si basa sul modo in cui i server web si connettono ai loro archivi di dati.

Un Server, un Database

Il modello più semplice è quello di un server web che si connette a un’istanza di database. Questo modello è facile da implementare e da mantenere e anche la messa in produzione è piuttosto semplice.

Grazie alla sua semplicità, questo modello è adatto per l’apprendimento e per piccole applicazioni sperimentali che non saranno esposte a un traffico elevato. Chi è alle prime armi con lo sviluppo web può configurare facilmente e smanettare con queste applicazioni per imparare i fondamenti dello sviluppo di applicazioni web.

Tuttavia, questo modello non dovrebbe essere utilizzato in produzione perché è altamente inaffidabile. Un problema al server o al database può causare tempi di inattività e perdite economiche.

Server Multipli, un Database

Questo modello porta l’applicazione a un livello più alto, impostando 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 evitare ciò, i server web sono progettati per essere stateless. Ciò significa che i server non conservano i dati tra le varie sessioni, ma si limitano a elaborarli e a memorizzarli nel database.

Le applicazioni realizzate con questo modello sono sicuramente più affidabili di quelle realizzate con il modello precedente, poiché la presenza di più server web aumenta la tolleranza agli errori dell’applicazione web. Tuttavia, poiché il database è ancora un’istanza comune, è l’anello più debole dell’architettura e può essere fonte di guasti.

Server Multipli, Database Multipli

Questo modello è uno dei più comuni e tradizionali per la progettazione di applicazioni web.

In questo caso, la logica dell’applicazione viene distribuita su più istanze identiche di server web raggruppate dietro un load balancer. Anche l’archivio dati viene gestito su più istanze di database per una maggiore tolleranza agli errori.

Potete anche scegliere di suddividere il vostro database tra le istanze disponibili per migliorare le prestazioni o di mantenere duplicati dell’intero archivio dati per ridondanza. In entrambi i casi, il guasto di un’istanza del database non comporterà l’interruzione completa dell’applicazione.

Questo modello è molto apprezzato per la sua affidabilità e scalabilità. Tuttavia, lo sviluppo e la manutenzione delle applicazioni che usano questo modello sono relativamente complicati e richiedono sviluppatrici e sviluppatori esperti e costosi. Per questo motivo, questo modello è consigliato solo quando si tratta di costruire su larga scala.

Servizi per le App

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

Il modello dei servizi applicativi suddivide un’applicazione in moduli più piccoli basati sulle funzionalità aziendali. Questi moduli possono essere piccoli come una funzione o grandi come un servizio.

L’idea è quella di rendere ogni funzionalità aziendale indipendente e scalabile. Ciascuno di questi moduli può connettersi al database in modo autonomo. Potete anche avere istanze di database dedicate per soddisfare le esigenze di scalabilità dei vostri moduli.

Tra le applicazioni 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 applicazioni costruite su questo modello richiede un lavoro di sviluppo esperto, soprattutto da parte di professionisti con esperienza in DevOps e CI/CD.

Le Migliori Pratiche per l’Architettura delle Applicazioni Web

Ecco alcune best practice che potete implementare nel vostro progetto di applicazione web per ottenere il massimo dall’architettura di web app che avete scelto.

1. Rendere il Front-End Responsive

Questo punto non sarà mai sottolineato abbastanza: puntate sempre su un front-end responsive. Non importa quanto sia grande e complessa la vostra web app al suo interno, è tutta esposta ai vostri utenti attraverso le pagine web, le app e le schermate del frontend.

Se i vostri utenti trovano queste schermate poco intuitive o lente, non resteranno a lungo a guardare e ammirare la meraviglia ingegneristica che è la vostra web app.

Per questo motivo, progettare front-end accessibili, facili da usare e leggeri è molto importante.

Sul web sono disponibili numerose best practice UI/UX che vi aiutano a capire cosa funziona meglio per i vostri utenti. Potete trovare professionisti in grado di realizzare progetti e architetture di facile utilizzo che consentano ai vostri utenti di sfruttare al meglio le app.

Vi consigliamo di pensare seriamente alla reattività del vostro front-end prima di distribuire il prodotto ai vostri utenti.

2. Monitorare i Tempi di Caricamento

Oltre a essere facile da capire, il front-end deve anche essere veloce da caricare.

Secondo Portent, i tassi di conversione più elevati nell’e-commerce si verificano su pagine con tempi di caricamento compresi tra 0 e 2 secondi e, secondo Unbounce, circa il 70% dei consumatori ammette che il tempo di caricamento delle pagine è un fattore importante nella scelta di acquistare da un venditore online.

Quando si progettano applicazioni mobile-native, di solito non si può essere certi delle specifiche del dispositivo degli utenti. Tutti i dispositivi che non soddisfano i requisiti della vostra applicazione sono in genere dichiarati non supportati dall’applicazione.

Tuttavia, la situazione è molto diversa nel caso del web.

Quando si tratta di applicazioni web, i vostri utenti potrebbero utilizzare qualsiasi dispositivo, dai più recenti Macbook M1 Pro di Apple ai telefoni Blackberry e Nokia vintage, per visualizzare la vostra applicazione. Ottimizzare l’esperienza del frontend per una gamma così ampia di utenti può essere a volte difficile.

Quando si parla di prestazioni del frontend, vengono in mente servizi come LightHouse e Google PageSpeed. Dovreste usare questi strumenti per effettuare un benchmark della vostra applicazione frontend prima di distribuirla in produzione. La maggior parte di questi strumenti vi fornisce un elenco di suggerimenti utili per migliorare il più possibile le prestazioni della vostra applicazione.

L’ultimo 5-10% delle prestazioni dell’applicazione è solitamente specifico del vostro caso d’uso e può essere risolto solo da chi conosce bene la vostra applicazione e le sue tecnologie. Investire nelle prestazioni del web non fa mai male!

3. Preferire le PWA Quando Possibile

Come già detto, le PWA sono il design del futuro. Si adattano bene alla maggior parte dei casi d’uso e offrono l’esperienza più uniforme sulle principali piattaforme.

Dovreste prendere in considerazione l’utilizzo di PWA per la vostra app il più frequentemente possibile. L’esperienza nativa su web e mobile è di grande impatto per i vostri utenti e può ridurre anche il vostro carico di lavoro.

Le PWA sono anche veloci da caricare, facili da ottimizzare e rapide da costruire. Optare per le PWA può aiutarvi a spostare molto della vostra attenzione dallo sviluppo al business fin da subito.

Mantenere la Codebase Pulita e Sintetica

Una codebase pulita può aiutarvi a individuare e risolvere la maggior parte dei problemi prima che causino danni. Ecco alcuni consigli che potete seguire per assicurarvi che la vostra codebase non vi crei più problemi del dovuto.

• Concentratevi sul riutilizzo del codice: Mantenere copie dello stesso codice in tutta la codebase non solo è ridondante, ma può anche causare discrepanze, rendendo la codebase difficile da mantenere. Concentratevi sempre sul riutilizzo del codice, laddove possibile.
• Pianificate la struttura del progetto: I progetti software possono diventare molto grandi con il passare del tempo. Se non iniziate con una struttura pianificata dell’organizzazione del codice e delle risorse, potreste finire per passare più tempo a cercare file che a scrivere codice utile.
• Scrivete test unitari: Ogni pezzo di codice può rompersi. Testare tutto manualmente non è fattibile, quindi avete bisogno di una strategia fissa per automatizzare i test della vostra codebase. I test runner e gli strumenti di copertura del codice possono aiutarvi a capire se i vostri sforzi di test delle unità stanno dando i risultati desiderati.
• Alta modularità: Quando scrivete del codice, concentratevi sempre sulla modularità. Scrivere codice strettamente legato ad altri pezzi di codice rende difficile testarlo, riutilizzarlo e modificarlo quando necessario.

5. Automatizzare i Processi CI/CD

CI/CD è l’acronimo di Continuous Integration/Continuous Deployment. I processi CI/CD sono fondamentali per lo sviluppo della vostra applicazione perché vi aiutano a costruire, testare e distribuire il vostro progetto con facilità.

Tuttavia, non vi conviene eseguire manualmente ogni volta. Dovreste invece creare delle pipeline che si attivino automaticamente in base alle attività del progetto. Per esempio, potete impostare una pipeline che esegua automaticamente i test ogni volta che eseguite il commit del codice sul sistema di controllo della versione. Esistono anche molti casi d’uso più complessi, come la generazione di artefatti multipiattaforma dal vostro repository di codice ogni volta che viene creata una release.

Le possibilità sono infinite, quindi sta a voi capire come sfruttare al meglio le vostre pipeline CI/CD.

6. Incorporare Funzioni di Sicurezza

La maggior parte delle app moderne è composta da più componenti. Prendiamo per esempio la seguente applicazione:

Le richieste dei clienti vengono inoltrate all’app attraverso un gateway API. Sebbene al momento consenta solo richieste dirette al modulo iniziale dell’app, in futuro potrebbe consentire l’accesso a più componenti senza passare per il modulo iniziale.

Successivamente, il modulo home controlla un BaaS di autenticazione esterno prima di consentire l’accesso. Una volta autenticato, il cliente può accedere alle pagine “Aggiorna profilo” o “Visualizza profilo”. Entrambe le pagine interagiscono con un database comune e gestito che gestisce i dati del profilo.

Come potete vedere, l’applicazione sembra una versione molto semplice e minimale di un elenco di persone online. Potete aggiungere/aggiornare il vostro profilo o visualizzare gli altri profili disponibili.

Ecco una rapida legenda dei vari componenti dell’architettura:

• Blue boxes: Moduli dell’app, che possono essere ospitati come microservizi o funzioni serverless.
• Red boxes: Componenti BaaS esterni che forniscono l’autenticazione e il database.
• Green box: Componente di routing che modera le richieste in arrivo dal client.
• Black box: La vostra applicazione client esposta all’utente.

I componenti di ciascun colore sono vulnerabili a vari tipi di minacce alla sicurezza. Ecco alcuni costrutti di sicurezza che potete adottare per ridurre al minimo la vostra esposizione:

• Moduli dell’app (blu): Poiché si tratta di funzioni serverless, ecco alcuni consigli per rafforzarne la sicurezza:
  • Isolate i segreti dell’applicazione e gestirli indipendentemente dal codice sorgente
  • Mantenete il controllo degli accessi attraverso i servizi IAM
  • Migliorate i vostri sforzi di testing per cercare anche le minacce alla sicurezza attraverso tecniche come il SAST
• Servizi esterni (red):
  • Impostate i controlli di accesso attraverso i loro moduli IAM per regolare l’accesso
  • Optate per la limitazione della velocità delle API
  • Per servizi come i database, impostate permessi di controllo più precisi, come per esempio chi può accedere ai dati dei profili, chi può visualizzare i dati degli utenti e altro ancora. Molti servizi, come Firebase, forniscono una serie dettagliata di regole di questo tipo.
• Componente di routing (green):
  • Come tutti gli altri componenti, implementate i controlli di accesso
  • Impostate l’autorizzazione
  • Ricontrollate le migliori pratiche standard, come il CORS
• Client:
  • Assicuratevi che nessun segreto dell’applicazione sia disponibile per il vostro client
  • Offuscate il codice del vostro client per ridurre al minimo le possibilità di reverse engineering

Sebbene si tratti solo di una manciata di suggerimenti, essi servono a far capire che la sicurezza delle app è complicata ed è vostra responsabilità assicurarvi di non lasciare nulla di intentato agli aggressori. Non potete affidarvi a un componente di sicurezza centrale per proteggere la vostra azienda; la sicurezza delle app è distribuita all’interno della vostra architettura.

7. Raccogliere il Feedback degli Utenti

Il feedback degli utenti è uno strumento fondamentale per capire quanto la vostra app stia funzionando bene in termini di prestazioni commerciali e tecniche. Potete costruire l’app più leggera e fluida del mondo, ma se non permette ai vostri utenti di fare ciò che si aspettano, tutti i vostri sforzi andranno sprecati.

Esistono diversi modi per raccogliere i feedback degli utenti. Sebbene un sondaggio rapido e anonimo sia l’approccio tradizionale, potete anche optare per una soluzione più sofisticata, come una mappa di calore dell’attività dei vostri utenti.

La scelta del metodo di raccolta dei feedback è meno importante dell’azione da intraprendere in base ai feedback raccolti. I clienti amano le aziende che ascoltano i loro problemi. Giganti come McDonald’s e Tesla lo fanno e questo è uno dei motivi per cui continuano ad avere successo nei loro mercati.

Riepilogo

Il web è un enorme parco giochi con una grande varietà di applicazioni, ognuna progettata in modo unico. Diversi tipi di architetture fanno sì che le applicazioni web si diversifichino, prosperino e offrano servizi agli utenti di tutto il mondo.

In questa guida abbiamo analizzato i diversi modelli di architettura delle applicazioni web e vi abbiamo mostrato quanto siano fondamentali per la crescita di un’applicazione.

C’è un’architettura per web app che vi è piaciuta molto? Oppure ce n’è un’altra che vorreste condividere con il mondo? Fatecelo sapere nei commenti qui sotto!