Evolution of Web Application History, Architecture, Examples. 

I’m Daniele! Daniele Fontani, CTO @Sintra-Digital business https://github.com/zeppaman https://www.linkedin.com/in/daniele-fontani/ [email protected] https://medium.com/@daniele.fontani 

Piacere! Piacere di conoscervi, e voi chi siete? 

● Presentazione ○ Chi sono ○ Chi siete ○ Agenda ● Cos’è un’applicazione web? ● Storia delle applicazioni web ○ panoramica ○ file server ○ cgi-bin ○ script ○ mvc ○ spa ● Architettura API ○ Perché? ○ Elementi: Database (SQL /NoSQL) ○ Elementi: Cache (Redis) ○ Elementi: Docker ○ Elementi: Oauth2 ○ Elementi: Api Gateway ○ Disegno Complesso ● Disegno interno ○ Disegno ○ DAL ○ BLL ○ Mapping ● Standard ○ GraphQL ○ OData ● Riferimenti & Saluti Agenda 

1. web application Di che stiamo parlando? 

WEB APPLICATION Da wikipedia: “In informatica l'espressione applicazione web, ovvero web application in inglese, indica genericamente tutte le applicazioni distribuite web-based.” 

Cos’è un’applicazione web, riproviamoci Cos’è un’applicazione: “Il termine applicazione individua un programma o una serie di programmi con lo scopo e il risultato di rendere possibile una o più funzionalità, tramite interfaccia utente” 

2. Evoluzione Come siamo arrivati agli standard attuali? 

WEB APPLICATIONS (SPA + API) WEB APPLICATIONS CMS SITO WEB STATICO + SITO DINAMICO “FACILE” + PROGRAMMA La storia delle web application Capiamo da dove viene questo termine e come siamo arrivati a lavorare come facciamo oggi SITO WEB STATICO + PROGRAMMA 1998 2006 2014 

Storia: file statici 1993: le persone possono andare su internet, ma cosa fanno? Scaricano files 

Storia: cgi-bin E se poi voglio “fare” delle cose tramite internet? Avvio dei programmi da remoto 

Storia: cgi-bin(2) Il CGI è la prima forma di elaborazione lato server implementata Il principio è questo: “Associo una url ad un eseguibile e restituisco l’output all’utente.” 

Storia: cgi-bin, esempio (3) submit risultato 

Storia: cgi-bin(4), limiti ● gestione “manuale degli input” ● mancanza di templating ● nessun pattern di sviluppo (es. MVC) ● un programma eseguito ad ogni richiesta utente (molto dispendioso) ● difficoltà a mettere “a fattor comune” parti di librerie 

Storia: scripting E se poi voglio una soluzione pratica? Usiamo un unico “programma” che interpreta script (ASP, PHP) 

Storia: scripting(2), esempio E se poi voglio una soluzione pratica? Usiamo un unico “programma” che interpreta script (ASP, PHP) 

Storia: script(2), limiti ● difficile condividere codice in modo organico ● il copia incolla regna ● funzioni di base distribuite (es. chiusura connessione) ● gestione dati a livello di statement (sql injection,etc..) ● inclusioni globali che eseguono codice non necessario (es. create table) 

Storia: MVC 

Storia: MVC(2), come funziona Separo le componenti applicative: ● Modello dati => cosa devo mostrare ● Controller => cosa devo fare ● Vista => come lo voglio mostrare 

Storia: MVC(3), vantaggi ● Separazione logica di business da presentazione ● organizzazione strutturata delle cose ● supportato da framework completi (ORM) 

Storia: MVC(3), limiti ● L’interazione con l’utente è limitata dal meccanismo “client-server” ● L’utilizzo di framework javascript a livello di DOM è molto limitante per le aspettative dell’utente di oggi ● lo sviluppatore deve conoscere tutto lo stack (frontend\backend) 

Storia: SPA Separiamo la parte di presentazione (frontend) da quella operativa (backend). In questo modo possiamo impiegare team verticali. SPA 

Storia: SPA(2) 

Storia: SPA(3), limiti ● integrazione in ambienti già esistenti (difficile farci “un pezzettino nuovo) 

3. API - Disegno di alto livello La rimozione del livello di presentazione focalizza il lavoro di backend sulla realizzazione di API 

API (Application Programming interface) ● REST/Json (ma non solo) ● Definire l’architettura ● Imparare a fare API “per bene” Come? ● Imparando quali “pezzi” utilizzare a livello architetturale ● Imparando come strutturare l’applicazione internamente 

Database: SQL\NOSQL ● Non sono esclusivi ● Da conoscere entrambi e sfruttare in base alle esigenze dell’applicativo RDBMS Quando usarlo? ● Struttura fortemente relazionata ● Necessità di calcoli aggregati e statistiche ● Mancata competenza su NoSQL NOSQL Quando usarlo? ● Bigdata ● Necessità verticali (es. Elastic per ricerca) ● Clustering 

Cache: Redis Redis è un KeyValue store, appartiene alla famiglia dei DB NOSQL ● Semplice da usare ● integrato con tutti i framework Quando usarlo? ● condividere dati di sessione tra più server ● cache applicativa (es. ci salvo la lista dei comuni all’avvio...) ● grandi moli di dati in forma chiave:valore 

Piattaforma: docker E’ una piattaforma che permette di astrarre il sistema operativo e sostituisce il vecchio approccio a macchine virtuali. ● Semplifica il processo di sviluppo ● Si lavora con lo stesso ambiente di produzione anche in locale ● Permette di scalare senza cambiare il codice (es. kubernetes) ● Riduce la complessità sistemistica Quando usarlo? ● per lo sviluppo, in tutti i casi in cui evita l’installazione di tool locali (es. mysql, apache etc..) ● per la produzione, ovunque vi sia permesso, facendo attenzione a calibrare la soluzione in base alla complessità del problema 

Autenticazione: Oauth2 E’ un protocollo standard di autenticazione che permette di identificare in maniera semplice l’utente ● Semplice da usare ● Disponibile come applicativi standalone (es. keycloak) ● integrabile su tutti i framework ● sicuro Quando usarlo? ● condividere l’accesso tra più applicativi ● necessità di essere autenticato da più backend API 

Esposizione API: ApiGateway E’ un sistema che intermedia le API, introducendo fnuzionalità di base. ● nasconde le api reali (sicurezza e indipendenza) ● traccia le chiamate ● applica limitazioni (es. massimo 10 richieste al secondo) ● offre un portale per sviluppatori Quando usarlo? ● Se le api sono utilizzate da terze parti ● Se pensiamo, in futuro, di aprire le nostre API all’esterno ● Se abbiamo necessità di limitare l’uso delle API 

Disegno di alto livello 

Disegno Interno ● DAL (Data Access Layer): Si occupa della lettura dei dati e ha un modello 1:1 con la struttura dati ● BLL (Business Logic Layer): Si occupa della logica di gestione dei dati. Il suo modello dati coincide con il dominio applicativo ed è svincolato dall’accesso ai dati ● PL (Presentation Layer): Se abbiamo lavorato bene, è totalmente in carico al frontend 

Vantaggi ● Possiamo modificare la base dati senza impatti per l’applicativo, perché non c’è accoppiamento, ● Possiamo buttare via il frontend e rifarlo (es. re-design) e mantenere invariate le API 

4. Insiders Nuove tecnologie che stanno rivoluzionando il modo di erogare API 

Insider: come stiamo per evolvere? come può cambiare questo scenario? ● Standard di formato (OData, GraphQL) ● Soluzioni in cloud ● Headless CMS 

Insider: Odata ● Protocollo standard per l’interrogazione dai (read, query, save) Esempi: ● https://services.odata.org/v4/TripPinServiceRW/People? $top=2 & $select=FirstName,LastName & $filter=Trips/any(d:d/Budget gt 3000) ● https://www.odata.org/getting-started/understand-odata-in-6-steps/ 

Insider: GraphQL ● Protocollo standard per l’interrogazione dai (read, query, save) Esempi: 

Insider: limiti di GraphQL e OData ● Difficile ridurre accoppiamento tra dati e output ● Difficile gestire casistiche non-standard 

Insider: Headless CMS ● Applicativo verticale che salva dati 

Insider: Headless CMS, limiti ● Difficile integrarsi con autenticazione esterna ● Difficile inserire logica di business ● Output sempre 1:1 con la base dati 

4. Riferimenti Qualche link prima dei saluti 

Riferimenti: Articoli citati ● Oauth2: GitHub Analytics: Oauth Killer Application ● Api Gateway: Api Gateway in un esempio pratico ● Slack API:Slack Pusher: Push Slack Messages to Wordpress ● NoSQL:NOSQL or NOT NOSQL? ● Headless CMS: Inside Headless CMS ● TDD+ MVC:Build an ASP.NET Wiki to Explain TDD ● Docker: Simple tutorial to understand docker basics 

Riferimenti: Letture consigliate ● Clean Code, Robert C. Martin ● Agile Principles, Patterns, And Practices in C#, Robert C. Martin ● Patterns of Enterprise Application Architecture, Martin Flower 

Riferimenti: codice sorgente https://github.com/zeppaman/HistoryOfWebApplication 

Thanks! ! Any questions? You can find me at @username & [email protected]