Nelle web-app (applicazioni software costruite mediante tecnologie web e fruibili via web) ci sono due suddivisioni: client e server.

Un client si connette al server. Nel caso web, quindi avendo un server HTTP, ci sono Richieste HTTP (HTTP Request) e Risposte HTTP (HTTP Response).

Un utente mediante il client HTTP (ad esempio un web-browser come Mozilla Firefox o Google Chrome) effettua richieste HTTP che il server (backend) risponderà con una risposta HTTP che il client HTTP elaborerà (nel frontend, la parte vicina all’utente, ad esempio che gestisce l’aspetto grafico dell’interfaccia grafica utente di una web-app).

Per gestire le richieste ci si serve ad esempio di un Controller, un componente software che risponde alle richieste all’interno della web-app lato server (back-end).

Mi vengono in mente alcuni design pattern, ovvero modi riutilizzabili di strutturare i meccanismi software, modi ricorrenti e standardizzati conseguentemente.

Il pattern Front Controller specifica che le richieste HTTP sono filtrate dal front controller che le gestisce, gestendo quindi un filtraggio dell’accesso alle risorse HTTP, ad esempio con blocchi in caso di mancata autorizzazione all’accesso, elaborazioni quali il templating HTML, che vedremo tra poco, e tutte le altre necessità che questa strutturazione software consente di risolvere (strutturazione architetturale).

Il Templating HTML è un modo di riusare del codice HTML, che però può variare, avendo quindi parti prefissate e altre inserite all’occorrenza dinamicamente dal software. Il look appare consistente anche grazie a questo.

Nel design pattern MVC (ModelloVistaControllore) il controllore gestisce le richieste HTTP (iniziate dal client e risposte dal server che le invia al client che le elabora). La vista è un template HTML che viene dinamicizzato dal Modello contenente i dati del software da mostrare (inserendo tali dati nella vista/template HTML).

Il templating può essere effettuato sia lato server sia lato client, anche mescolando gli approcci risolutivi nella stessa applicazione.

Un templating lato server è ottenibile quando il controllore passa i dati del modello alla vista come template HTML elaborato lato server. Al client arriva il template già riempito con i dati.

Un templating lato client HTTP è ottenibile mediante una richiesta del modello al server, e una volta ricevuto il modello dal server esso riempirà le parti dinamiche del template lato client (ad esempio un client HTML+JavaScript che mediante il JS genera l’ HTML dinamico servendosi dei dati del modello ottenuto mediante una apposita richiesta HTTP, stile AJAX/REST). Il client riempe il template con i dati, presi i dati dal server (e dall’utente).

Quindi i template esistono sia nel client che nel server, seguendo un design di una architettura distribuita, in questo caso distribuita tra clients e servers (come potrebbe anche esserlo tra nodi di rete e peers vedasi PeerToPeer/P2P).