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

Naviga le tue risposte
14

Al lavoro, abbiamo una grande applicazione interna che è in fase di sviluppo da quasi 2 anni; Ho appena aderito al progetto e alcune delle architetture mi hanno leggermente perplesso, quindi spero che qualcuno qui possa fornire qualche consiglio prima di uscire per chiedere agli architetti le stesse domande (così posso avere una discussione informata con loro ).

Le mie scuse se il sotto è un po 'lungo, voglio solo provare a dipingere 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ù non fa altro che aggregare dati da vari altri servizi. Quindi in pratica è un host per un'applicazione AngularJS; c'è letteralmente un controller MVC che avvia il lato client, e quindi ogni altro controller è un controller WebAPI.

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

  • Tuttavia, le chiamate vengono infine inoltrate attraverso un'altra serie di applicazioni WebAPI (in genere queste sono per area di business, ad esempio sicurezza, dati dei clienti, dati sui prodotti, ecc.). Tutte queste WebAPI vengono distribuite anche in scatole dedicate; abbiamo anche 4 di queste caselle.

  • Con un'unica eccezione, queste WebAPI non vengono utilizzate da altre parti della nostra organizzazione.

  • Infine queste WebAPI fanno ancora un altro gruppo di chiamate ai servizi "back-end", che sono tipicamente servizi asmx o wcf legati 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 di dati legacy, l'aggregazione, l'esecuzione di regole di business, il solito tipo di cosa.

What has me confused is what possible benefit there is in having such a separation between the WebApplication and the WebAPIs that serve it. Since nobody else is using them, I don't see any scalability benefit (i.e there's no point in putting in another 4 API boxes to handle increased load, since increased load on the API servers must mean there is increased load on the Web servers - therefore there has to be a 1:1 ratio of Web server to Api server)

  • Inoltre non vedo alcun vantaggio di dover effettuare una chiamata HTTP extra Browser = > HTTP = > WebApp = > HTTP = > WebAPI = > HTTP = > Servizi di backend. (che la chiamata HTTP tra WebApp e WebAPI è il mio problema)

  • Quindi, attualmente sto cercando di spingere per spostare le WebAPI correnti da soluzioni separate, per separare solo i progetti all'interno della soluzione WebApplication, con semplici riferimenti di progetto in mezzo e un singolo modello di implementazione. Quindi alla fine diventerebbero solo librerie di classi.

  • Deployment-wise, questo significa che avremmo 8 web box "full stack", al contrario di 4 + 4.

I benefici che vedo del nuovo approccio sono

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

So the question is: am I wrong? Have I missed some fundamental "magic" of having separated WebApplication and WebAPI boxes?

Ho ricercato materiale dell'architettura N-Tier ma non riesco a trovare nulla in loro che possa dare un beneficio concreto alla nostra situazione (dal momento che la scalabilità non è un problema per quanto posso dire, e questo è un l'app interna quindi la sicurezza in termini di applicazioni WebAPI non è un problema.)

And also, what would I be losing in terms of benefits if I were to re-organise the system to my proposed setup?

    
posta Stephen Byrne 10.10.2015 - 00:07
fonte

2 risposte

23

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 posizionato il livello intermedio nel server web, allora ha accesso a tutto ciò che ha - cioè il tuo DB, e dopo sai che ha appena eseguito "select * from users" sul tuo DB e portato via da offline password cracking.

Un altro motivo è il ridimensionamento: il livello Web in cui le pagine sono costruite e manipolate e XML elaborate e tutto ciò richiede molto più risorse rispetto al livello intermedio, che è spesso un metodo efficiente per ottenere dati dal DB al livello web. Per non parlare del trasferimento di tutti i dati statici che risiedono (o sono memorizzati nella cache) sul server web. Aggiungere altri server Web è un compito semplice una volta passato 1. Non dovrebbe esserci un rapporto 1: 1 tra i livelli web e logico - Ho visto 8: 1 in precedenza (e un rapporto 4: 1 tra la logica livello e DB). Dipende da ciò che fanno i tuoi livelli e dalla quantità di memorizzazione nella cache.

I siti web non si preoccupano delle prestazioni di un singolo utente in quanto sono costruiti per scalare, non importa che ci sia una chiamata in più che rallenta un po 'le cose se significa che puoi servire più utenti.

Un altro motivo per cui è utile avere questi livelli è che impone più 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 in quanto disponevano di specialisti per ogni livello che potevano apportare modifiche molto rapidamente perché non dovevano preoccuparsi degli altri livelli, ovvero un javscript dev dell'interfaccia utente potrebbe aggiungere una nuova sezione al sito semplicemente consumando un nuovo servizio web che qualcun altro ha sviluppato.

    
risposta data 10.10.2015 - 20:47
fonte
2

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

Da come ho capito le tue descrizioni, il " WebAPI " nella tua architettura serve come tipo di middleware fatto da te. Ora puoi cercare quali vantaggi ci sono negli usi di un middleware. Fondamentalmente la tua webapp non dovrebbe mai essere adottata se hai cambiato il tuo sistema di backoffice (a patto che l'interfaccia WebAPI mantenga lo stesso).

Per andare oltre: immagina di avere un database clienti (servizio di back-end) e hai 5 app Web che comunicano con quel database. Se si sostituisce il sistema di database del cliente con un nuovo sistema (come da un altro fornitore e non si può influenzare le interfacce del servizio Web) è molto probabile che sia necessario modificare il livello di comunicazione di tutte le 5 applicazioni Web. Se comunichi tramite WebAPI , dovrai semplicemente modificare il livello di comunicazione di WebAPI .

Fondamentalmente, Layer Architecture è attualmente considerato sia come: Pattern e Anti-Pattern. (Vedi: Codice di Lasagna ) Se hai solo 1 sistema senza piani per estenderlo ulteriormente nei prossimi anni, preferirei considerare questo come anti-pattern. Ma questo sarebbe un giudice irrealistico in quanto non conosco le circostanze / situazioni esatte:)

    
risposta data 10.10.2015 - 19:55
fonte

Leggi altre domande sui tag

PBI vs User Story Come facilitare la manutenzione del codice guidato dagli eventi?