Vantaggi dell'utilizzo di server API e UI separati per l'applicazione Web

Al lavoro, abbiamo una vasta applicazione interna che è in fase di sviluppo da quasi 2 anni; Mi sono appena unito al progetto e parte dell'architettura mi ha lasciato un po 'perplesso, quindi spero che qualcuno qui possa fornire qualche consiglio prima di uscire per porre agli architetti queste stesse domande (così posso avere una discussione informata con loro ).

Mi scuso se il seguito è un po 'lungo, voglio solo provare a disegnare una buona immagine di ciò che il sistema è prima di porre la mia domanda :)

• Il modo in cui il sistema è configurato è che abbiamo un'applicazione web principale (asp.net, AngularJS) che per lo più aggrega solo i dati di vari altri servizi. Quindi sostanzialmente è un host per un'applicazione AngularJS; esiste letteralmente un controller MVC che avvia il lato client e quindi ogni altro controller è un controller WebAPI.

• Le chiamate dal lato client vengono gestite da questi controller, che vengono sempre distribuiti in caselle che non fanno altro che ospitare l'applicazione Web. Al momento abbiamo 4 scatole di questo tipo.

• Tuttavia, le chiamate vengono infine instradate a un altro set di applicazioni WebAPI (in genere si tratta di aree di business, quali sicurezza, dati dei clienti, dati dei prodotti, ecc.). Tutte queste API Web vengono distribuite anche in box dedicati; abbiamo anche 4 di queste scatole.

• Con una sola eccezione, queste API Web non sono utilizzate da altre parti della nostra organizzazione.

• Infine, queste WebAPI effettuano ancora un altro set di chiamate ai servizi "back-end", che sono in genere servizi legacy asmx o wcf che vengono schiacciati su vari sistemi ERP e archivi dati (sui quali non abbiamo alcun controllo).

• La maggior parte della logica aziendale della nostra applicazione si trova in questi WebApis, come la trasformazione dei dati legacy, l'aggregazione, l'esecuzione delle regole aziendali, il solito tipo di cose.

Ciò che mi ha confuso è quale possibile beneficio ci sia nell'avere una tale separazione tra la WebApplication e le WebAPI che la servono. Dato che nessun altro li sta usando, non vedo alcun vantaggio in termini di scalabilità (vale a dire che non ha senso inserire altre 4 caselle API per gestire un carico maggiore, poiché un carico maggiore sui server API deve significare che c'è un carico maggiore sui server Web - pertanto deve esserci un rapporto 1: 1 tra server Web e server Api)

• Inoltre non vedo alcun vantaggio nel dover effettuare una chiamata HTTP aggiuntiva Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => Servizi di back-end. (quella chiamata HTTP tra WebApp e WebAPI è il mio problema)

• Quindi sto attualmente cercando di spingere per spostare le attuali WebAPI da soluzioni separate, a soli progetti separati all'interno della soluzione WebApplication, con semplici riferimenti di progetto in mezzo e un singolo modello di distribuzione. Quindi alla fine diventerebbero solo biblioteche di classe.

• Per quanto riguarda la distribuzione, ciò significa che avremmo 8 caselle Web "full stack", anziché 4 + 4.

I vantaggi che vedo del nuovo approccio sono

• Aumento delle prestazioni perché esiste un ciclo in meno di serializzazione / deserializzazione tra l'applicazione Web e i server WebAPI
• Tonnellate di codice che possono essere cancellate (cioè non c'è bisogno di mantenere / testare) in termini di DTO e mapper ai confini in uscita e in entrata rispettivamente dei server Web Application e WebApi.
• Migliore capacità di creare test di integrazione automatizzati significativi, perché posso semplicemente deridere i servizi di back-end ed evitare il disordine attorno ai salti HTTP di livello intermedio.

Quindi la domanda è: sbaglio? Ho perso qualche "magia" fondamentale di aver separato le caselle WebApplication e WebAPI?

Ho fatto ricerche su alcuni materiali dell'architettura di livello N ma non riesco a trovare nulla in essi che possa dare un beneficio concreto alla nostra situazione (dal momento che la scalabilità non è un problema per quanto posso dire, e questa è un'app interna quindi la sicurezza in termini di applicazioni WebAPI non è un problema.)

Inoltre, cosa perderei in termini di benefici se dovessi riorganizzare il sistema alla configurazione proposta?

Una ragione è la sicurezza - se (haha! Quando ) un hacker ottiene l'accesso al tuo server Web front-end, ottiene l'accesso a tutto ciò a cui ha accesso. Se hai inserito il tuo livello intermedio nel web server, allora ha accesso a tutto ciò che ha - vale a dire il tuo DB, e la prossima cosa che sai, ha appena eseguito "seleziona * dagli utenti" sul tuo DB e lo ha rimosso da offline cracking password.

Un altro motivo è il ridimensionamento: il livello Web in cui le pagine sono costruite e modificate ed elaborate XML e tutto ciò richiede molta più risorsa rispetto al livello intermedio, che è spesso un metodo efficiente per ottenere dati dal DB al livello Web. Per non parlare del trasferimento di tutti quei dati statici che risiedono (o sono memorizzati nella cache) sul server web. L'aggiunta di più server Web è un'operazione semplice dopo aver superato 1. Non dovrebbe esserci un rapporto 1: 1 tra livelli Web e livelli logici - ho già visto 8: 1 prima (e un rapporto 4: 1 tra logica livello e DB). Dipende da cosa fanno i tuoi livelli e da quanta cache si ripete in essi.

I siti Web non si preoccupano davvero delle prestazioni per singolo utente poiché sono costruiti su scala, non importa che ci sia una chiamata in più che rallenta un po 'le cose se ciò significa che puoi servire più utenti.

Un altro motivo per cui può essere utile avere questi livelli è che impone maggiore disciplina nello sviluppo in cui viene sviluppata un'API (e facilmente testata in quanto autonoma) e quindi l'interfaccia utente sviluppata per consumarla. Ho lavorato in un posto che ha fatto questo: diversi team hanno sviluppato diversi livelli e ha funzionato bene dato che avevano specialisti per ogni livello che potevano dare il via ai cambiamenti molto velocemente perché non dovevano preoccuparsi degli altri livelli - cioè un dev javscript dell'interfaccia utente potrebbe aggiungere una nuova sezione al sito semplicemente consumando un nuovo servizio web sviluppato da qualcun altro.

Penso che non ci sia una risposta giusta / sbagliata qui. Hai chiesto ai tuoi colleghi lo scopo di questa architettura?

Da come comprendo le tue descrizioni, il " WebAPI " nella tua architettura funge da tipo di Middleware fatto da sé. Ora puoi cercare quali vantaggi ci sono negli usi di un middleware. Fondamentalmente il tuo Webapp non avrebbe mai bisogno di essere adottato se hai cambiato il tuo sistema di backoffice (purché l' interfaccia WebAPI mantenga lo stesso).

Per andare oltre: immagina di avere un database dei clienti (servizio back-end) e di avere 5 app Web che comunicano con quel database. Se si sostituisce il sistema di database dei clienti con un nuovo sistema (come da un altro fornitore e non è possibile influenzare le interfacce del servizio Web), molto probabilmente sarà necessario modificare il livello di comunicazione di tutte e 5 le applicazioni Web. Se comunichi tramite la tua WebAPI , dovresti semplicemente modificare il livello di comunicazione della WebAPI .

Fondamentalmente, Layer Architecture è oggi considerata sia: Pattern che Anti-Pattern. (Vedi: Lasagna-Code ) Se hai solo 1 sistema senza piani per espandere ulteriormente questo nei prossimi anni, preferirei considerare questo come anti-pattern. Ma questo sarebbe un giudice irrealisticamente taff dato che non conosco le circostanze / situazioni esatte :)