2

Most of the web applications that I have seen developed in my organisation , have the following components :

JS App (from browser) -> Web server -> Service(s)/Application server(s) -> Database

Each of these components typically does the following:

JS App - The interface (UI) for users to interact with the application from their browsers, typically a single page app.
Web server - Listens to HTTP requests and constructs the response by calling various services (application servers). Application server - Fetches data by calling a database, and other services and processes the data based on some business logic and returns a response.
Database - Stores data.

Let's say my organization runs a hotel booking website, and is planning to provide a new functionality of travel packages, think of a package as consisting of multiple bookings at multiple hotels, travel (trains, flights etc) bookings, etc., this new 'Packages' application would be made up of the following components :

PackagesFrontEnd - JS App
PackagesWebApp - Web server
PackagesService - Application server/service
PackagesDB - Database

The PackagesWebApp would communicate with the PackagesService, and various services that handle bookings for hotels, travel etc., to serve its requests. The PackagesService is pretty much a wrapper on top of the PackagesDB, containing some business logic.

My question is, why do the web and application servers need to be separate here ? in my example, what is the problem with having PackagesWebApp and PackagesService as a single thing ? I have tried asking co workers, and searching online, but could not find a convincing answer for this, heard and read the following reasons:

Separation of concerns: Separating presentation logic and business logic (Why can't this be done at a module level ? with interfaces in between the classes for the layers ? Also, a side effect of this is that people duplicate some business logic like validation for example, in both the components to 'fail fast' but this sometimes comes back to bite when a change was done in one but missed in the other)

Availability: If one component has a bug and it misbehaves, it might bring down both the components (The web app wouldn't be useable anyways if either of the servers is down, even when they are separated, so what is the additional benefit here ? And, even if there is a benefit to this, then, by extension the same thing might happen, where, a bug in the code for feature 'X' thats unrelated to features 'Y' and 'Z' brings down all of them, so why not separate them also ? where do you draw a line for this ?)

On the other hand, there are definitely some overheads that come with having multiple components, like maintaining codebases, integrating components, maintaining infrastructure resources, debugging/finding root cause for issues is more complicated. In such a situation, doesn't separation only make sense if it solves some problem thats worth taking on these additional things ?

Can someone please help me in understanding the reason why this is needed ?

2

The main benefit is that your application servers don't have to think about stuff like:

  • Load balancing.
  • Request / Traffic Routing.
  • Hacking - understand things like Denial of Service attack
  • Upgrades - lets say you want to incrementaly upgrade your application.
  • Logging and filtering of traffic.
  • Specialized HTTP servers for Ajax, Websocket(Async Http server) communication GraphQL (Appolo server) etc...

It should also be noted that the line between HTTP server and Api Gateway is rather weak. Api Gateway can potentialy be realized via webserver.

Here is an example article about NGNIX deployed as Api Gateway https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/

4
  • Thank you for the answer. Though these reasons are valid, these are cross cutting concerns that are not specific to a particular application, so i have seen these responsibilities being organised across a hierarchy of API gateways that handle them for the entire organisation. In such a situation, does the separation still make sense ? – takasugi Feb 21 at 16:07
  • @takasugi what do you think API gateway is ? Web server and Api Gateway can be synonyms. Api Gateway is more or less the pattern which is in one or another way realized. A web server can be used as API gateway. stackoverflow.com/questions/35756663/… – Alexander Petrov Feb 21 at 16:30
  • I understand that, we have a hierarchy of web servers that intercept and route requests based on the path. A request coming to a path like subDomain.orgDomain.com/appName, will pass through three web servers : 1) Company/organisation wide api gateway - handles requests to *.orgDomain.com/* 2) Api gateway for a set of closely related bounded contexts - handles requests to subDomain.orgDomain.com/* 3) Application specific web server - handles requests to subDomain.orgDomain.com/app/* (PackagesWebApp). If the things you have mentioned are handled at (1) and (2), is (3) needed? – takasugi Feb 21 at 17:10
  • 1
    @takasugi without knowing your case in details there are a lot of specialized http server dealing with one or another problem. Examples are Async Http Servers dealing usualy with ajax calls and websocket communication. Appolo server deals with GraphQL or as Jan Dorniak pointed serving static content. – Alexander Petrov Feb 21 at 19:47
2

To add another reason, many application servers are not as good as web servers at serving static files (frontend JS, CSS). At least some of them (I know of Flask and node) explicitly stated in their deployment documentation that you should use a separate dedicated web server software (commonly nginx, or Apache) to serve those in a production environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.