Request processing pipeline in Arnica NanoProxy

December 15, 2021 by Igor Lozhkin
The Arnica NanoProxy pipeline includes several steps that are important in planning the implementation of an application server, load balancer, service mesh, API router or simply a static file server.

The following diagram describes components of a request processing pipeline for a generic load balancer, in which each node implements an application server, API server or a static file server, .  

nanoproxy_pipeline.png

In this example, there are 3 Arnica NanoProxy instances: one load balancer and two application/API/file servers.

The following are pipeline components involved in request processing. Not all of them are mandatory and engagement of a specific component is controlled by the config file.

HTTP Listener - listens for incoming HTTP/HTTPS traffic on specified IP address, host, port, and initiates request processing

WAF - Web Application Firewall - based on a specified rule, inspects incoming traffic, and blocks requests which do not fit permitted patterns

Redirect Rules - analyzes properties of requests (path, query string, headers, cookies, etc.) and redirects requests to a new destination for specified routes

Rewrite Rules - translates URIs (usually from user-friendly formats) to formats accepted by backend applications

Headers, CSP, and Other Rules - sets response headers, content-security-policy headers and other response components to specified values

Load Balancer - forwards incoming requests for processing to other computing nodes. The forwarding rules match specified patterns to identify proper nodes in specific computing clusters. Also supports a fault-tolerant mode by automatically excluding deactivated nodes and repeating requests against active nodes. As an option, supports sticky-node mode by forwarding requests from the same client to the same node.

Static Content Server - serves static files from internal folders to matched request routes

Web App Router - engages Arnica Platform Applications to process incoming requests (such as WebScript, WebReport, WebPortal, etc.) for specified routes

API Router - engages custom APIs to process incoming requests for specified routes