Deployment di Applicazioni JavaScript

17 febbraio 2026

11 min di lettura

Introduzione

Dopo aver sviluppato e testato un’applicazione JavaScript, il passo successivo è renderla disponibile pubblicamente su Internet. Il processo di deployment varia a seconda del tipo di applicazione: applicazioni statiche (solo HTML, CSS, JavaScript) richiedono un hosting statico, mentre applicazioni con codice server-side (Node.js) necessitano di un server che possa eseguire JavaScript.

In questo capitolo si approfondiscono:

Tipi di applicazioni web: statiche vs dinamiche
Processo di deployment: build, ottimizzazione e pubblicazione
Static Hosting: deploy di applicazioni client-side con Firebase Hosting
Dynamic Hosting: deploy di applicazioni Node.js con Heroku
Configurazione: variabili d’ambiente, porta del server, file di configurazione

Tipi di Applicazioni Web

Applicazioni Statiche

Un’applicazione statica consiste solo di file che vengono serviti così come sono:

File HTML
File CSS
File JavaScript
Immagini e altri asset

Non c’è codice che viene eseguito sul server. Tutto il codice JavaScript viene eseguito nel browser dell’utente. Il server serve semplicemente i file quando vengono richiesti.

Caratteristiche:

Nessuna esecuzione di codice sul server
File serviti direttamente senza elaborazione
Veloce da servire (solo trasferimento file)
Limitato nelle funzionalità (nessun accesso a database, file system, ecc.)

Esempi: landing page, portfolio, applicazioni single-page che comunicano con API esterne.

Applicazioni Dinamiche

Un’applicazione dinamica include codice che viene eseguito sul server:

Codice server-side (Node.js, PHP, Python, ecc.)
Generazione dinamica di HTML
Accesso a database
Elaborazione di dati sul server

Il server esegue codice per generare risposte personalizzate per ogni richiesta.

Caratteristiche:

Codice eseguito sul server
Può generare contenuto dinamico
Accesso a database e file system
Richiede più risorse del server

Esempi: applicazioni e-commerce, social network, dashboard con dati personalizzati.

Single-Page Applications (SPA)

Le SPA sono un caso particolare di applicazioni statiche:

Un solo file HTML servito
JavaScript gestisce la navigazione e il rendering
Comunicazione con API esterne tramite richieste HTTP
Nessun codice eseguito sul server che serve l’applicazione

Anche se tecnicamente statiche, le SPA possono sembrare dinamiche grazie al JavaScript che gestisce tutto lato client.

Processo di Deployment

Fasi del Deployment

Il processo di deployment segue generalmente queste fasi:

1. Sviluppo Scrittura del codice, organizzazione in moduli, implementazione delle funzionalità.

2. Testing Verifica che il codice funzioni correttamente, test di funzionalità, correzione di bug.

3. Ottimizzazione Preparazione del codice per la produzione:

Minificazione del codice
Rimozione di codice non utilizzato (tree shaking)
Compressione di asset
Aggiunta di polyfills per supporto browser

4. Build per Produzione Generazione dei file ottimizzati pronti per il deployment. Con webpack, questo significa eseguire il build in modalità production.

5. Deployment Caricamento dei file generati sul server di hosting.

Build per Produzione: Client-Side

Per applicazioni client-side, il build è cruciale perché il codice viene scaricato dagli utenti:

npm run build:prod

Questo comando:

Combina tutti i file JavaScript in bundle ottimizzati
Minifica il codice (rimuove spazi, accorcia nomi di variabili)
Applica tree shaking per rimuovere codice non utilizzato
Genera file con content hash per cache busting

Risultato: file più piccoli = caricamento più veloce = migliore esperienza utente.

Build per Produzione: Server-Side

Per applicazioni Node.js, il build è meno critico perché:

Il codice non viene scaricato dagli utenti
Viene eseguito solo sul server
Le dimensioni del codice non influenzano le performance per gli utenti finali

Tuttavia, è comunque buona pratica:

Rimuovere codice di sviluppo e commenti
Verificare che non ci siano dipendenze di sviluppo incluse
Assicurarsi che il codice sia pronto per l’ambiente di produzione

Static Hosting: Firebase Hosting

Cos’è Firebase Hosting

Firebase Hosting è un servizio di Google che permette di ospitare applicazioni web statiche in modo semplice e veloce. Offre CDN globale, SSL automatico e integrazione con altri servizi Firebase.

Preparazione del Progetto

Prima di deployare, assicurarsi che il progetto sia buildato per produzione:

npm run build:prod

Questo genera i file ottimizzati nella cartella di output (tipicamente dist/ o build/).

Importante: aggiornare manualmente i riferimenti ai file JavaScript negli HTML se si usa content hash nei nomi dei file:

1
<!-- Prima del build -->
2
<script src="assets/scripts/app.js"></script>
3

4
<!-- Dopo il build (con content hash) -->
5
<script src="assets/scripts/app.a1b2c3d4.js"></script>

Installazione Firebase CLI

Firebase CLI è lo strumento a riga di comando per interagire con Firebase:

npm install -g firebase-tools

Su Linux e macOS potrebbe essere necessario sudo:

sudo npm install -g firebase-tools

Inizializzazione del Progetto

Navigare nella cartella del progetto e inizializzare Firebase:

firebase init

Durante l’inizializzazione:

Login: accedere con account Google o creare un account Firebase
Selezionare servizio: scegliere “Hosting”
Creare progetto: creare un nuovo progetto Firebase o selezionarne uno esistente
Public directory: specificare la cartella con i file da deployare (es. dist)
Single-page app: scegliere se configurare come SPA (redirect tutte le route a index.html)
Overwrite index.html: scegliere se sovrascrivere file esistenti

File di Configurazione

Dopo l’inizializzazione, Firebase crea due file:

firebase.json:

1
{
2
  "hosting": {
3
    "public": "dist",
4
    "ignore": [
5
      "firebase.json",
6
      "**/.*",
7
      "**/node_modules/**"
8
    ],
9
    "rewrites": [
10
      {
11
        "source": "**",
12
        "destination": "/index.html"
13
      }
14
    ]
15
  }
16
}

.firebaserc:

1
{
2
  "projects": {
3
    "default": "nome-progetto-firebase"
4
  }
5
}

Deploy

Una volta configurato, il deploy è semplice:

firebase deploy

Questo comando:

Carica tutti i file dalla cartella public (configurata in firebase.json)
Distribuisce i file sulla CDN globale di Firebase
Fornisce un URL pubblico per l’applicazione

Dopo il deploy, Firebase fornisce un URL tipo:

1
https://nome-progetto.firebaseapp.com

Aggiornare il Deploy

Per aggiornare l’applicazione dopo modifiche:

Eseguire di nuovo il build: npm run build:prod
Aggiornare riferimenti HTML se necessario
Eseguire: firebase deploy

Firebase sovrascrive i file precedenti con le nuove versioni.

Configurazioni Avanzate

Redirect e Rewrites:

1
{
2
  "hosting": {
3
    "rewrites": [
4
      {
5
        "source": "/api/**",
6
        "destination": "https://api.example.com/**"
7
      }
8
    ],
9
    "redirects": [
10
      {
11
        "source": "/old-page",
12
        "destination": "/new-page",
13
        "type": 301
14
      }
15
    ]
16
  }
17
}

Headers personalizzati:

1
{
2
  "hosting": {
3
    "headers": [
4
      {
5
        "source": "**/*.@(js|css)",
6
        "headers": [
7
          {
8
            "key": "Cache-Control",
9
            "value": "max-age=31536000"
10
          }
11
        ]
12
      }
13
    ]
14
  }
15
}

Dynamic Hosting: Heroku

Cos’è Heroku

Heroku è una piattaforma cloud che permette di deployare applicazioni con codice server-side senza gestire l’infrastruttura. Supporta Node.js, Python, Ruby, PHP e altri linguaggi.

Preparazione del Progetto Node.js

Prima di deployare su Heroku, il progetto Node.js deve essere configurato correttamente.

1. Script di Start in package.json:

1
{
2
  "scripts": {
3
    "start": "node app.js"
4
  }
5
}

Questo script dice a Heroku come avviare l’applicazione.

2. File Procfile (alternativa): Creare un file Procfile nella root del progetto (senza estensione):

1
web: node app.js

Il formato è: tipo-processo: comando. web indica che è un processo web che riceve traffico HTTP.

3. Porta Dinamica: Heroku assegna una porta dinamica. Il codice deve usare la variabile d’ambiente PORT:

1
const port = process.env.PORT || 3000;
2

3
app.listen(port, () => {
4
  console.log(`Server running on port ${port}`);
5
});

Se process.env.PORT non è definito (sviluppo locale), usa 3000. Su Heroku, process.env.PORT contiene la porta assegnata.

Installazione Heroku CLI

Scaricare e installare Heroku CLI dal sito ufficiale o tramite package manager:

# macOS con Homebrew
brew tap heroku/brew && brew install heroku

# Altri sistemi: scaricare installer dal sito Heroku

1. Login:

heroku login

Aprire il browser per autenticarsi o inserire credenziali nel terminale.

2. Creare App Heroku: Tramite dashboard web o CLI:

heroku create nome-app

Questo crea un’applicazione Heroku e aggiunge un remote Git.

Deploy con Git

Heroku usa Git per il deployment. Il processo è:

1. Inizializzare Git (se non già fatto):

git init

2. Aggiungere file:

git add .

3. Creare commit:

git commit -m "Initial commit"

4. Aggiungere remote Heroku:

heroku git:remote -a nome-app

5. Push a Heroku:

git push heroku main

Oppure, se si usa master:

git push heroku master

Processo di Build su Heroku

Quando si fa push a Heroku:

Heroku rileva che è un’app Node.js (presenza di package.json)
Esegue npm install per installare dipendenze
Cerca script start in package.json o Procfile
Avvia l’applicazione usando il comando trovato
Assegna una porta e rende l’app disponibile pubblicamente

Variabili d’Ambiente

Per configurazioni sensibili (credenziali database, API keys), usare variabili d’ambiente configurate su Heroku:

Tramite Dashboard:

Andare su Settings → Config Vars
Aggiungere variabili (es. DB_PASSWORD, API_KEY)

Tramite CLI:

heroku config:set DB_PASSWORD=secret123
heroku config:set API_KEY=abc123

Nel codice Node.js:

1
const dbPassword = process.env.DB_PASSWORD;
2
const apiKey = process.env.API_KEY;

Logs e Monitoring

Visualizzare logs dell’applicazione:

heroku logs --tail

Questo mostra i log in tempo reale, utile per debugging dopo il deployment.

Database e Servizi Esterni

Quando si deploya un’app Node.js che si connette a un database esterno (es. MongoDB Atlas):

1. Whitelist IP Addresses: Nel pannello di controllo del database, aggiungere gli IP di Heroku o permettere connessioni da qualsiasi IP:

1
0.0.0.0/0  (permetti tutti gli IP)

Nota: Heroku assegna IP dinamici, quindi spesso è necessario permettere tutti gli IP o usare un servizio che supporta connessioni da qualsiasi IP.

2. Usare Variabili d’Ambiente: Non hardcodare la connection string nel codice:

1
// ❌ Non fare
2
const connectionURL = 'mongodb+srv://user:pass@cluster.mongodb.net/db';
3

4
// ✅ Fare
5
const connectionURL = process.env.MONGODB_CONNECTION_STRING;

Configurare su Heroku:

heroku config:set MONGODB_CONNECTION_STRING="mongodb+srv://..."

Restart e Scaling

Restart dell’applicazione:

heroku restart

Scaling (numero di dyno):

heroku ps:scale web=1

Nel piano gratuito, è disponibile un solo dyno.

Best Practices per il Deployment

Pre-Deployment Checklist

Per Applicazioni Statiche:

Build eseguito in modalità production
File HTML aggiornati con nomi file corretti (se si usa content hash)
Test dell’applicazione con i file buildati localmente
Verifica che tutti gli asset siano inclusi
Controllo delle dimensioni dei bundle

Per Applicazioni Node.js:

Script start configurato in package.json o Procfile
Porta configurata per usare process.env.PORT
Variabili d’ambiente configurate sul servizio di hosting
Database e servizi esterni configurati (whitelist IP, credenziali)
Gestione errori implementata per evitare crash
Logging configurato per debugging

Gestione degli Errori

In produzione, è importante gestire gli errori per evitare che l’applicazione crashi:

1
// Gestione errori base
2
process.on('uncaughtException', (err) => {
3
  console.error('Uncaught Exception:', err);
4
  // Log su servizio di monitoring
5
  process.exit(1);
6
});
7

8
process.on('unhandledRejection', (reason, promise) => {
9
  console.error('Unhandled Rejection:', reason);
10
  // Log su servizio di monitoring
11
});

Monitoring e Logging

Dopo il deployment, monitorare l’applicazione:

Logs: verificare regolarmente i log per errori o comportamenti anomali
Performance: monitorare tempi di risposta e utilizzo risorse
Uptime: verificare che l’applicazione sia sempre disponibile
Errori: configurare alert per errori critici

Aggiornamenti e Rollback

Deploy di Aggiornamenti:

Testare le modifiche localmente
Eseguire build (se necessario)
Commit delle modifiche
Push a Heroku/Firebase
Verificare che tutto funzioni

Rollback (tornare a versione precedente):

# Heroku
heroku releases  # Vedi versioni precedenti
heroku rollback v123  # Torna a versione specifica

# Firebase
firebase hosting:clone SOURCE_SITE_ID:TARGET_SITE_ID

Confronto: Static vs Dynamic Hosting

Quando Usare Static Hosting

Vantaggi:

Più economico (spesso gratuito per progetti piccoli)
Più veloce (CDN globale, nessuna elaborazione server)
Più semplice da configurare
Scalabile automaticamente

Limiti:

Nessuna esecuzione di codice server-side
Nessun accesso diretto a database
Dipendenza da API esterne per dati dinamici

Servizi popolari: Firebase Hosting, AWS S3, Netlify, Vercel, GitHub Pages.

Quando Usare Dynamic Hosting