È normale progettare per disaccoppiare completamente le applicazioni Web back-end e front-end e consentire loro di comunicare con l'API REST (JSON)?

Sto creando una nuova applicazione Web aziendale e voglio ottenere:

• Usa le migliori tecnologie dei rispettivi regni. Voglio un framework backend affidabile con ORM solido. E voglio il più avanzato framework SPA (applicazione a pagina singola) con l'uso delle funzionalità HTML e Javascript più aggiornate per l'applicazione frontend
• Esporre entità back-end e servizi aziendali per l'utilizzo da diversi tipi di applicazioni - ad esempio applicazioni Web, dispositivi mobili (Android) e possibilmente altri tipi (dispositivi intelligenti, ecc.)

Quindi, per soddisfare entrambi i requisiti, sono propenso a separare completamente la mia applicazione in applicazioni back-end e front-end e organizzare la comunicazione tra di loro utilizzando l'API REST (JSON). Questo è un approccio valido?

Tale separazione non è una soluzione progettuale ovvia, poiché molte tecnologie di applicazione Web hanno livelli di vista integrati in cui l'applicazione lato server controlla più o meno la generazione della vista e gestisce parzialmente le risposte dalla vista (ad esempio SpringMVC con livello di vista, PHP Yii con vista livello, Java JSF / Facelets salva completamente lo stato dei loro componenti sul server). Quindi, ci sono molte tecnologie in giro che propongono un accoppiamento più forte e promettono tempi di sviluppo più rapidi e percorsi più standardizzati. Quindi - devo essere cauto quando inizi a usare tecnologie in un modo che non è ampiamente usato.

A quanto ho capito, il frontend SPA completamente separato di solito nasce dalla necessità di utilizzare API di terze parti. Ma una tale progettazione del suono disaccoppiata quando sia il backend che il frontend sono sviluppati da un'azienda?

La mia scelta di tecnologie attualmente è Java / Spring backend e Angular2 / Web Components / Polymer per frontend - se mi è permesso dirlo. Ma questo è irrilevante per questa domanda, perché questa domanda riguarda il design generale e non la scelta delle tecnologie concrete?

È normale progettare per disaccoppiare completamente le applicazioni Web back-end e front-end e consentire loro di comunicare con l'API REST (JSON)?

Sì è normale Ma è normale solo se devi avere quel tipo di separazione e non stai forzando questa configurazione nella tua applicazione generale.

Una SPA presenta alcuni problemi ad essa associati. Qui ci sono solo alcuni che mi vengono in mente ora:

• è principalmente JavaScript. Un errore in una sezione dell'applicazione potrebbe impedire il funzionamento di altre sezioni dell'applicazione a causa dell'errore Javascript. Con le pagine servite dal server (SpringMVC, PHP, ecc.) Ricarichi una nuova sezione;
• CORS . Non necessariamente obbligatorio ma spesso il back-end si trova su un nome di dominio diverso rispetto al front-end. Quindi ora devi affrontare i problemi di sicurezza del browser;
• SEO . Ne hai bisogno? Il tuo sito è pubblico? Google può capire Javascript e provare a dare un senso al tuo sito, ma in pratica dai il controllo a un bot e speri per il meglio. Riprendere il controllo potrebbe significare dover fare affidamento su altri strumenti come PhantomJS .
• applicazione front-end separata significa progetti separati, pipeline di distribuzione, strumenti extra, ecc .;
• la sicurezza è più difficile da fare quando tutto il codice è sul client;

Certo, ci sono anche vantaggi SPA:

• interagire completamente nel front-end con l'utente e caricare solo i dati necessari dal server. Migliore reattività ed esperienza utente;
• a seconda dell'applicazione, alcune elaborazioni eseguite sul client indicano che si risparmia il server di tali calcoli.
• avere una migliore flessibilità nell'evoluzione del back-end e del front-end (puoi farlo separatamente);
• se il tuo back-end è essenzialmente un'API, puoi avere altri client davanti come applicazioni native per Android / iPhone;
• la separazione potrebbe rendere più semplice per gli sviluppatori front-end eseguire CSS / HTML senza la necessità di avere un'applicazione server in esecuzione sul proprio computer.

Quindi il fatto è che ci sono vantaggi e svantaggi per entrambi gli approcci (pagine SPA vs server). Dedica un po 'di tempo alla ricerca di entrambe le opzioni, quindi scegli in base alla tua situazione.

La risposta alla tua domanda è semplice. Sì. Quello che proponi è un approccio valido . Ma poi, ciò che penso tu voglia chiederti è se si tratta di un approccio migliore e, sfortunatamente, nessuno di noi può rispondere per te. I fattori coinvolti abbracciano troppe sfaccettature che senza divulgare tutto ciò che riguarda sia l'organizzazione che i requisiti del prodotto, non è possibile giungere a una conclusione reale. Penso che tu sappia già cosa fare comunque.

Normale con avvertenze.

i framework javascript front-end sono limitati in ciò che possono fare. Se si creano API non elaborate per l'utilizzo da più applicazioni, in genere richiedono l'elaborazione lato server delle chiamate API non elaborate per visualizzare i modelli che funzionano con quella particolare applicazione.

Quindi un'architettura 'normale' potrebbe essere:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Ora, se hai una sola applicazione web, puoi tagliare il livello 'api esponendo la logica aziendale' e avere solo il codice web lato server che chiama direttamente la logica aziendale.

Poiché hai separato la logica aziendale nella sua libreria, è ancora disaccoppiata dalla logica dell'interfaccia utente e puoi sempre aggiungere un livello di servizio in un secondo momento.

Allo stesso modo, poiché il servizio API è chiamato dal codice lato server, non si ha una comunicazione http limitata. (anche se questo è praticamente universale ora)

Inoltre, avere il javascript che chiama lo stesso host da cui è servito significa che non devi scherzare con cors