Metodi di separazione tra front-end e back-end con javascript full stack?

Supponiamo che io abbia un front-end che è principalmente un'applicazione a pagina singola scritta usando angolare, grugnito e pergolato. E supponiamo che io abbia un backend, che è principalmente solo un'API REST situata in cima a un ORM, che memorizza / recupera oggetti da un database, usando cose come grunt, express e sequelize.

L'applicazione angolare fa tutto il materiale visivo che l'utente vede, ma lo fa essendo una GUI sui servizi forniti dal back-end.

Sarebbe desiderabile separarli in due differenti codebase, per consentire sviluppo indipendente, versioning, integrazione continua, spinta allo sviluppo, ecc.

La mia domanda è: quali metodi ci sono per farlo in modo pulito? Esistono best practice consigliate per JavaScript full-stack?

L'opzione n. 1 sembra essere un monolite, cioè "non separarli". Il pro è che la catena di costruzione è semplice e tutto è in un unico posto, ma sembrano esserci molti svantaggi; più difficile da versione indipendente, un fronte rotto significa un retro non schierabile, e così via.

L'opzione n. 2 sembra essere un quasi monolite, in cui la catena di build del front-end comporta la scrittura di un mucchio di file sul back-end. La distdirectory sul front-end farebbe riferimento a una directory sul back-end, quindi essenzialmente quando il front-end viene minimizzato, modificato, ecc., Finisce per pubblicare sul back-end, che esegue tutto.

L'opzione n. 3 sembra completamente separata: front-end e back-end eseguono ciascuno i propri server su porte diverse e sono progetti completamente separati. Lo svantaggio sembra che debbano essere configurati per conoscere le reciproche porte; il back-end deve consentire a CORS dal front-end e il front-end deve sapere dove dovrebbero trovarsi tutti quegli endpoint.

L'opzione n. 4 potrebbe essere quella di utilizzare qualcosa come docker-compose per sistemare il tutto insieme.

Sono sicuro che ci sono altre opzioni. Qual è la migliore pratica consigliata?

È un'applicazione front-end, back-end, con un'interfaccia REST nel mezzo. Hai già una separazione completa.

Il mio voto è per l'opzione # 3. Sembri preoccupato per la configurazione, ma questo è un po 'il punto. La configurazione consente di avere una separazione completa senza la necessità di associazioni di codice strettamente accoppiate. Se sei preoccupato per CORS, metti tutto in un dominio. Se devi avere CORS, il modo migliore per gestirlo è una configurazione.

Ma non esiste una "migliore pratica" qui. La migliore pratica è quella che soddisferà al meglio le tue esigenze specifiche.

Sì, dovresti separare i due e trattare l'app front-end come un'app di terze parti: potresti eventualmente aggiungere un altro client, ad esempio un'app mobile, e se il primo client è stato creato in questo modo la tua vita sarà più facile.

L'uso dei container docker o di un altro sistema di distribuzione riguarda principalmente il back-end, poiché il front-end dell'app è solo un asset statico che deve essere risolto. Puoi ospitare queste risorse staticamente nel tuo server o da qualche altra parte come una CDN come il cloudfront.

Evitare cors ti salverà una piccola configurazione, ma come indicato nella risposta sopra, questo è il punto. L'uso di cors (e token auth) preparerà meglio il tuo backend anche per altri client.

Modifica: per quanto riguarda le best practice js full stack - Vorrei solo dire questo, essere coerenti. Se stai usando le promesse (e dovresti), fallo su entrambi i lati. Mantieni lo stesso stile js e la stessa formattazione, usa le stesse librerie di test (ove possibile), ecc.