Smetti di pensare in termini di MVC. Solo MVC descrive bene le interazioni se tutto accade sul lato server. Devi pensare a un livello più alto di astrazione. Ad esempio, Data Layer (ex database), livello API (ex lato server), Livello client (Webapp, app IOS, App Android).
Una SPA di base funziona sulla premessa che l'intero sito gira su un unico grande file HTML. I ricaricamenti non richiedono un round trip sul server perché in pratica stai mostrando / nascondendo diverse sezioni di codice.
In pratica non è necessariamente vero perché il framework (ex Angular) può estrarre template partial e dati dagli URL in background. Sembra che tu capisca molto ma non riesci a capire come dovrebbero essere separate le preoccupazioni tra server / client.
Per i template, fai lo stesso come faresti con Django. Tranne che, invece di caricare i file da una directory locale, devi recuperare i partial dal server.
Per generare viste che includono dati devi creare un controller in grado di recuperare i dati e utilizzarli nella vista parziale. Ci sono molti modi per farlo, ma il più comune è semplicemente creare un'API sul lato server che accetta richieste di dati e risponde con i risultati in JSON.
In termini MVC. Sia il server che il client utilizzeranno ancora modelli, viste e controller:
Sul server (ovvero l'API dei dati). I modelli sono le classi di accesso al database / archiviazione. Invece di generare codice HTML grezzo, le viste verranno utilizzate per formattare / serializzare i dati per il trasferimento. I controller elaborano i dettagli disordinati tra i modelli e le viste.
Sul client (cioè sul client WebApp). I modelli sono le funzioni che gestiscono il recupero e la deserializzazione delle richieste di dati. Le viste sono i partial parziali html che vengono analizzati in HTML statico. I controllori / le direttive gestiscono combinando i due.
Puoi ancora generare HTML sul lato server?
Ovviamente. Quanto lavoro decidi di fare nel client vs server dipende dai tuoi obiettivi.
Allora qual è il vantaggio dei framework lato client?
Se il tuo obiettivo è creare una SPA, i framework come Angular sono un'opzione molto più robusta rispetto alle alternative che consistono nel lanciare una serie di richieste AJAX, quindi collegarle al DOM usando qualcosa come jQuery.
Cosa c'è di così speciale nei framework lato client?
Nulla in realtà, spingono la responsabilità della generazione di HTML nel client. Invece di dividere i template HTML e la manipolazione dinamica tra client e server ora puoi fare entrambi nel client. Fornisce una separazione più chiara dei problemi e riduce il carico sul server.
Se hai bisogno di un livello dati che può essere accesso da più piattaforme (ex IOS, sito Web, Android), probabilmente hai già isolato le richieste di dati nella propria API. Se hai già fatto ciò, inserire il codice lato client sul client ha senso visto che lo stai già facendo per le altre piattaforme.
Semplificare il server a un livello dati semplifica la vita a chi sviluppa su più piattaforme. I framework lato client hanno reso più semplice il processo di recupero dei dati e generazione di HTML in modo dinamico sul client. Se il tuo obiettivo è costruire una SPA, l'utilizzo di un framework fornirà un buon scaffold su cui costruire.
Il principale svantaggio della generazione HTML lato client è che si basa su JavaScript e la maggior parte dei webcrawler dei motori di ricerca sono troppo stupidi per usare JavaScript. Ciò significa che se si dispone di un sito con contenuti pesanti, si avrà un brutto momento nel tentativo di far sì che i motori di ricerca indicizzino il contenuto. Esistono approcci ibridi per caricare in modo condizionale i contenuti generati dal server ai webcrawler, ma aggiungono un ulteriore livello di complessità in modo che i compromessi superino probabilmente i benefici.