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.
eg.
location = /exact-match { content_by_lua 'require("lapis").serve("app")'; }
location /directory-match { content_by_lua 'require("lapis").serve("app")'; }
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.
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.
eg.
location = /exact-match { content_by_lua 'require("lapis").serve("app")'; }
location /directory-match { content_by_lua 'require("lapis").serve("app")'; }
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.