Layout di architettura per applicazione SPA

Question

Layout di architettura per applicazione SPA

#1 da (1 voti)

0

Ho un'applicazione SPA esistente in cui le chiamate api dal browser dell'utente vengono inoltrate al server applicazioni ospitato separatamente. Il mio server delle applicazioni ha tutta la logica aziendale e il repository per connettersi al DB. Qualcosa come sotto:

stiamopensandodifondereillivellodell'applicazioneconlapausaAPIinmodocheilnuovodesignsiasimilea:

Tecnicamente entrambi i progetti servono allo scopo, ma mi piacerebbe sapere quali sono i punti decisionali dell'architettura per scegliere l'uno rispetto all'altro e quali sono i pro ei contro se devo considerare l'uno contro l'altro.

architecture web-development web-applications application-design enterprise-architecture

posta Rahul Agarwal 26.09.2018 - 08:01

fonte

1 risposta

Leggi altre domande sui tag architecture web-development web-applications application-design enterprise-architecture

Corrispondenza sottodominio Oltre all'ovvio, c'è una buona ragione per la versione dei componenti separati in una versione generale?

score 1 · Answer 1

Nel primo approccio disponi di un servizio aziendale sottostante e di un backend-for-frontend separato che lo accede. Nel secondo approccio, il servizio aziendale fornisce direttamente l'interfaccia utente, senza un servizio gateway intermedio.

Il compromesso raggiunto dal secondo approccio è la semplicità operativa per la flessibilità architettonica e la separazione delle preoccupazioni.

Eliminando il servizio dell'adattatore, il servizio aziendale sottostante ora deve combinare tutte le preoccupazioni necessarie all'interfaccia utente. Se il tuo intento è quello di isolare preoccupazioni diverse nei microservizi, potresti trovare difficile farlo senza un servizio gateway in primo piano.
Se aggiungi più di un front-end con esigenze diverse, quel singolo servizio aziendale dovrà soddisfare tutti loro. Nella mia esperienza ciò porta in pratica a API disordinate.