At work, we have a large internal application which has been under development for close to 2 years now; I've just recently joined the project and some of the architecture has me slightly perplexed, so I'm hoping someone here can provide some advice before I go out to ask the architects these same questions (so I can have an informed discussion with them).
My apologies if the below is a little long, I just want to try to paint a good picture of what the system is before I ask my question :)
The way the system is setup is that we have one main web application (asp.net, AngularJS) which does mostly just aggregates data from various other services. So basically it is a host for an AngularJS application; there is literally one MVC controller that bootstraps the client side, and then every other controller is a WebAPI controller.
Calls from the client-side are handled by these controllers, which is always deployed to boxes that do nothing but host the Web Application. We currently have 4 such boxes.
However, the calls are then ultimately routed through to yet another set of WebAPI applications (typically these are per business area, such as security, customer data, product data, etc). All of these WebAPIs get deployed together to dedicated boxes as well; we also have 4 of these boxes.
With a single exception, these WebAPIs are not used by any other parts of our organisation.
Finally these WebAPIs make yet another set of calls to the "back end" services, which are typically legacy asmx or wcf services slapped on top of various ERP systems and Data stores (over which we have no control).
Most of our application's business logic is in these WebApis, such as transforming legacy data, aggregating it, executing business rules, the usual type of thing.
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)
I also don't see any benefit at all of having to make an extra HTTP call Browser=>HTTP=>WebApp=>HTTP=>WebAPI=>HTTP=>Backend services. (that HTTP call between WebApp and WebAPI is my problem)
So I am currently looking to push to have the current WebAPIs moved from separate solutions, to just separate projects within the WebApplication solution, with simple project references in between, and a single deployment model. So they would ultimately just become class libraries.
Deployment-wise, this means we would have 8 "full stack" web boxes, as opposed to 4+4.
The benefits I see of the new approach are
- Increase in performance because there is one less cycle of serialisation/deserialisation between the Web application and the WebAPI servers
- Tons of code that can be deleted (i.e. no need to maintain/test) in terms of DTOs and mappers at the outgoing and incoming boundaries of the Web Application and WebApi servers respectively.
- Better ability to create meaningful automatied Integration Tests, because I can simply mock the back-end services and avoid the messiness around the mid-tier HTTP jumps.
So the question is: am I wrong? Have I missed some fundamental "magic" of having separated WebApplication and WebAPI boxes?
I have researched some N-Tier architecture material but can't seem to find anything in them that can give a concrete benefit for our situation (since scalabilty isn't an issue as far as I can tell, and this is an internal app so security in terms of the WebAPI applications isn't an issue.)
And also, what would I be losing in terms of benefits if I were to re-organise the system to my proposed setup?