Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Idea to provide single file Lua controller (i.e. via init_by_lua_file) #166

nanoant opened this Issue · 4 comments

3 participants


Overall I am very impressed by LuaJIT + Nginx. With mysql-native I am able to get around 13k req/s on my i5 4 core CPU, where NodeJS makes no more than 6k req/s. This is amazing results. Good job!

What we miss IMHO now in lua-nginx and openresty is some clean, user friendly api.

It would be great if we could provide single controller/app Lua file rather than providing separate files for every location or mixing nginx conf with lua, which is bit ugly.

This would make possible to use single file for whole Lua web app just using init_by_lua_file. I propose here two new functions ngx.location and ngx.default_type inspired by Sinatra (Ruby) & Express (NodeJS).

local db = require ""
local cjson = require "cjson"
db:connect{ … }

ngx.default_type 'text/html'

ngx.location('/users', function ()
    local res = db:query('select * from users')
    return template(res)

ngx.default_type 'application/json'

ngx.location('/api/users', function ()
    local res = db:query('select * from users')
    return cjson.encode(res)

ngx.location('/api/user/(\d+)', function (id)
    local res = db:query('select * from users where id='
    return cjson.encode(res)

This will basically create new nginx config location entry with default_type set by last nginx.defaults_type and content_by_lua to the body of the function.

As an extra sugar regex group matches could be passed as parameters, and returned values are output via nginx.



I pondered on this for some time, but then I noticed something:
There is nothing wrong with the Nginx config file. With LuaJIT it divides the logical layer and the resource layer in a way that other servers failed to achieve.

If you go along these lines, you can no longer utilize the many third-party modules which are available for Nginx, like the ones included with OpenResty.

While I think it would be nifty to have a Lua-based configuration file, I think it is an all-in endeavor that would require ripping the core of Nginx apart and a great deal of code which ultimately is unnecessary. We have a tool that works well and very efficiently.

What is the harm in learning one more, small and definitive language?

Still want to do something along these lines? Check out Moochine, an OpenResty-based framework.


Oh, what a coincidence. I had very similar concept, not yet knowing Moonchine.
I made a module app.lua and inside conf/nginx.conf I put a routing like that:

location ~ '^/users'      { default_type application/json; content_by_lua 'require("app").get_users()'; }
location ~ '^/user/(\d+)' { default_type application/json; content_by_lua 'require("app").get_user(ngx.var[1])'; }

Works pretty neat. But it would be possible to reduce it more, if location mapping was exposed as ngx Lua function.


Consider it resolved.

@agentzh agentzh closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.