History of web applications

Transcript

1. Evolution of
   Web Application
   History, Architecture, Examples.
   

   View Slide

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
   

   View Slide

3. Piacere!
   Piacere di conoscervi, e voi chi
   siete?
   

   View Slide

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
   

   View Slide

5. 1.
   web application
   Di che stiamo parlando?
   

   View Slide

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

   View Slide

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”
   

   View Slide

8. 2.
   Evoluzione
   Come siamo arrivati agli standard attuali?
   

   View Slide

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
   

   View Slide

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

    View Slide

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

    View Slide

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.”
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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)
    

    View Slide

18. Storia: MVC
    

    View Slide

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

    View Slide

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

    View Slide

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)
    

    View Slide

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

    View Slide

23. Storia: SPA(2)
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. Disegno di alto livello
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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/
    

    View Slide

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

    View Slide

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

    View Slide

40. Insider: Headless CMS
    ● Applicativo verticale che salva dati
    

    View Slide

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

    View Slide

42. 4.
    Riferimenti
    Qualche link prima dei saluti
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

46. Thanks!
    !
    Any questions?
    You can find me at @username &
    user@mail.me
    

    View Slide