[QUESTION] Starlette 0.13 declarative support?

Description

In the upcoming release 0.13 of Starlette, a new declarative way for routing is introduced. At first, decorator style will still be supported but @tomchristie will somewhat deprecate it and remove it at some point in the future:

Yes, that’s not going away here. However I do think that I’m going to stop documenting it everywhere.

Would I like to eventually phase it out? Possibly at some point in the future, maybe. One of the key things I’m trying to emphasize in Starlette is a low-complexity stack, and components such as the Starlette and Router classes get really simple if we move away from all the .add_route(...) and @route() futzing.

At the light of this, it seems that FastAPI needs to take a decision about this: either follow Starlette new convention or stick with the decorator style.

Personally, I tend to prefer the decorator style, which is similar to Flask or even Node’s Express. However, as Starlette is one of the core component of FastAPI, I think it’s better if it keeps up with its evolutions, for several reasons:

• Keep the friction between the two frameworks as low as possible. Currently, if you know how to write a Starlette app, you know how to write a FastAPI one.
• At some point, FastAPI will have to implement and maintain some wrapper code to convert imperative routing into the declarative style Starlette expects.

That’s it! Just some quick thoughts in order to keep this subject in mind 🙂

[dmontagu]

@sm-Fifteen

The main problem I can see if FastAPI were to switch to this new model is that decorators clearly show which functions are intended to be routes and which aren’t, which becomes important when you consider how dependency injection and parameters work, since those don’t work with “normal” functions

This is a good point I hadn’t considered.

---

I too thought that adding another decorator for specifying a subset of the endpoint kwargs might make it more natural to follow the new starlette routing convention.

Something like the following:

@endpoint(response_model=User, response_class=UJsonResponse)
def get_user(user_id: str):
    ...

The @endpoint decorator would just store/update a dict on get_user.__fastapi_endpoint_kwargs or similar, and then when an APIRoute is initialized, it would look for that attribute on the endpoint and update the provided keyword arguments.

It would have the benefit of signaling that your goal is to use the function as an endpoint call, clearly indicating that FastAPI’s dependency injection can be expected to be used.

Also, it would simplify the implementation of this CBV pattern for reusing the same dependencies across many routes (admittedly I seem to be the only person who cares about this 😅). It would also make it more natural to implement response_model inference through the use of a custom decorator instead of a router subclass.

[tomchristie]

FWIW I don’t think FastAPI necessarily needs to consider any changes here - it’s fairly reasonable for higher level frameworks to adopt a different approach, while Starlette itself sticks to a as-plain-as-possible style.

(Also I don’t think there’s any changes needed to deal with the 0.12-0.13 update, tho I’m keen to double check that all before I hit go on it)

I am interested in folks thoughts about the style change, tho. It’s an odd trade off, because I’m not sure it necessarily looks nicer, but I think it’s a good thing for the project.

From my POV it’s a good thing for Starlette since it more simply expresses the mechanics, and is easier to override the behaviour (eg subclassing Route makes sense, whereas that’s more awkward to do if there’s a .route decorator on the app instance). Those are particularly valuable qualities for Starlette since it makes it easier to build different high level styles on top of it.