A small router for Openresty

Hi, thanks for sharing.

Here are some comments about your module:

* Your solution is tied to nginx/openresty. We try to limit our dependencies on the ngx.* interfaces as much as we can. That way, if changes happen on the ngx.* api, we have less places to "hunt".

* Your module does more than just the routing. That is not a bad thing on itself, but the routing code is coupled with the rest (that is bad)

* As I mention in the article, using patterns for matching the urls ends up being messy quite quickly. In apitools we need to handle between 50 and 100 different routes. Handling those without some sort of structured strategy would be maddening. We ended up using routes. Getting the correct matching algorithm was tricky.

* Your sinatra module is stateful - the user has to "modify it" (with get and set) in order to use it. We did that before, too. It can cause trouble with nginx's workers and global state. We moved to a stateless solution (the library returns a "new router" and you put the changes there instead).

The main reason was that APItools is not a typical "web application" - it has a web frontend, but its most important part is an "intelligent proxy" - it does things like storing requests, changing them on-the-fly, and sending them to other places. We had to use some of nginx's more arcane tricks to get that part working.

Lapis had some abstractions on top of those parts, and we ended up "fighting" with Lapis more often than we wanted.

There's also the fact that we don't use postresql for persistence (we use redis), so we didn't get the advantage of using Lapis for the "Models" of our app.

Finally, and this is a minor thing, most of the existing doc is for using moonscript, not Lua, which was a bit of a bummer.

If you are planning to build a "conventional" web app on top of openresty, I think Lapis is the best tool out there at the moment.

Hi,

The code referred to in that presentation is the rails router, journey - https://github.com/rails/journey

router.lua is much simpler than that. Journey can parse complex regular expressions like `/(app|application)/(:id)+/foo` while router.lua can only handle parameter interpolations (like `/app/:app_id/foo`). We found out that handling parameters was enough for us.

That said, the strategy we use is pretty similar: we parse the routes and transform them into a tree, which then allows us to match urls faster. It's just that our string parsing and tree construction are much, much simpler than Journey's.

Hi,

It's not nginx. It's Openresty. It's an nginx "distro". One of the main ideas behind it is adding logic on top of nginx (not only routing). This is also how Lapis works.

Could you elaborate a bit?

Actually, use nginx as a router sending traffic to different back-ends/applications based on urls is my main usage.