Capire l'architettura di una web app moderna: layer, pattern, stack tecnologici 2025 e come valutare la proposta di una software house prima di firmare.
Quando si commissiona o si valuta lo sviluppo di una web app, uno degli aspetti più sottovalutati è l'architettura. Non si tratta di un dettaglio tecnico riservato agli sviluppatori: l'architettura determina quanto sarà costoso manutenere l'applicazione tra un anno, quanto velocemente potrà crescere, e se sarà sicura.
Questa guida è pensata per manager, imprenditori e CTO di PMI che vogliono capire di cosa si parla quando una software house presenta la propria proposta tecnica.
Una web app moderna non è un monoblocco. È composta da layer distinti, ognuno con responsabilità precise.
È la parte visibile dell'applicazione, quella che l'utente vede e con cui interagisce nel browser. Può essere costruita come SPA (Single Page Application, dove il rendering avviene nel browser) o SSR (Server Side Rendering, dove l'HTML viene generato lato server prima di essere inviato al browser).
La scelta tra SPA e SSR dipende dal caso d'uso: le web app interne (gestionali, back-office) vanno benissimo come SPA; le applicazioni pubbliche con esigenze SEO beneficiano dell'SSR.
Il frontend non accede direttamente al database. Comunica con il backend tramite API, tipicamente REST o GraphQL. Le API definiscono le operazioni disponibili (crea un ordine, aggiorna un cliente, carica un documento) e sono il confine di sicurezza principale dell'applicazione.
Un'API ben progettata è versionate, documentata e protetta da autenticazione.
È il cuore dell'applicazione: le regole di business, i calcoli, i workflow, le validazioni. In un'architettura pulita questo layer è separato dal framework e testabile in isolamento. È anche la parte più specifica del tuo dominio aziendale: ciò che distingue il tuo software da uno generico.
Dove vivono i dati. La scelta tra database relazionale (PostgreSQL, MySQL) e non relazionale (MongoDB, Redis) dipende dalla natura dei dati. Per la maggior parte delle applicazioni aziendali, PostgreSQL è la scelta più solida: transazioni ACID, relazioni complesse, query potenti, maturità decennale.
Redis viene spesso usato in parallelo come cache (per risposta più veloce su dati letti frequentemente) e per gestire sessioni o code.
Chi può accedere e cosa può fare. L'autenticazione verifica l'identità (login), l'autorizzazione stabilisce i permessi (l'utente A può leggere ma non scrivere; il responsabile può approvare; l'admin può tutto).
JWT (JSON Web Token) è lo standard de facto per le API REST. La gestione dei refresh token e il loro ciclo di vita è un'area dove molte implementazioni hanno vulnerabilità.
Documenti, immagini, allegati, PDF: vanno su object storage (AWS S3, MinIO, Backblaze), non nel database e non sul filesystem del server applicativo. Questo garantisce scalabilità, backup e accesso da CDN.
Le operazioni lente o asincrone (invio email, generazione PDF, import CSV, elaborazione immagini) non devono bloccare la risposta HTTP. Vengono messe in coda e processate da worker separati. Strumenti comuni: Celery (Python), BullMQ (Node.js), Redis come broker.
Senza osservabilità, un'applicazione in produzione è una scatola nera. Logging strutturato (chi ha fatto cosa e quando), metriche di performance (latenza, throughput, error rate), alerting (notifica se il tasso di errori supera una soglia): questi strumenti non sono opzionali in un ambiente professionale.
Manutenibilità: un'architettura chiara permette a un nuovo sviluppatore di orientarsi in pochi giorni. Un sistema senza separazione di responsabilità diventa rapidamente ingestibile.
Scalabilità: non significa "reggere milioni di utenti". Per una PMI significa poter aggiungere funzionalità senza riscrivere tutto, e poter scalare orizzontalmente se i volumi crescono.
Sicurezza: la maggior parte delle vulnerabilità nasce da architetture mal progettate (dati sensibili esposti in API, mancanza di validazione lato server, gestione superficiale dei token).
Team velocity: un'architettura chiara permette a più sviluppatori di lavorare in parallelo senza bloccarsi a vicenda.
I microservizi sono l'architettura di Netflix, Amazon, Uber, aziende con team distribuiti di centinaia di sviluppatori, sistemi che devono scalare indipendentemente su componenti diverse, e l'infrastruttura per gestire tutto questo.
Per una PMI italiana che sviluppa un'applicazione gestionale o un portale B2B, i microservizi creano più problemi di quanti ne risolvano: complessità di deployment, latenza di rete inter-servizio, difficoltà nel mantenere consistenza dei dati, overhead operativo.
Il monolite modulare è l'alternativa intelligente: un'unica applicazione con moduli ben separati (auth, CRM, fatturazione, magazzino) che comunicano tramite interfacce interne chiare. Scala fino a team di 10-15 sviluppatori, è più semplice da debuggare e deployare, e può essere scomposto in microservizi in futuro se necessario.
Esistono decine di combinazioni possibili. Alcune hanno dimostrato affidabilità e maturità:
Stack web full-stack: Next.js (frontend SSR) + FastAPI o Node.js/Express (backend API) + PostgreSQL + Redis + S3-compatible storage. Questo stack copre il 90% delle esigenze applicative delle PMI con un ecosistema maturo, buona documentazione e ampia disponibilità di sviluppatori.
Stack più conservativo: server-side rendering con Django o Rails, utile per applicazioni con complessità di dominio alta e team con background backend.
Stack mobile-first: React Native o Flutter per il client, con un backend API condiviso.
La scelta dello stack non deve essere guidata dalla moda tecnologica ma dalla realtà del team, dalla natura del problema e dalla longevità prevista del sistema.
Quando una software house ti presenta la propria proposta tecnica, ecco le domande da fare:
Un'architettura solida non è visibile nell'interfaccia utente, ma si sente quando il sistema va in produzione, quando arriva il primo bug critico, e quando due anni dopo dovete aggiungere una funzionalità non prevista inizialmente.
Se vuoi discutere l'architettura di un progetto specifico, contattaci: siamo abituati a lavorare con manager non tecnici e a spiegare le scelte in modo comprensibile.
Tag
Domande frequenti
I microservizi sono la soluzione giusta per una PMI?
Quasi mai, almeno nelle prime fasi. I microservizi risolvono problemi di scala e di team distribuiti che la maggior parte delle PMI italiane non ha. Introducono invece complessità operativa significativa: service discovery, comunicazione inter-servizio, deployment distribuito, monitoraggio di più sistemi. Un monolite modulare ben strutturato scala fino a team di 10-15 sviluppatori senza problemi. La transizione ai microservizi, se mai necessaria, può avvenire in seguito su parti specifiche del sistema.
Quanto costa l'infrastruttura cloud di una web app?
Dipende dai volumi, ma per una PMI con un'applicazione interna o un portale a traffico moderato (fino a qualche centinaia di utenti attivi), l'infrastruttura cloud costa tra i 100 e i 500 euro al mese. Questo include server applicativo, database gestito, storage, backup e CDN. Con Nomad o Kubernetes su bare metal i costi fissi sono più alti inizialmente ma convengono su volumi elevati.
Come si garantisce la sicurezza dell'autenticazione?
Le pratiche fondamentali sono: password hashate con bcrypt o Argon2 (mai SHA256 o MD5), token JWT con scadenza breve (15-30 minuti) + refresh token a lunga scadenza con rotazione, HTTPS ovunque, rate limiting sui tentativi di login, e possibilmente MFA (autenticazione a più fattori) per utenti con accesso privilegiato. L'autenticazione non va mai implementata da zero: usare librerie testate (NextAuth, Auth.js, Keycloak, Auth0) riduce drasticamente il rischio.
Continua a leggere
La UX non è estetica: è la differenza tra un software che le persone usano volentieri e uno che sabota la produttività. Ecco perché le aziende B2B la sottovalutano e quanto costa questo errore.
Una landing page efficace non è questione di estetica. È una sequenza logica di elementi che guida il visitatore verso una decisione. Ecco come costruirla.
La distinzione non è solo tecnica: è strategica. Ecco come scegliere tra web app e app mobile basandoti su frequenza d'uso, accesso offline e budget.