

A small router for Openresty - otikik
https://docs.apitools.com/2014/04/24/a-small-router-for-openresty.html

======
daurnimator
Check out the router prototype I wrote for openresty over at
[https://gist.github.com/daurnimator/3721157](https://gist.github.com/daurnimator/3721157)

Can do all sorts of fun conditions :)

~~~
otikik
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).

------
srean
> Unfortunately, due to some technical reasons, we had to discard [Lapis] and
> roll our own solution on top raw Openresty.

Would appreciate if someone could point out what the problem was. Keen on
trying Lapis myself.

~~~
otikik
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.

------
_mikz
Would be nice to compare it to
www.confreaks.com/videos/782-magrails2011-pattern-matching

~~~
otikik
Hi,

The code referred to in that presentation is the rails router, journey -
[https://github.com/rails/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.

------
mahmoudimus
Putting routing logic in Nginx seems like a architecture smell to me.

~~~
otikik
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.

