Upgrade to Pro — share decks privately, control downloads, hide ads and more …

History of web applications

History of web applications

Daniele Fontani

May 27, 2020
Tweet

More Decks by Daniele Fontani

Other Decks in Technology

Transcript

  1. • 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
  2. WEB APPLICATION Da wikipedia: “In informatica l'espressione applicazione web, ovvero

    web application in inglese, indica genericamente tutte le applicazioni distribuite web-based.”
  3. 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”
  4. 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
  5. Storia: cgi-bin E se poi voglio “fare” delle cose tramite

    internet? Avvio dei programmi da remoto
  6. 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.”
  7. 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
  8. Storia: scripting E se poi voglio una soluzione pratica? Usiamo

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

    Usiamo un unico “programma” che interpreta script (ASP, PHP)
  10. 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)
  11. Storia: MVC(2), come funziona Separo le componenti applicative: • Modello

    dati => cosa devo mostrare • Controller => cosa devo fare • Vista => come lo voglio mostrare
  12. Storia: MVC(3), vantaggi • Separazione logica di business da presentazione

    • organizzazione strutturata delle cose • supportato da framework completi (ORM)
  13. 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)
  14. Storia: SPA Separiamo la parte di presentazione (frontend) da quella

    operativa (backend). In questo modo possiamo impiegare team verticali. SPA
  15. 3. API - Disegno di alto livello La rimozione del

    livello di presentazione focalizza il lavoro di backend sulla realizzazione di API
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. Insider: come stiamo per evolvere? come può cambiare questo scenario?

    • Standard di formato (OData, GraphQL) • Soluzioni in cloud • Headless CMS
  25. 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/
  26. Insider: limiti di GraphQL e OData • Difficile ridurre accoppiamento

    tra dati e output • Difficile gestire casistiche non-standard
  27. Insider: Headless CMS, limiti • Difficile integrarsi con autenticazione esterna

    • Difficile inserire logica di business • Output sempre 1:1 con la base dati
  28. 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
  29. 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