031.2 Lezione 1

Ci sono applicazioni mobile e desktop la cui interfaccia è resa tramite HTML e, come i browser, possono usare JavaScript come linguaggio di programmazione. Tuttavia, a differenza del client caricato nel browser, l’HTML e i componenti necessari al funzionamento del client nativo sono presenti localmente dall’installazione dell’applicazione. Un’applicazione che funziona in questo modo è virtualmente identica a una pagina HTML (è persino probabile che entrambe siano rese dallo stesso motore). Ci sono anche le progressive web apps (PWA), che permettono di “impacchettare” i client delle applicazioni web per l’uso offline - limitatamente alle funzioni che non richiedono una comunicazione immediata con il server. Per quanto riguarda ciò che l’applicazione può fare, non c’è differenza tra l’esecuzione nel browser o confezionata in una PWA, tranne che in quest’ultima lo sviluppatore ha più controllo su ciò che viene memorizzato localmente.

Il rendering delle interfacce HTML è un’attività così ricorrente che il motore è di solito un componente software separato, presente nel sistema operativo. La sua presenza come componente separato permette ad applicazioni diverse di incorporarlo senza doverlo incorporare nel pacchetto dell’applicazione. Questo modello delega anche la manutenzione del motore di rendering al sistema operativo, facilitando gli aggiornamenti. È molto importante mantenere aggiornato un componente così cruciale per evitare possibili problematiche.

Indipendentemente dal loro metodo di consegna, le applicazioni scritte in HTML girano su un livello di astrazione creato dal motore, che funziona come un ambiente di esecuzione isolato. In particolare, nel caso di un client che gira sul browser, l’applicazione ha a disposizione solo le risorse offerte dal browser. Le funzionalità di base, come l’interazione con gli elementi della pagina e la richiesta di file tramite HTTP, sono sempre disponibili. Le risorse che possono contenere informazioni sensibili, come l’accesso ai file locali, la posizione geografica, la fotocamera e il microfono, richiedono l’autorizzazione esplicita dell’utente prima che l’applicazione sia in grado di utilizzarle.

L’elemento centrale di un client di un’applicazione web che gira sul server è il documento HTML. Oltre a presentare gli elementi dell’interfaccia che il browser visualizza in modo strutturato, il documento HTML contiene gli indirizzi di tutti i file necessari per la corretta presentazione e funzionamento del client.

L’HTML da solo non ha molta versatilità per costruire interfacce più elaborate e non ha caratteristiche di programmazione generale. Per questo motivo, un documento HTML che deve funzionare come applicazione client è sempre accompagnato da uno o più set di CSS e JavaScript.

Il CSS (Cascading Style Sheets) può essere fornito come file separato o direttamente nel file HTML stesso. Lo scopo principale dei CSS è quello di regolare l’aspetto e la disposizione degli elementi dell’interfaccia HTML. Anche se non è strettamente necessario, le interfacce più sofisticate di solito richiedono modifiche alle proprietà CSS degli elementi per soddisfare le loro esigenze.

JavaScript è un componente praticamente indispensabile. Le procedure scritte in JavaScript rispondono a eventi nel browser. Questi eventi possono essere causati dall’utente e non. Senza JavaScript, un documento HTML è praticamente limitato al testo e alle immagini. L’uso di JavaScript nei documenti HTML permette di estendere l’interattività oltre i collegamenti ipertestuali e i moduli, rendendo la pagina visualizzata dal browser come un’interfaccia di applicazione convenzionale.

JavaScript è un linguaggio di programmazione genico, ma il suo uso principale è nelle applicazioni web. Le caratteristiche dell’ambiente di esecuzione del browser sono accessibili attraverso parole chiave JavaScript, utilizzate in uno script per eseguire l’operazione desiderata. Il termine document, per esempio, è usato nel codice JavaScript per riferirsi al documento HTML associato al codice JavaScript. Nel contesto del linguaggio JavaScript, document è un oggetto globale con proprietà e metodi che possono essere usati per ottenere informazioni da qualsiasi elemento del documento HTML. Ancora più importante, si può usare l’oggetto document per modificare i suoi elementi e associarli ad azioni personalizzate scritte in JavaScript.

Un’applicazione client basata su tecnologie web è multipiattaforma, perché può essere eseguita su qualsiasi dispositivo che abbia un browser web compatibile.

Essere confinati al browser, tuttavia, impone limitazioni alle applicazioni web rispetto alle applicazioni native. L’intermediazione effettuata dal browser permette una programmazione di livello superiore e aumenta la sicurezza, ma aumenta anche l’elaborazione e il consumo di memoria.

Gli sviluppatori lavorano continuamente sui browser per fornire più funzioni e migliorare le prestazioni delle applicazioni JavaScript, ma ci sono aspetti intrinseci all’esecuzione di script come JavaScript che impongono uno svantaggio rispetto ai programmi nativi per lo stesso hardware.

Una caratteristica che migliora significativamente le prestazioni delle applicazioni JavaScript in esecuzione sul browser è WebAssembly. WebAssembly è un tipo di JavaScript compilato che produce codice sorgente scritto in un linguaggio più efficiente e di livello inferiore, come il linguaggio C. WebAssembly può accelerare principalmente le attività ad alta intensità di processore, perché evita gran parte della traduzione eseguita dal browser quando si esegue un programma scritto in JavaScript convenzionale.

Indipendentemente dai dettagli di implementazione dell’applicazione, tutto il codice HTML, CSS, JavaScript e i file multimediali devono prima essere ottenuti dal server. Il browser ottiene questi file proprio come una pagina Internet, cioè con un indirizzo a cui il browser accede.

Una pagina web che funge da interfaccia per un’applicazione web è come un semplice documento HTML, ma aggiunge ulteriori comportamenti. Nelle pagine convenzionali l’utente viene indirizzato a un’altra pagina dopo aver cliccato su un link. Le applicazioni web possono presentare la loro interfaccia e rispondere agli eventi dell’utente senza caricare nuove pagine nella finestra del browser. La modifica di questo comportamento standard nelle pagine HTML viene fatta tramite la programmazione JavaScript.

Un client webmail, per esempio, visualizza i messaggi e passa da una cartella all’altra senza lasciare la pagina. Questo è possibile perché il client usa JavaScript per reagire alle azioni dell’utente e fare richieste appropriate al server. Se l’utente clicca sull’oggetto di un messaggio nella posta in arrivo, un codice JavaScript associato a questo evento richiede il contenuto di quel messaggio al server (usando la chiamata API corrispondente). Non appena il client riceve la risposta, il browser visualizza il messaggio nella porzione appropriata della stessa pagina. Diversi client webmail possono adottare strategie diverse, ma tutti usano questo stesso principio.

Quindi, oltre a fornire i file che compongono il client al browser, il server deve anche essere in grado di gestire richieste come quella del client webmail, quando chiede il contenuto di un messaggio specifico. Ogni richiesta che il client può fare ha una procedura predefinita per rispondere sul server, le cui API possono definire diversi metodi per identificare a quale procedura si riferisce la richiesta. I metodi più comuni sono:

Un metodo può essere più adatto di un altro, a seconda dello scopo della richiesta e di altri criteri presi in considerazione dallo sviluppatore. In generale, le applicazioni web utilizzano una combinazione di metodi, ognuno in una circostanza specifica.

Il paradigma Representational State Transfer (REST) è ampiamente utilizzato per la comunicazione nelle applicazioni web, perché si basa sui metodi di base disponibili in HTTP. L’intestazione di una richiesta HTTP inizia con una parola chiave che definisce l’operazione di base da eseguire: GET, POST, PUT, DELETE, ecc., accompagnata da un URL corrispondente dove l’azione sarà applicata. Se l’applicazione richiede operazioni più specifiche, con una descrizione più dettagliata dell’operazione richiesta, il protocollo GraphQL può essere una scelta più appropriata.

Le applicazioni sviluppate utilizzando il modello client/server sono soggette a instabilità nella comunicazione. Per questo motivo, l’applicazione client deve sempre adottare strategie di trasferimento dati efficienti per favorire la sua coerenza e non danneggiare l’esperienza dell’utente.

I server HTTP, come Apache e NGINX, di solito richiedono modifiche di configurazione specifiche per soddisfare le esigenze dell’applicazione. Per impostazione predefinita, i server HTTP tradizionali associano direttamente il percorso indicato nella richiesta a un file sul file system locale. Se il server HTTP di un sito web mantiene i suoi file HTML nella directory /srv/www, per esempio, una richiesta con il percorso /it/about.html riceverà come risposta il contenuto del file /srv/www/it/about.html, se il file esiste. Siti web più sofisticati, e specialmente applicazioni web, richiedono trattamenti personalizzati per diversi tipi di richieste. In questo scenario, parte dell’implementazione dell’applicazione consiste nel modificare le impostazioni del server HTTP per soddisfare i requisiti dell’applicazione.

In alternativa ci sono framework che permettono di integrare la gestione delle richieste HTTP e l’implementazione del codice dell’applicazione in un unico luogo, permettendo allo sviluppatore di concentrarsi più sullo scopo dell’applicazione che sui dettagli della piattaforma. In Node.js Express, per esempio, tutta la mappatura delle richieste e la programmazione corrispondente sono implementate utilizzando JavaScript. Dato che la programmazione dei client è di solito fatta in JavaScript, molti sviluppatori considerano una buona idea dal punto di vista della manutenzione del codice usare lo stesso linguaggio per client e server. Altri linguaggi comunemente usati per implementare la parte server, sia nei framework che nei tradizionali server HTTP, sono PHP, Python, Ruby, Java e C#.

Sta alla discrezione del team di sviluppo come i dati ricevuti o richiesti dal client vengono memorizzati sul server, ma ci sono linee guida generali che si applicano alla maggior parte dei casi. È conveniente mantenere il contenuto statico - immagini, codice JavaScript e CSS che non cambiano a breve termine - come file convenzionali, o sul file system del server o distribuito attraverso una content delivery network (CDN). Altri tipi di contenuto, come i messaggi di posta elettronica in un’applicazione webmail, i dettagli dei prodotti in un’applicazione di shopping, e i log delle transazioni, sono più convenientemente memorizzati in un database management system (DBMS).

Il tipo più tradizionale di sistema di gestione di database è la base di dati relazionale. In esso, il progettista dell’applicazione definisce le tabelle di dati e il formato di input accettato da ogni tabella. L’insieme delle tabelle nel database contiene tutti i dati dinamici consumati e prodotti dall’applicazione. Un’applicazione di shopping, per esempio, può avere una tabella che contiene una voce con i dettagli di ogni prodotto nel negozio e una tabella che registra gli articoli acquistati da un utente. La tabella degli articoli acquistati contiene riferimenti alle voci della tabella dei prodotti, creando relazioni tra le tabelle. Questo approccio può ottimizzare l’immagazzinamento e l’accesso ai dati, oltre a permettere interrogazioni in tabelle combinate usando il linguaggio adottato dal sistema di gestione del database. Il linguaggio di database relazionale più popolare è lo Structured Query Language (SQL, pronunciato “sequel”), adottato dai database open source SQLite, MySQL, MariaDB e PostgreSQL.

Un’alternativa ai database relazionali è una forma di database che non richiede una struttura rigida per i dati. Questi database sono chiamati database non relazionali o semplicemente NoSQL. Anche se possono incorporare alcune caratteristiche simili a quelle che si trovano nei database relazionali, l’obiettivo è quello di consentire una maggiore flessibilità nella memorizzazione e l’accesso ai dati memorizzati, passando il compito di elaborare tali dati all’applicazione stessa. MongoDB, CouchDB e Redis sono comuni sistemi di gestione di database non relazionali.