La vita è questione di scelte. È questione di scelte anche l’architettura di una applicazione web.
La fase iniziale di un nuovo progetto web è di solito complessa, caotica, e comprende:
- Progettazione dell’architettura dell’applicazione
- Progettazione e sviluppo della User Experience (UX)
- Progettazione e implementazione della sicurezza (spesso si parla di security by design)
L’architettura di una nuova applicazione web è disegnata tenendo conto di una serie di requisiti strategici per l’applicazione stessa (e per l’azienda committente, o cliente).
Alcuni punti sono in comune com tutte le applicazioni web:
- Data Access Layer: quale dbms? ORM si/no?
- Separation of Concern
- Quale pattern architetturale adottare? MVC, MVP, MVVM?
- client / server: qui esiste un numero non precisato (altissimo) di soluzioni, con framework “per ogni…”
- scalabilità: oggi le start up sono “scalable by design”, il loro obiettivo numero uno è scalare da 0 a un numero di utenti con sei zeri; quindi una applicazione web “prodotto” di una start up deve! essere scalabile
Altri punti diventano caratteristici dell’applicazione, a seconda del dominio applicativo:
- architettura client / server o microservice oriented? Ibrida?
- session and state management: cookieness or cookieless? local storage? sessionless?
- strategie di caching: di pagina, dati, applicazione, http?
- real time? WebSocket oppure Socket.io?
- in cloud oppure on-premise?
Ovviamente, questa lista non è esaustiva. E soprattutto l’approccio alla archiettura di una applicazione web spesso è frutto dell’esperienza dell’architetto.
Una volta definito lo stack tecnologico da adottare, vengono presi in esame nuovi punti derivanti dalla tecnologia adottata (php, .net, java, altro) e si riesaminano i punti precedente: continuous management.
Voi che scelte adottate?