Any working examples of dynamic routing?

[scott2b]

I have a need for custom routes associated with authenticated users. I am going by the dynamic routing docs here

I realize the caveats around complexity of dynamic route registration, but I don't have a better idea about how to handle this use case. I am open to other approaches.

Meantime, I am trying to get dynamic routing working, and am struggling to get something working based on the provided example. Setting aside the need for authentication for a moment, here is what I have that seems to be about as close as I can get to the example in the docs:

@get("/custom")
def custom_handler(request: Request[Any, Any, Any]) -> Any: # The docs state Request[Any, Any] but pretty sure that is wrong
    @get("/vendor1") # I have tried this with: "vendor1", "/vendor1", "/custom/vendor1"
    def vendor1_handler(request: Request) -> Any:
        return {"message": "Hello, vendor 1."}
    request.app.register(vendor1_handler)
    return { "message": "vendor specific routes go here"} # This seems optional. Without it, /custom merely returns null

custom_handler is then explicitly listed in the route handlers for my Litestar app.

Notes of comparison with the documented example:

• The docs state Request[Any, Any]. I think that's just a typo in the docs
• I have annotated these routes to return Any rather than None
• The return from /custom is for my sanity. Without that return dict, the route simply returns null

The issue:
/custom/vendor raises a 404. I have tried variations on this path, which is called the "sub-path" in the docs, but all result in a 404.

Again, I am not bound to the idea of dynamic routes to solve my use case. I am open to any approach that allows me to serve up custom routes to specific users. Ideally, the customization would also be reflected appropriately in the OpenAPI docs as well, but I have not thought that far ahead yet. If there is not a better way to do this, I would appreciate any help in getting this dynamic route registration behavior working. I am also really interested in seeing this work with a class-based controller if that is possible.

[scott2b]

I am realizing that there might be an answer here along the lines of: why not just specify a standard route with a vendor parameter like "/custom/{vendor:str}" or some such? So it might be worth walking through my process on getting here:

1. First, I imagined this being a whole custom application. I tried using is_mount=True to mount a vendor-specific Litestar application on the path /custom. The problem with this approach is that the sessions are not shared across applications, so authentication does not work across the apps. Perhaps there is any easy way to fix this? In which case, I probably don't need dynamic routes. Not sure yet. I think it may still be necessary to do something dynamic in order to only expose a user's own customizations to that user.
2. So, barring the idea of a custom mounted application, I imagined a routing setup where authenticated users see routes that are associated with their identity. The dynamic routing above is just the beginning of exploring that. It is not really clear to me that this will get me where I need to go, which is not really individual custom routes, but whole subsets of custom application-like functionality.
3. I figure in any case, maybe some discussion would at least help to clarify the docs on dynamic routing even if it does not end up solving my use case.

[scott2b]

Ok, I think what I was trying to do was way to complex and probably does not warrant further discussion. I have now completely changed tack. For what it is worth, just in case anyone is curious about implementing user specific customizations, this is the approach I am currently pursuing:

1. There is a primary public facing application on the domain
2. Users who have bespoke functionality will get a subdomain. Not ideal, but this approach seems to simplify the mess.
3. Instead of the primary app including reference to the custom app, it will be the other way around: the user-specific subdomain will run the user-specific application. Routes from the main application will be imported and included in the subdomain app.

There will be some maintenance issues with being sure customers always have an up-to-date version of the main routes, but this is the cleanest approach I can come up with. It gives me the following capabilities:

• There is a general public app that all users have access to, including public facing documentation of the API
• Bespoke users get their own endpoint and do not have to specify different endpoints for primary vs custom routes
• Custom documentation can be locked down to appropriate users by making the documentation of the subdomain app authentication-required.

Still feeling this out. Sorry to clutter up the discussion space. Do what you will with this thread -- I thought I had a particular question, but it turned out really to be the wrong question for my use case.