È normale che il design disgiungi completamente le applicazioni Web di backend e frontend e consente loro di comunicare con l'API REST (JSON)?

Question

È normale che il design disgiungi completamente le applicazioni Web di backend e frontend e consente loro di comunicare con l'API REST (JSON)?

#1 da (14 voti)
#2 da (1 voti)
#3 da (0 voti)

17

Sto creando una nuova applicazione web aziendale e voglio raggiungere:

Utilizza le migliori tecnologie dai loro rispettivi reami. Voglio un framework di backend affidabile con ORM solido. E voglio il più avanzato framework SPA (applicazione a singola pagina) con l'uso delle più aggiornate funzionalità HTML e Javascript per l'applicazione frontend
Esporre le entità di backend e i servizi aziendali per l'utilizzo da diversi tipi di applicazioni, ad es. applicazioni web, dispositivi mobili (Android) e possibilmente altri tipi (dispositivi intelligenti, ecc.)

Quindi, per soddisfare entrambi i requisiti, sono incline a separare completamente la mia applicazione nelle applicazioni backend e frontend e organizzare la comunicazione tra loro utilizzando REST API (JSON). Questo approccio sonoro?

Tale separazione non è una soluzione di progettazione evidente, perché molte tecnologie di applicazioni Web hanno livelli di visualizzazione 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 vista, PHP Yii con view layer, Java JSF / Facelets salva completamente lo stato dei loro componenti sul server). Quindi, ci sono molte tecnologie in giro che propongono un accoppiamento più strong e promettono tempi di sviluppo più rapidi e più percorsi standard. Quindi - Devo essere prudente quando inizi a utilizzare le tecnologie in modo non ampiamente utilizzato.

Come capisco, il frontend SPA completamente separato nasce solitamente dalla necessità di utilizzare API di terze parti. Ma è un design del suono disaccoppiato quando sia il backend che il frontend sono sviluppati da una società?

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

design api rest front-end backend

posta TomR 04.12.2016 - 14:41

fonte

3 risposte

Leggi altre domande sui tag design api rest front-end backend

Come devo archiviare i dati di sola lettura da distribuire con la mia applicazione? Come testare l'unità o eseguire i test automatici più efficaci sul codice grafico per OpenGL?

score 14 · Answer 1

Is it normal design to completely decouple backend and frontend web applications and allow them to communicate with (JSON) REST API?

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

Una SPA ha alcuni problemi ad essa associati. Ecco alcuni che mi vengono in mente adesso:

è principalmente JavaScript. Un errore in una sezione della tua applicazione potrebbe impedire ad altre sezioni dell'applicazione di funzionare a causa di quell'errore Javascript. Con le pagine servite dal server (SpringMVC, PHP, ecc.) Si ricarica 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 . Hai bisogno di questo? Il tuo sito è pubblico? Google può capire Javascript e cercare di dare un senso al tuo sito, ma fondamentalmente dai il controllo a un bot e sperare per il meglio. Riprendere il controllo potrebbe significare dover contare su altri strumenti come PhantomJS .
applicazione front-end separata significa progetti separati, pipeline di implementazione, strumenti aggiuntivi, ecc.
la sicurezza è più difficile da fare quando tutto il codice si trova sul client;

Certo, ci sono anche vantaggi SPA:

interagisce completamente nel front-end con l'utente e carica solo i dati necessari dal server. Quindi migliore reattività e user experience;
a seconda dell'applicazione, alcune elaborazioni eseguite sul client significano risparmiare il server di tali calcoli.
ha una maggiore flessibilità nell'evoluzione del back-end e del front-end (puoi farlo separatamente);
se il tuo back-end è essenzialmente un'API, puoi avere davanti altri client come applicazioni native per Android / iPhone;
la separazione potrebbe rendere più semplice per gli sviluppatori front-end eseguire CSS / HTML senza che sia necessario eseguire un'applicazione server sul proprio computer.

Quindi la cosa è 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 e poi scegli in base alla tua situazione.

score 1 · Answer 2

La risposta alla tua domanda è semplice. Sì. Quello che proponi è un "approccio sano". Ma poi, quello che penso tu voglia chiedere è che è un approccio "migliore", e sfortunatamente nessuno, se noi possiamo rispondere a questo per te. I fattori coinvolti abbracciano troppe faccette che senza divulgare tutto ciò che riguarda la tua organizzazione e le esigenze del prodotto, nessuna conclusione reale può essere fatta. Penso che tu sappia già cosa fare comunque.

score 0 · Answer 3

Normale con avvertimenti.

I framework javascript front-end sono limitati in ciò che possono fare. Se crei apis grezzi per l'utilizzo da parte di più applicazioni, in genere richiedono l'elaborazione lato server delle chiamate api raw 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 solo l'unica applicazione web, puoi tagliare il livello 'api exposing business logic' e solo il codice web lato server chiama direttamente la logica di business.

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

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

Inoltre, avendo la javascript chiama lo stesso host dal quale è stata pubblicata significa che non devi muckare con cors