How Nginx Lua Enables Aspect‑Oriented Backend Design with Low Coupling

Aspect‑oriented programming (AOP) separates cross‑cutting concerns from business logic to improve maintainability.

Separating concerns is the core concept of AOP, allowing domain‑specific code to be isolated from the main business flow. – Wikipedia

The example is based on a simplified APP backend with four requirements: encrypted request verification, token‑based login, hierarchical organization (company, group, employee) with future sharding, and permission‑related REST APIs.

Version 1 – Sinatra Implementation

The core concern is a REST‑style resource server, while cross‑cutting concerns include request encryption verification, login verification, and permission management.

All request encryption verification

Login verification

Resource permission management and retrieval

In Sinatra, extensions and a before filter are used to handle request encryption verification as middleware:

Helpers are then used for login verification and retrieving organization information:

Thus the REST code does not need to handle encryption or authentication; after validation and permission checks, it simply maps to database operations and returns the result.

Version 2 – Nginx Lua Orchestration

To achieve low coupling and support multi‑service development, the architecture is split into independent servers. Nginx’s Lua module is used to orchestrate cross‑cutting services.

The Lua module can interact with Redis, Memcached, PostgreSQL, inspect and modify request headers and bodies, and perform asynchronous processing. It can also enforce permissions and proxy requests.

The core Lua code uses proxy_pass and ngx.location.capture to forward the original request (including headers, body, URI, and method) to another service and capture the response:

This code cleans malicious request headers and forwards the request via request_to_server, then validates the returned parameters.

Multiple internal addresses are configured using Nginx stream and proxy_pass:

The workflow is as follows:

When a request arrives, request_to_server forwards it to cross‑cutting services (user authentication, organization service). Each service may return next: true to continue the chain.

If next: true is absent, Nginx returns the current service’s response directly.

If present, the response headers are passed to the next service, which trusts them for further processing.

Three services are defined:

User verification service handling request encryption, login, and password changes.

Organization service managing company structure and user permissions.

Resource service processing the actual REST requests.

Examples:

Invalid password or failed encryption causes the user verification service to return an error without next: true, ending the flow.

A request to send an SMS code is handled solely by the user verification service, again without next: true.

Successful login passes to the organization service, which returns detailed user information via headers.

A resource operation that the user verification service cannot handle is forwarded to the organization service, then to the resource service via proxy_pass.

Advantages of this approach:

Leverages Nginx’s asynchronous processing to compensate for Ruby’s I/O limitations.

Provides a clear, low‑coupling request chain that can be extended by adding appropriate header parameters.

Each module can have its own caching and clustering strategies.

Facilitates isolated testing of individual services without extensive integration effort.

Original article: Using Nginx to Optimize Aspect‑Oriented Architecture (https://github.com/vincenting/note/issues/5)