3 ms·

A small router for Openresty

36 points by otikik 13y ago

_mikz 13y ago
Would be nice to compare it to www.confreaks.com/videos/782-magrails2011-pattern-matching
- otikik 13y ago
  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.
daurnimator 13y ago
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 13y 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 13y ago
Putting routing logic in Nginx seems like a architecture smell to me.
- otikik 13y 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 13y 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 13y 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.
- otikik 13y 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.

36 points by otikik 13y ago

_mikz 13y ago

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

otikik 13y ago
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.

daurnimator 13y ago

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 13y 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 13y ago

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

otikik 13y 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 13y 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 13y 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.

otikik 13y 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.