Exploring the reverse proxy mechanism
Running NGINX as an application server is somewhat like the FastCGI architecture described in the previous chapter; we are going to be running NGINX as a frontend server, and for the most part, reverse proxy requests to our backend servers.
In other words, it will be in direct communication with the outside world whereas our backend servers, whether Node.js, Apache, and so on, will only exchange data with NGINX:
Figure 6.1: An example of using Nginx as a proxy server
There are now two web servers running and processing requests.
NGINX, positioned as a frontend server (in other words, as a reverse proxy), receives all the requests coming from the outside world. It filters them, either serving static files directly to the client or forwarding dynamic content requests to our backend server.
Our backend server only communicates with NGINX. It may be hosted on the same computer as the frontend, in which case the listening ports must be edited to leave ports 80 and 443 available to NGINX. Alternatively, you can employ multiple backend servers on different machines and load balance between them.
To communicate and interact with each other, neither process will be using FastCGI. Instead, as the name suggests, NGINX acts as a simple proxy server; it receives HTTP requests from the client (acting as the HTTP server) and forwards them to the backend server (acting as the HTTP client). There is thus no new protocol or software involved. The mechanism is handled by the proxy module of NGINX, as detailed later in this chapter.
