A small router for Openresty

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

by otikik • 12 years ago

36 9 12 years ago

docs.apitools.com

_mikz• 12 years ago

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

otikik4• 12 years ago

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.

daurnimator• 12 years ago

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

Can do all sorts of fun conditions :)

otikik4• 12 years ago

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

mahmoudimus• 12 years ago

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

otikik4• 12 years ago

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.

lewaldman• 12 years ago

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.

srean• 12 years ago

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.

otikik4• 12 years ago

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.

A small router for Openresty

Related Stories