Applicazioni e Servizi Web è tenuto dalla prof.ssa Silvia Mirri ([email protected]); il tutor del corso, che segue le esercitazioni in laboratorio, è il dott. Manuel Andruccioli ([email protected]). Le lezioni si tengono il venerdì dalle 14:30 alle 17:30 in aula 2.5, le esercitazioni in laboratorio il mercoledì dalle 15:00 alle 17:00 in lab 4.2. Il ricevimento è prima o dopo la lezione del mercoledì e del venerdì, oppure su appuntamento. Il calendario prevede due sospensioni (da confermare): venerdì 17 ottobre e venerdì 28 novembre.
Tutto il materiale — slide di lezioni ed esercitazioni, forum, informazioni sugli elaborati — vive sulla piattaforma Virtuale, alla pagina del corso (virtuale.unibo.it/course/view.php?id=71624). Sulla piattaforma è già disponibile materiale relativo agli argomenti considerati conoscenze pregresse, che il corso dà quindi per scontati.
Non c'è un libro di testo. La materia evolve troppo rapidamente perché esista un volume che copra l'intera disciplina: si studia sulle slide proiettate a lezione. Nell'ultima slide di ogni lezione trovate i link alle risorse aggiuntive per l'approfondimento, molte delle quali disponibili solo in inglese.
Il corso presuppone che siano già acquisiti — tipicamente da Tecnologie Web, che è propedeutico — i seguenti argomenti:
| Area | Cosa si dà per scontato |
|---|---|
| Markup | Concetti di markup, XML e JSON |
| Documento | DOM, HTML5 (incluse le API) |
| Presentazione | CSS3 |
| Programmazione | JavaScript e jQuery, PHP |
Di questi argomenti verranno ripresi soltanto parzialmente alcune definizioni e concetti, usati come ponte verso i temi nuovi del corso: il funzionamento del browser motiva le tecnologie Web-based (HTML, CSS, JS) e apre la strada ai superset e metalinguaggi — TypeScript, che produce JavaScript in output, e SCSS/SASS, che producono CSS.
Il corso collabora a un progetto di ricerca che correla i dati ambientali raccolti da sensori presenti in aula e in laboratorio con la percezione del comfort da parte delle persone presenti in un ambiente indoor. Durante ogni lezione o esercitazione viene chiesto di compilare un questionario disponibile su Virtuale, con domande a risposta chiusa sulla percezione di temperatura, umidità, qualità dell'aria e rumore. La partecipazione è volontaria ed è premiata con un punto extra a chi compila il questionario in più dell'80% delle attività; sono considerate valide solo le risposte inviate durante le effettive ore di lezione o laboratorio.
L'esame si compone di due parti: un progetto (elaborato) e una prova orale. Vale la pena avere chiaro il meccanismo di punteggio fin dall'inizio, perché condiziona il modo in cui conviene affrontare il corso.
| Parte | Contenuto | Punteggio |
|---|---|---|
| Elaborato | Applicazione web-based realizzata in gruppo da 2-3 persone, con client, server e DB documentale, nelle fasi di design, implementazione e test con utenti | massimo 27/30 |
| Prova orale | Demo dell'elaborato, discussione delle scelte di design e implementative, domande di teoria su tutti gli argomenti di lezioni ed esercitazioni | +/- 5 punti a partire dal punteggio dell'elaborato |
L'elaborato è basato sui concetti e sulle metodologie viste a lezione e sulle tecnologie usate in laboratorio; lo stack richiesto è MEVN. Il tema — specifiche, funzionalità e metodologie — va concordato via email con docente e tutor e, una volta definito, pubblicato da uno studente del gruppo sul Forum degli Elaborati su Virtuale. La consegna avviene condividendo un repository (GitHub, BitBucket o altro) almeno una settimana prima della prova orale, accompagnata da una relazione in LaTeX il cui template viene fornito durante le esercitazioni. Sono consigliati test con utenti (almeno 5 persone) sull'interfaccia e sui meccanismi di interazione, da riportare nella relazione.
| Voce | Punti massimi |
|---|---|
| Design | 6 |
| Gestione funzionalità real-time/push | 8 |
| Gestione degli utenti | 5 |
| Gestione del servizio | 6 |
| Effetto WOW | 2 |
Due vincoli funzionali sono espliciti e pesano molto. Primo: devono esistere almeno due tipologie di utenti, l'admin del servizio e l'utente fruitore. Secondo: almeno una funzionalità deve sfruttare lo scambio di dati iniziato dal server (per esempio le notifiche), perché è lì che sta il vantaggio principale dello stack tecnologico — l'immediatezza dello scambio di informazioni push. Da sole, queste due voci valgono 13 punti su 27.
I temi proposti dai docenti sono volutamente molto generici e vanno dettagliati dal gruppo: mobilità per passeggeri (trasporto pubblico, interfacce per passeggeri, control room e driver, servizi a bordo o alla fermata, integrazione con servizi esterni come meteo, traffico ed eventi), smart mobility con calcolo di percorsi multimodali personalizzati, una web UI per Eclipse SUMO (Simulation of Urban Mobility), un Crowd Digital Twin per il monitoraggio e la simulazione dei comportamenti delle folle, applicazioni per la sostenibilità digitale e per il climate change basate su crowdsensing, applicazioni a supporto degli SDGs, e web app per il controllo di robot (dashboard di comandi e mappa della posizione, con possibilità di esperimenti su robot reale).
I docenti valutano volentieri proposte autonome, ma chiedono che si differenzino in modo sostanziale dai progetti tipici di Tecnologie Web. Sono esplicitamente scoraggiate: gestione di turni (palestra, ristorante, cinema), gestione di e-commerce, gestione di giochi, gestione di eventi, social network.
Il programma si articola su tre piani. I concetti principali sono browser e server per il Web, MVC e altri pattern applicati al Web, i concetti relativi alle Single Page Application e le metodologie per lo sviluppo di applicazioni Web. Le tecnologie sono lo stack MEVN, i superset e metalinguaggi per il Web (TypeScript, SASS e SCSS) e i framework JS, con VUE approfondito in dettaglio e Angular introdotto. In laboratorio si lavora su Node.js con Express, MongoDB, VueJS e SCSS. Durante il corso sono ospitati alcuni seminari di docenti esterni.
Un aspetto dichiarato apertamente dalla docente è la delimitazione rispetto ad altri insegnamenti, ed è utile conoscerla perché spiega perché certi argomenti "attesi" non compaiono.
| Corso | Sovrapposizione e confine |
|---|---|
| Tecnologie Web | Propedeutico: tutti i suoi argomenti e tecnologie sono dati per scontati. Si riprende solo ciò che serve da ponte, in particolare JS (lo stack MEAN è basato su JS, così come TypeScript) e CSS (per SCSS e SASS). |
| Programmazione Concorrente e Distribuita | Lì si vedono programmazione asincrona in Node.js, API REST design, il Web come piattaforma applicativa, architetture a microservizi e sviluppo di applicazioni Cloud. Qui si usa la stessa tecnologia (Node.js per script server-side) ma con punti di vista e obiettivi differenti; il corso si concentra su concetti, metodologie e tecnologie per il design e lo sviluppo di applicazioni Web-based. |
| Paradigmi di programmazione e sviluppo | Lì metodologie di sviluppo e pattern di progettazione avanzati. Qui gli stessi concetti applicati al Web, con attenzione a come MVC e pattern similari (MVVM) siano implementati dai framework usati in laboratorio. |
| Sistemi distribuiti | Lì i "servizi standard per sistemi distribuiti: Web Service". Qui il focus è sulle applicazioni Web-based più che sui servizi. |
La docente premette che il corso offre una panoramica volutamente parziale: non è possibile presentare tutte le tecnologie, i linguaggi, le piattaforme o i framework esistenti. Si entra nel dettaglio solo di alcune tecnologie (in laboratorio) e si introducono concetti di base applicabili anche altrove, così da essere poi in grado di apprendere autonomamente strumenti diversi che si fondano sugli stessi principi.
L'architettura Web di base è la più semplice che si possa disegnare: un client, che è il browser, e un Web Server. Il browser è al tempo stesso un client HTTP e un visualizzatore di documenti ipertestuali e multimediali. È lui a iniziare l'interazione; è lui a renderizzare testi, immagini e semplici interfacce grafiche; è lui che può permettere di editare, ma solo localmente.
Il browser, però, non è mai stato soltanto un visualizzatore. Fin da subito ha potuto includere plug-in per visualizzare file in formati particolari (PDF, Word e simili), estensioni che aggiungono funzionalità non disponibili in origine, e soprattutto un linguaggio di programmazione interno — JavaScript — che permette di realizzare tanto semplici verifiche di dati quanto complicate applicazioni autosufficienti, le cosiddette rich client application. È da questa terza voce che nasce l'intera storia raccontata in questo capitolo: l'architettura "con scripting client-side" è la stessa di prima, ma con del codice che gira nel browser.
I precursori dei browser nascono negli anni '80, a partire dalle idee di Ted Nelson (MEMEX). Il primo browser vero e proprio risale al 1990: lo sviluppa Tim Berners-Lee al CERN e si chiama WorldWideWeb, poi rinominato Nexus. È già composto dai tre pezzi che ritroveremo per sempre: un client HTTP, un layout engine e — dettaglio spesso dimenticato — un editor WYSIWYG. Il primo browser grafico fu Mosaic.
Le due guerre dei browser meritano di essere lette come un caso di studio, perché spiegano perché ancora oggi parliamo tanto di standard. Nella prima guerra il piano tecnico e quello commerciale si intrecciano: dal punto di vista tecnico c'è un rilascio continuo di nuove modifiche agli standard, spesso incompatibili tra loro, che costringe l'utente a navigare con un determinato browser per poter fruire delle nuove funzionalità, a seconda dei tag e degli attributi usati dall'autore delle pagine; sul piano commerciale, Microsoft inizia a distribuire IE includendolo nel sistema operativo Windows 95, mentre Netscape Navigator andava installato esplicitamente e molti utenti non ne conoscevano nemmeno l'esistenza.
La seconda guerra nasce dall'esito della prima: Internet Explorer, senza la minaccia di un avversario competitivo, continua lo sviluppo in maniera irregolare e senza introdurre cambiamenti importanti. È in questo vuoto che si affermano browser con caratteristiche innovative e maggiore rispetto degli standard W3C, che conquistano una fetta consistente del mercato. Nel 2008 arriva Chrome.
Da questa storia esce l'elenco delle componenti principali di un browser, che il capitolo successivo smonta pezzo per pezzo: client HTTP, interfaccia utente (e backend dell'interfaccia utente), motore di rendering e di layout, JavaScript engine.
La conformità agli standard non è un dettaglio burocratico: è la condizione che rende possibile scrivere una applicazione invece di N versioni. Le guerre dei browser sono la dimostrazione storica di cosa succede quando quella condizione viene meno, e sono il motivo per cui W3C e specifiche condivise hanno il peso che hanno.
Il server Web è un'applicazione che risponde a richieste di risorse locali — file, record di database e così via — individuate da un identificatore univoco. La sua funzione primaria è rispondere alle richieste di pagine effettuate dai client, cioè dai browser. Ma può anche collegarsi ad applicazioni server-side e agire da tramite tra il browser e l'applicazione che opera sul server, in modo che il browser diventi l'interfaccia dell'applicazione: è questa la porta d'ingresso di tutte le architetture dinamiche che vedremo tra poco.
Operativamente un server web deve ospitare, processare e fare il delivery delle pagine Web ai browser. Il server HTTP è la componente che riceve le richieste dal client e manda le risorse in risposta; le risorse sono documenti HTML, che possono includere immagini, fogli di stile e script. Il capitolo 3 riprende in dettaglio queste funzionalità.
La storia delle architetture del World Wide Web è la storia di una domanda sola, posta con insistenza crescente: dove mettiamo la logica? Ogni gradino sposta un pezzo di responsabilità, guadagnando qualcosa e pagando un prezzo. Le tappe sono cinque: sito statico, server-side include, modello a tre livelli (nelle due varianti embedded code e full application), modello a quattro livelli, rich client AJAX.
Il server contiene una quantità di file fisici memorizzati in directory, in formati immediatamente riconoscibili dal browser (HTML, GIF, JPEG). C'è esattamente un file per ogni schermata possibile, ciascuno con un URL diverso; il client li richiede uno a uno e li riceve per la visualizzazione. Nessun contenuto visualizzato cambia rispetto al documento memorizzato su disco.
Pregi: facile da realizzare, non richiede nessuna competenza tecnica. Difetti: totale mancanza di automazione e integrazione, ogni file è indipendente dagli altri.
La struttura resta quella del sito statico — un file per schermata, ciascuno con il suo URL — ma dentro i file HTML compaiono commenti speciali:
<!--#include virtual="header.html"-->
<!--#flastmod virtual="index.html"-->Questi commenti corrispondono a specifiche azioni che il server effettua subito prima di spedire il file richiesto. Il vocabolario di azioni possibili è però molto limitato.
Pregi: fornisce una qualche forma di modularità, resta molto semplice da usare. Difetti: è troppo limitato per essere veramente utile in contesti generali; si possono solo modularizzare frammenti che si ripetono su più file e realizzare micro-espressioni di contenuti dinamici.
Qui avviene il salto. Parte dei contenuti resta statica e su file, ma la parte importante è generata in output da un'applicazione server-side, che spesso raccoglie dati da query su un DBMS, li elabora e li trasforma, e li spedisce come risposta al browser. I tre livelli sono Browser, Application Logic + Presentation, Storage: l'application logic (a volte detta business logic) si modularizza rispetto allo storage per poter usufruire di velocità e funzionalità dei DB indipendentemente dalla logica dell'applicazione. È il modello tipicamente associato a stack applicativi di tipo LAMP, e si realizza in due modi.
Il sito Web è in realtà un'applicazione. Contiene file fisici in formati riconoscibili dal browser e c'è un file per ogni tipo di funzionalità (servizio) offerto. I file HTML contengono commenti speciali con codice inserito in qualche linguaggio di programmazione (PHP, ASP, …): la parte puramente HTML è ripetuta su ogni risposta spedita dal server, mentre le istruzioni embedded generano codice HTML di volta in volta diverso.
La singola pagina HTML può contenere molti blocchi di codice embedded: la parte HTML è il template, mentre il codice fornisce la parte dinamica. Bisogna però fare attenzione a mantenere sincronizzati tutti i template per quel che riguarda la presentazione — un cambio di look al sito richiede di modificare ogni singolo file — e questa commistione di codice e template può essere considerata fragile e poco pulita.
Pregi: si può realizzare qualunque applicazione server-side con poco sforzo e in maniera fortemente integrata ai template HTML. Difetti: architettura fragile, perché cambiamenti al codice possono esporre problemi di visualizzazione del template e, viceversa, modifiche al look possono cambiare il comportamento dell'applicazione.
Si attua una separazione forte tra logica di applicazione e presentazione: risiedono fisicamente su file diversi e vengono modificati in momenti diversi del processo di produzione. Il server esegue il file di programma e alla fine genera un singolo output dell'intera stringa del documento HTML. I modi più comuni per ottenerlo sono tre:
Pregi: si crea un'importante separazione tra application logic e presentazione, che permette di separare i processi di generazione e test dell'applicazione da quelli di progettazione della parte visibile del sito. Difetti: la separazione non è ancora completa, perché si applica solo al template (layout complessivo, decorazioni, schemi di colori, parti fisse della pagina). Il codice HTML di ogni singolo pezzo di output è ancora deciso dall'applicazione: che l'output di una query venga restituito come lista o come tabella resta una decisione dell'application logic, e generare output personalizzati per device molto diversi resta complesso.
L'ultimo passo prima del rich client consiste nello spezzare in due il livello centrale. Nel modello a quattro livelli il livello di application logic genera un output completamente privo di aspetti presentazionali — per esempio un file XML — e lo dà in pasto a un altro livello, che chiamiamo presentation (o presentation logic). Questo livello modifica completamente il documento posizionando le varie parti dell'output all'interno del template in maniera completa e assoluta, prendendo anche micro-decisioni riguardo a quale HTML usare di volta in volta. Template diversi possono applicarsi allo stesso output per personalizzarsi su specifici tipi di device mantenendo assolutamente intatta l'application logic.
Esistono motori di template che funzionano in questo modo; una soluzione utilizzata in passato era basata sull'uso di XSLT per generare il documento HTML finale: un processo della catena di produzione dell'output, o l'ultima istruzione dell'application logic, richiamava il motore XSLT sul documento XML prodotto e restituiva in output il documento HTML finale.
Pregi: completa e definitiva separazione tra application logic e presentation logic, architettura semplice, modulare, ripetibile. Difetti: i difetti di tutte le applicazioni server-side.
Tradizionalmente la programmazione client-server ha sempre criticato la presenza di application logic sul client, per due ragioni solide: poco controllo sull'ambiente operativo e difficoltà di distribuzione di versioni e patch. Il WWW muove però alcune obiezioni a queste critiche.
| Obiezione del Web | In concreto |
|---|---|
| Costo di ogni passo | Ogni passo dell'applicazione richiede di consultare il server, eseguire una funzione dell'application logic, generare l'HTML finale, riceverlo e visualizzarlo: può portare via molto tempo |
| Naming e caching | Ogni passo dell'applicazione ha un proprio URL, che richiede specifiche politiche di naming e di caching piuttosto complesse da gestire |
| Ambiente | I browser sono ambienti indipendenti dal sistema operativo e (più o meno) standardizzati |
| Distribuzione | Il codice può comunque risiedere sul server ed essere distribuito al client ogni volta, garantendo che giri sempre l'ultima versione |
Il meccanismo è questo: all'inizio dell'esecuzione del servizio il browser carica una normale pagina HTML, che contiene codice JavaScript e alcune librerie AJAX. Lo scopo di quelle librerie è duplice: fornire una libreria di funzioni comuni e indipendenti dallo specifico sistema operativo e browser utilizzato, e fornire strumenti utili per realizzare applicazioni client-side in maniera facile (per esempio l'interazione con il server o la generazione di frammenti di output).
Il documento HTML contiene quindi solo le parti fisse (layout e simili) e le funzioni JavaScript. Il programma parte e, attraverso un'apposita chiamata di libreria — XMLHttpRequest — chiede al server dati presentation-independent da convertire in HTML e visualizzare sulla pagina. Qui si aprono due possibilità, ed è importante distinguerle:
Il passo finale è il single-page web site / Single-page Application: un sito web complesso e sofisticato composto in realtà da un unico documento HTML piuttosto ricco. È diventato possibile grazie a tre fattori concomitanti — l'aumento della velocità di rete, la disponibilità di AJAX e la sofisticazione dei framework JavaScript e CSS — e sta avvenendo sia per siti informativi sia per siti di applicazioni, per via di quattro vantaggi: gestione semplificata, connessioni HTTP semplificate e unificate, estrema flessibilità di reazione dell'applicazione, offline editing.
Sapere ricostruire la scala completa — statico → SSI → tre livelli (embedded / full application) → quattro livelli → AJAX/SPA — dicendo per ciascun gradino dove sta la presentation logic, dove sta l'application logic e quale problema del gradino precedente risolve, è la domanda di teoria più prevedibile su questo capitolo. Il criterio unificante è uno solo: la posizione della logica rispetto al confine client/server.
I framework sono librerie che rendono più ricco, sofisticato e semplice l'uso di una tecnologia: un linguaggio server-side, un linguaggio client-side o le specifiche grafiche di una pagina web. I framework server-side esistono dalla fine degli anni novanta e hanno reso più semplice la programmazione a tre livelli; quelli client-side si sono sviluppati a partire dal 2002, su CSS e JavaScript, con scopi molto differenti e difformi l'uno dall'altro.
Struts, Django, Ruby on Rails, Symfony, Yii, Spring MVC, Stripes, Play, CodeIgniter…
Architettura a tre livelli con una struttura concettuale Model-View-Controller. Forniscono una varietà di servizi: gestione di autenticazione e sicurezza, accesso a database, mappatura di URL, e scaffolding, cioè strutture semplificate e generiche di applicazione da riempire caso per caso con i dettagli.
Foundation, YAML, Twitter Bootstrap…
Un mix di classi CSS e strutture predefinite HTML per: gestione del layout di pagina (colonne, aree, stili integrati), gestione dei layout responsive che si adattano alla dimensione dello schermo, semplificazione e omogeneizzazione di feature frequenti (blocchi evidenziati, tab, barre di navigazione, menu dropdown).
Prototype, Dojo, GWT, jQuery, ExtJs, Angular, Vue.js, React…
Librerie JavaScript per: omogeneizzare le versioni JavaScript dei vari browser; aggiungere funzionalità utili al linguaggio (AJAX, query su DOM, funzionalità object oriented); fornire librerie di effetti grafici sofisticati (animazioni e transizioni); integrare piattaforme tradizionali e mobili; fornire widget grafici di uso frequente (grid, tree, menu, form, date picker); gestire template per frammenti HTML riusati frequentemente.
Un solution stack è un insieme di componenti o sottosistemi software necessari per creare una piattaforma completa basata su architetture a 3 livelli, in modo che nessun software aggiuntivo sia indispensabile allo sviluppo di applicazioni. Per lo sviluppo Web uno stack è solitamente costituito da quattro elementi: sistema operativo, web server, database e linguaggio di programmazione.
LAMP è uno dei solution stack più noti: Linux come sistema operativo, Apache come server web, MySQL come DBMS, e come linguaggio di programmazione comunemente PHP, ma vengono usati anche Perl e Python. Tutto lo stack è completamente open source, è molto utilizzato, è supportato da una comunità vasta e solida ed è personalizzabile: da qui le varianti — LEMP con NGINX al posto di Apache (la E deriva dalla pronuncia "engine-X"), LLMP con lighttpd, LAPP con PostgreSQL al posto di MySQL. WAMP è semplicemente la variante con Windows come sistema operativo.
I problemi che hanno spinto verso qualcosa di diverso sono cinque: Apache non è il web server più veloce; è difficile scrivere buon codice PHP riusabile e veloce da eseguire; si usano linguaggi diversi per front-end e back-end; ci sono molte conversioni dei dati (da XML/JSON a PHP, da PHP a HTML); non c'è una netta separazione nello sviluppo tra la parte client e quella server.
MEAN ha una struttura diversa e, soprattutto, non fa riferimento a un sistema operativo. È l'acronimo di MongoDB (database NoSQL), Express.js (framework di sviluppo JavaScript lato server, che esegue su Node.js), Angular (framework di sviluppo JavaScript lato client) e Node.js (ambiente di esecuzione per applicazioni server-side, che permette di eseguire codice JavaScript al di fuori del browser).
| Aspetto | L(W)AMP | MEAN |
|---|---|---|
| Sistema operativo | Fa riferimento a uno specifico SO | Nasce multipiattaforma |
| Esecuzione server-side | PHP, Python o Perl | Node.js: esegue codice JS fuori dal browser (JavaScript everywhere) |
| Database | MySQL, relazionale | MongoDB, non relazionale |
| Copertura | Definisce solo lo stack lato server | Fornisce due supporti di programmazione, uno client e uno server, basati sullo stesso linguaggio |
MEAN rappresenta quindi un cambiamento forte nel modello di architettura: si passa da database relazionali a database documentali (NoSQL) e si passa dal pattern MVC lato server a una single web application lato client.
Vantaggi dichiarati: 100% open source, 100% JavaScript (più JSON e HTML), 100% Web standard; modello consistente tra back-end e front-end; uso di JavaScript in tutto lo stack — JavaScript è il linguaggio del web, JSON il data format del web, e non serve nessuna conversione per il database; basso overhead di memoria; si può iniziare lo sviluppo dal frontend. Svantaggi: non esistono ancora linee guida e best practice consolidate per la generazione e lo sviluppo di codice JS; MongoDB non è robusto quanto SQL server; una volta creato il primo sito Web con MEAN è difficile tornare indietro ai "vecchi" approcci.
Nel corso useremo la variante MEVN, con VueJS al posto di Angular; si discuterà anche il confronto con MERN (React). Gli stack standard non esauriscono la realtà: sono sempre possibili versioni ibride, dette signature stack. Uber usa NGINX e Apache come web server, MySQL, PostgreSQL, MongoDB e Cassandra come database, Node.js lato server e Python, Java, JavaScript e Objective-C come linguaggi; Reddit usa NGINX, PostgreSQL, Redis e Cassandra, Node.js, JavaScript e Python; Pinterest lavora con Python, Java e Go, Django e Javascript MVC, MySQL, Hadoop, HBase, Memcached e Redis, con NGINX; Facebook usa PHP, GraphQL e Hack, il framework Tornado, database come Cassandra, RocksDB, Beringei e Memcached e server custom; Airbnb usa JavaScript, Ruby, Java e Sass con Rails, MySQL, Amazon RDS, Hadoop e Redis, su NGINX.
La lezione si chiude con una fotografia del presente, che è anche la lista dei motivi per cui vale la pena studiare questa materia adesso. Oltre il 65% del traffico proviene da dispositivi mobili; ci si aspettano applicazioni veloci, responsive, accessibili e personalizzate; le architetture si basano su microservizi e backend serverless; l'edge computing porta le logiche a essere distribuite geograficamente.
| Tendenza | Contenuto |
|---|---|
| Ecosistema front-end | Da jQuery a React, Vue, Angular (ma anche altri come Svelte); Next.js, Nuxt.js, Astro per il rendering ibrido e full-stack; TypeScript come standard per codice sicuro e leggibile; UI component-based e modulari |
| Serverless ed edge | Esecuzione on-demand (AWS Lambda, Vercel Functions), distribuzione geografica e scalabilità automatica, nessuna gestione server e modello pay-per-use, adatte ad applicazioni in tempo reale |
| JAMstack | JavaScript, API, Markup: contenuti statici ma dinamici grazie ad API e JavaScript, con prestazioni elevate, maggiore sicurezza e scalabilità, architettura disaccoppiata e flessibile |
| PWA | Progressive Web App installabili, funzionanti offline, con notifiche push; esperienza simile alle app native; adottate da aziende come Twitter (X), Pinterest, Starbucks |
| AI | Interfacce conversazionali e ricerca semantica, contenuti personalizzati e raccomandazioni intelligenti, generazione automatica di codice |
| Accessibilità e sostenibilità | WCAG 2.2, ruoli ARIA, screen reader e tecnologie assistive; riduzione delle richieste, compressione degli asset, hosting green; accessibilità come requisito, non come opzione |
La conclusione della docente è netta: lo sviluppo web è sempre più distribuito e intelligente, le architetture sono API-driven e user-centered, AI e accessibilità ridefiniscono l'esperienza utente. E soprattutto — il Web evolve, aggiornarsi è parte del mestiere.
Le ultime due voci della tabella — accessibilità e sostenibilità — non sono contorno: sono l'oggetto di un'intera lezione del corso (capitolo 14) e compaiono anche tra i temi proposti per l'elaborato. Collegare "riduzione delle richieste e compressione degli asset" con le scelte architetturali di questo capitolo (quanto codice mando al client? quante richieste faccio?) è esattamente il tipo di ragionamento trasversale che l'orale premia.
L'esame ha due parti. L'elaborato è un'applicazione web-based realizzata in gruppo da 2-3 persone, con client, server e DB documentale, sviluppata nelle fasi di design, implementazione e test con utenti: vale al massimo 27/30. La prova orale consiste nella demo dell'elaborato, nella discussione delle scelte di design e implementative e in domande di teoria su tutti gli argomenti di lezioni ed esercitazioni: sposta il voto di +/- 5 punti a partire dal punteggio dell'elaborato. Si aggiunge un possibile punto extra per la partecipazione al questionario sul comfort ambientale in più dell'80% delle attività.
Devono esistere almeno due tipologie di utenti (admin del servizio e utente fruitore) e almeno una funzionalità deve essere basata su uno scambio di dati iniziato dal server, per esempio le notifiche. La motivazione è esplicita: il vantaggio dello stack tecnologico risiede principalmente nell'immediatezza dello scambio di informazioni push, quindi un progetto che non lo usa non sta sfruttando lo stack. Nella griglia di valutazione le funzionalità real-time/push valgono fino a 8 punti e la gestione degli utenti fino a 5.
In entrambi i casi il server contiene file fisici in formati riconoscibili dal browser, con un file per ogni schermata e un URL diverso per ciascuno. Nel sito statico il contenuto visualizzato non cambia mai rispetto al documento su disco. Con SSI i file HTML contengono commenti speciali (come <!--#include virtual="header.html"-->) che corrispondono ad azioni eseguite dal server subito prima di spedire il file. SSI dà quindi una forma di modularità restando semplicissimo, ma il vocabolario di azioni è molto limitato: si possono solo modularizzare frammenti ripetuti e realizzare micro-espressioni di contenuti dinamici.
Con embedded code i file HTML contengono blocchi di codice (PHP, ASP…) mescolati al markup: la parte HTML è il template, il codice fornisce la parte dinamica. Si realizza qualunque applicazione con poco sforzo, ma l'architettura è fragile — modifiche al codice possono rompere la visualizzazione e modifiche al look possono cambiare il comportamento — e un cambio di look richiede di toccare ogni singolo file. Con full application logica e presentazione risiedono fisicamente su file diversi, modificati in momenti diversi del processo di produzione; il server esegue il programma e genera l'intero documento HTML. La separazione però non è completa: riguarda solo il template, mentre il codice HTML di ogni singolo pezzo di output è ancora deciso dall'application logic.
Spezza in due il livello centrale. L'application logic genera un output completamente privo di aspetti presentazionali (per esempio un documento XML) e lo passa a un livello di presentation logic, che posiziona le parti dell'output nel template in maniera completa e assoluta, prendendo anche le micro-decisioni su quale HTML usare. Il vantaggio è che template diversi possono applicarsi allo stesso output per personalizzarlo su device differenti mantenendo intatta l'application logic. Una realizzazione storica usava XSLT sul documento XML prodotto per generare l'HTML finale.
Le critiche classiche della programmazione client-server erano il poco controllo sull'ambiente operativo e la difficoltà di distribuzione di versioni e patch. Il Web risponde su due fronti: da un lato i browser sono ambienti indipendenti dal sistema operativo e più o meno standardizzati, e il codice può comunque risiedere sul server ed essere distribuito al client ogni volta, garantendo che giri sempre l'ultima versione; dall'altro il modello tutto-server ha costi propri, perché ogni passo dell'applicazione richiede un giro completo verso il server e ha un proprio URL, con politiche di naming e caching complesse.
Il browser carica una pagina HTML con le parti fisse e le funzioni JavaScript, e tramite XMLHttpRequest chiede al server dati presentation-independent. Da qui: o esiste un'applicazione server-side che genera l'XML e lo passa al client, e allora si sposta sul client solo la presentation logic; oppure sul server esiste solo il minimo indispensabile per interrogare i dati, e allora si spostano sul client sia la presentation logic sia l'application logic. Il secondo caso è quello che porta direttamente alle Single Page Application.
Tre fattori concomitanti: l'aumento della velocità di rete, la disponibilità di AJAX e la sofisticazione dei framework JavaScript e CSS. Il fenomeno riguarda sia i siti informativi sia le applicazioni, e porta quattro vantaggi: gestione semplificata, connessioni HTTP semplificate e unificate, estrema flessibilità di reazione dell'applicazione, offline editing.
È un insieme di componenti o sottosistemi software necessari per creare una piattaforma completa basata su architetture a 3 livelli, in modo che nessun software aggiuntivo sia indispensabile allo sviluppo di applicazioni. Per lo sviluppo Web è solitamente costituito da quattro elementi: sistema operativo, web server, database e linguaggio di programmazione. LAMP (Linux, Apache, MySQL, PHP) ne è l'esempio più noto, con le varianti LEMP (NGINX), LLMP (lighttpd), LAPP (PostgreSQL) e WAMP (Windows).
Quattro differenze. Sistema operativo: LAMP e WAMP fanno riferimento a uno specifico SO, MEAN nasce multipiattaforma e non lo nomina affatto. Esecuzione server-side: MEAN usa Node.js per eseguire JavaScript fuori dal browser, secondo il paradigma JavaScript everywhere. Database: MEAN usa un DB non relazionale (MongoDB) al posto del relazionale MySQL. Copertura: MEAN fornisce due supporti di programmazione, uno client (Angular) e uno server (Express), basati sullo stesso linguaggio, mentre L(W)AMP definisce solo lo stack lato server. Ne consegue un cambiamento del modello di architettura: dai database relazionali a quelli documentali, e dal pattern MVC lato server a una single web application lato client.
JAMstack sta per JavaScript, API, Markup. I contenuti sono statici ma dinamici: il markup viene servito già pronto, mentre la dinamicità arriva da API interrogate via JavaScript. I benefici dichiarati sono prestazioni elevate, maggiore sicurezza e scalabilità, e un'architettura disaccoppiata e flessibile. Rispetto al sito dinamico classico, il server non ricompone la pagina a ogni richiesta: la composizione avviene prima (build) o dopo (nel client), non durante.
Client HTTP, interfaccia utente (con il relativo backend dell'interfaccia utente), motore di rendering e di layout e JavaScript engine. Il browser va inteso non solo come visualizzatore di documenti ipertestuali e multimediali ma anche come piattaforma di esecuzione: può includere plug-in per formati particolari, estensioni che aggiungono funzionalità e un linguaggio di programmazione interno che consente di realizzare vere rich client application.