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.* i

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