We started out using lapis in nginx but unfortunately had to abandon it because it basically takes away all the power of using regular location {}. You have to mount your whole app under like location / which is lame for an nginx-native framework.
It's got some nice utilities that we use, but we ended up just using regular location {} routes each with their own content_by_lua code block and none of the lapis routing/handler stuff.
I suppose I haven't really fully considered this use case, but...
There's no requirement to put your entire app in a location / {} block. You can freely use as many location blocks as you want, and those that you want to be rendered by Lapis can call serve to the app as normal.
Keep in mind pattern matching will still happen in the app: You will need to define the routes handled by Lapis within the definition of the Lapis app. Why is it done this way? Primarily, for named routes. Typically you want to be able to generate the URL of a resource within your app's code, so by having routes defined in Lua you can easily reference those. Secondly, easy parameter parsing and the parameter validation.
> It's got some nice utilities that we use, but we ended up just using regular location {} routes each with their own content_by_lua code block and none of the lapis routing/handler stuff.
Although it's very possible to pick and choose what components to use, keep in mind that the `serve` function does some important work with connection pooling. If you are using any query related functionality outside of a dispatch it will open and close connections per request, which is not ideal for performance.
Do you know if you can use lapis to proxy to a backend, essentially getting the benefits of nginx proxy, but perhaps allowing you to layer an authz/authen handler on top using lapis? Thanks for your comment.
Because we want to use rewrites, jumps, named handlers, etc. in nginx too. But you can't do that once you delegate all your routing to Lua. At that point all nginx is doing is a socket event loop.
We weren't happy to lose all the power of nginx just to use a framework.
I would think you would treat the OpenRESTy component as just an executable binary application server just as you would with any other webservice, and put your nginx stuff in front of it, just like you would with any other webserver's front end lb. I agree that it does sound nice to handle it as another component in a regular nginx config, but it doesn't sound like a dealbreaker. Just treat the nginx stuff as incidental to the implementation and it seems like it would be no big deal.
It's got some nice utilities that we use, but we ended up just using regular location {} routes each with their own content_by_lua code block and none of the lapis routing/handler stuff.