History of web applications

Transcript

1. Evolution of Web Application History, Architecture, Examples.
2. I’m Daniele! Daniele Fontani, CTO @Sintra-Digital business https://github.com/zeppaman https://www.linkedin.com/in/daniele-fontani/ d.fontani@sintraconsulting.eu https://medium.com/@daniele.fontani
3. Piacere! Piacere di conoscervi, e voi chi siete?
4. • 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
5. 1. web application Di che stiamo parlando?
6. WEB APPLICATION Da wikipedia: “In informatica l'espressione applicazione web, ovvero web application in inglese, indica genericamente tutte le applicazioni distribuite web-based.”
7. 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”
8. 2. Evoluzione Come siamo arrivati agli standard attuali?
9. 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
10. Storia: file statici 1993: le persone possono andare su internet, ma cosa fanno? Scaricano files
11. Storia: cgi-bin E se poi voglio “fare” delle cose tramite internet? Avvio dei programmi da remoto
12. 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.”
13. Storia: cgi-bin, esempio (3) submit risultato
14. 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
15. Storia: scripting E se poi voglio una soluzione pratica? Usiamo un unico “programma” che interpreta script (ASP, PHP)
16. Storia: scripting(2), esempio E se poi voglio una soluzione pratica? Usiamo un unico “programma” che interpreta script (ASP, PHP)
17. 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)
18. Storia: MVC
19. Storia: MVC(2), come funziona Separo le componenti applicative: • Modello dati => cosa devo mostrare • Controller => cosa devo fare • Vista => come lo voglio mostrare
20. Storia: MVC(3), vantaggi • Separazione logica di business da presentazione • organizzazione strutturata delle cose • supportato da framework completi (ORM)
21. 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)
22. Storia: SPA Separiamo la parte di presentazione (frontend) da quella operativa (backend). In questo modo possiamo impiegare team verticali. SPA
23. Storia: SPA(2)
24. Storia: SPA(3), limiti • integrazione in ambienti già esistenti (difficile farci “un pezzettino nuovo)
25. 3. API - Disegno di alto livello La rimozione del livello di presentazione focalizza il lavoro di backend sulla realizzazione di API
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
32. Disegno di alto livello
33. 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
34. 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
35. 4. Insiders Nuove tecnologie che stanno rivoluzionando il modo di erogare API
36. Insider: come stiamo per evolvere? come può cambiare questo scenario? • Standard di formato (OData, GraphQL) • Soluzioni in cloud • Headless CMS
37. 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/
38. Insider: GraphQL • Protocollo standard per l’interrogazione dai (read, query, save) Esempi:
39. Insider: limiti di GraphQL e OData • Difficile ridurre accoppiamento tra dati e output • Difficile gestire casistiche non-standard
40. Insider: Headless CMS • Applicativo verticale che salva dati
41. Insider: Headless CMS, limiti • Difficile integrarsi con autenticazione esterna • Difficile inserire logica di business • Output sempre 1:1 con la base dati
42. 4. Riferimenti Qualche link prima dei saluti
43. 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
44. 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
45. Riferimenti: codice sorgente https://github.com/zeppaman/HistoryOfWebApplication
46. Thanks! ! Any questions? You can find me at @username & user@mail.me