Risposta breve:
Non ho abbastanza informazioni sul tuo ambiente e sugli obiettivi per dare una risposta breve semplice e utile. Guarda la mia lunga risposta qui sotto.
Risposta lunga:
Questa è una domanda davvero difficile a cui rispondere. Ci sono molte cose specifiche per il tuo team e il tuo progetto che portano a decidere su una migliore architettura per il tuo sistema. Per rispondere bene, è necessario avere maggiori dettagli sugli obiettivi e i requisiti per questa app Web. Ad esempio:
- L'API sarà pubblica o utilizzata solo dall'app Web? Ad esempio, dovrebbe essere pensato come un servizio interno protetto da un firewall e accessibile solo all'app Web o qualcos'altro?
- Quanto è previsto il traffico per questa app? (1k utenti / mese? 10k? 100k? 1m?)
- Quanto velocemente devono essere caricate le pagine? (cioè, quanto deve essere reattiva l'applicazione a fel vs. in realtà?)
- Quanto tempo hai per costruire l'app?
- Hai davvero bisogno di OAuth?
- Quante persone hai nel tuo team?
- Se nello spettro di "esperienza di apprendimento" a "supportare un'attività", questo progetto si trova?
- Dove nello spettro di "pratico, fallo fare" a "deve essere perfettamente tecnicamente corretto" questo progetto sta mentendo?
- Questa app verrà indicizzata dai motori di ricerca o sarà per lo più privata (dietro un meccanismo di autenticazione)?
La mia opinione sulla domanda "pratica" e "perfetta" è, rendetela più pratica. Se non viene spedito, il progetto non ha importanza al di fuori di ciò che impari.
Le risposte alle domande 1, 2 e 3 portano a quanto deve essere grande e complesso il sistema. (Se è previsto molto traffico e il tempo di caricamento della pagina non è così importante, potrebbero essere introdotti più livelli e più sistemi. Se ci sono aree di dati che possono essere memorizzate nella cache, è possibile compensare altre posizioni in cui è più lento ottenere dati .)
Per l'autenticazione e la creazione dell'account. Questo è un argomento sorprendentemente complesso che richiede tempo per capire veramente. Sia che usi OAuth (supponendo OAuth 2.0) contro la tua API, l'autenticazione con password regolare o l'autenticazione OAuth contro terzi (Facebook, Google, ecc.), Avrai comunque bisogno di un modo per creare account utente all'interno del tuo sistema.
Su OAuth: l'uso più comune di OAuth è quello di consentire a un sistema / servizio di terze parti di accedere ai dati nel tuo sistema di proprietà di uno dei tuoi utenti. Ha la flessibilità, tuttavia, per consentire il login basato su password. Ciò significa che, una volta che un utente ha creato un account sul proprio sistema, è possibile utilizzare il tipo di concessione "Credenziali password proprietario risorse" in OAuth 2.0 per autenticare tale utente. Dai un'occhiata a full rfc se non lo hai ancora fatto.
Ecco un paio di modi comuni per architettare le applicazioni web (questo non è completo e ci sono un sacco di variazioni):
- Utilizzare un framework front-end, in javascript (think ember, angular o similar), per gestire tutte le viste e richiedere i dati appropriati dall'API su un server. Questa API potrebbe quindi essere un'API pubblica o un'API utilizzata solo da quell'app.
- Crea un'architettura di server multilivello in cui è presente un livello di app Web esterno con servizi interni (API) per ciascuno dei servizi necessari. Il livello dell'app Web ha le viste e ottiene tutti i dati del modello dai servizi interni. Tutti i servizi interni sono protetti da un firewall. Ad esempio, guarda come TripAdvisor lo fa.
- Fornire un'API pubblica e creare un'app web standard basata su server in cui serve singole pagine html generate da visualizzazioni sul server. (Ad esempio, l'app Web non utilizza l'API pubblica ma accede direttamente a tutti i database e servizi interni.)
- Fornisci un'API pubblica per l'utilizzo di terze parti e crea un'API semi-privata utilizzata solo dall'app Web. Questa è una variazione specifica su # 1.
Vorrei seguire # 1, # 3 o # 4:
- Se stavo costruendo un sistema che so che avrà < 100k utenti
- se dovessi supportare > 100k utenti e il numero di funzionalità nel sistema è piccolo (ad esempio, non un prodotto estremamente complesso)
Seguirò una combinazione di (# 2 e (# 1, # 3 o # 4)) (parentesi per chiarezza di ordine operativo):
- Se avessi un sacco di elaborazione di backend in corso con molti altri sistemi
- se dovessi supportare > 100k utenti e c'è un set di funzionalità molto grande / molti tipi diversi di dati da gestire
Se avessi un prodotto che era pubblicamente disponibile e sarebbe stato indicizzato dai motori di ricerca, vorrei non fare # 1 né # 4.
La mia squadra conta molto per me. Le loro preferenze, esperienza e desiderio di imparare influenzano ciò che scelgo architettonicamente tra # 1 / # 4 e # 3.