A small runtime can be a useful architectural choice when the problem is well-bounded. OpenResty combines Nginx with LuaJIT and a set of libraries for request handling, networking, and shared state. It lets a team place application logic close to the network edge without requiring a large framework for every endpoint.
"Zero dependency" should not mean "no dependencies at all." It is better understood as a deliberate limit on abstraction layers: use a small set of components whose behavior the team can inspect, operate, and upgrade.
Start with a narrow boundary
Choose work that fits the request lifecycle: authentication checks, routing, protocol translation, lightweight validation, and carefully bounded orchestration. Keep business rules explicit, and separate them from transport details even when the deployment artifact is compact.
For work that does not fit comfortably in a request handler—long-running jobs, large file transformations, or expensive computation—hand the task to a queue or a service designed for it. A small gateway is most useful when it remains a gateway, not when it slowly becomes an unstructured monolith.
Treat blocking work as a design constraint
Nginx workers are event-driven. A blocking call in a hot path can prevent that worker from servicing other connections while it waits. Use non-blocking libraries where available, set timeouts on every outbound operation, and avoid synchronous work that can grow with user input.
Define an explicit latency budget for each dependency. The application should have a predictable response when an upstream is slow or unavailable: bounded retries, clear error mapping, and a fallback where the product can tolerate one.
Keep the system observable
Small systems still need operational discipline. Emit structured logs with a request or trace identifier, collect request and upstream timing, and expose health checks that distinguish process health from dependency health. Track resource use per worker and watch for queueing, connection saturation, and memory growth.
Load tests should reflect the actual request mix, payload sizes, and upstream behavior. Performance is a property of a particular workload and deployment—not a guarantee implied by the choice of language or server.
When this approach fits
OpenResty is a strong candidate for API gateways, compact integration services, protocol adapters, and predictable high-concurrency I/O. It is a weaker fit when a team depends on a broad ecosystem that is not available in Lua, needs heavy CPU work, or cannot support the operational knowledge required to maintain Nginx and Lua together.
The right measure of simplicity is not lines of code. It is whether a new engineer can understand the request path, failure modes, and deployment responsibilities without carrying hidden framework behavior in their head.
A practical review checklist
- Are request handlers short, bounded, and testable?
- Does every network call have a timeout and a defined failure path?
- Are blocking operations and CPU-heavy work kept off the event loop?
- Can operators correlate logs and timings for a single request?
- Does the team have a clear upgrade and rollback process?