Can you not add middleware to an existing litestar.Litestar instance?

[bunny-therapist]

I had a litestar.Litestar instance with middleware passed to the init, and it worked fine. Then I tried to instead first instantiate, then modify the middleware attribute - specifically, I appended middleware to it (it is a list). There was not error raised by this, but when I ran the tests, it appears that none of the middlewares I appended had any effect. It is if there is no middleware at all.

I knew you could register route handlers after instantiation with the register method, so when I saw that the middleware was exposed as a mutable, settable, public attribute, I assumed that I could modify that as well, but that appears to have been wrong.

Is this behavior intentional? I would expect either for the middleware to work, or that it was simply impossible to modify the attribute. Now it just seems like a bit of "gotcha".

[guacs]

You are right that you cannot add middleware to an existing Litestar instance. The resolution of the middleware and the creation of the middleware stack for each route handler is done when instantiating the instance itself. The reason for this is that servers like uvicorn will only instantiate the instance by calling the factory or just assume the instance is already done any preprocessing it needs to do. So this will work properly:

# imports

app = Litestar([..])

As for why the attribute can be modified, it's because Litestar is a subclass of Router which doesn't have immutable values. I don't know if there is a specific reason why that's kept as mutable, but @provinzkraut had talked about making all the route handlers immutable, amongst some other changes, for v3.

Maybe we could allow users to modify the Litestar instance and then have an API to create the routing trie (which is when the middleware stack is created) from scratch. Like resolve all the routes again etc so that any changes made take effect. I could see this being useful for implementing something like the builder pattern to build the Litestar instance.

[bunny-therapist]

Mostly what I want is some kind of cohesion. Right now, the register method as well as the publicly mutable attributes like response_headers and middleware imply that a builder pattern can be used, but only some of them work. I am not sure if I missed some documentation or not, but regardless, the structure of the code itself makes it seem as if this is possible.

If we had a recreate method as you suggest, at least anything would be possible (I guess). But it would have to be very well documented. I do kind of worry that the recreate method's docstring will end up something like "if you modify the app after instantiation, all bets are off unless you call recreate at the end". If it is just middleware that is the issue (I did not check - what about things like e.g. before_request?) then I guess one could say "if you add middleware after instantiation, you should call this".

Are there any plans for any of this? I feel like this is a more general feature of "support builder pattern".

[guacs]

For now, could you just take in a dictionary of the kwargs or something along those lines and then instantiate the Litestar instance in the end?

Sorry, I'm not exactly sure how you mean. You mean to instantiate inside a function that takes kwargs, or to modify kwargs via a function...?

Sorry! I had missed this in my notifications.

I was thinking of:

def add_middlewares(kwargs: dict):
    kwargs["middlewares"].append(middleware)

Then a final:

def create_app():

    kwargs = {}
    add_middlewares(kwargs)

    return Litestar(**kwargs)

[guacs]

I like the idea of a builder pattern as well. Feel free to create an issue :)

[bunny-therapist]

#3257