Is it really that big of a deal that you can do @app.post("/foo") instead of @app.route("/foo", methods=["POST"])?

That's not what anyone is talking about.

Take this example from their docs:

    @app.get("/items/{item_id}")
    async def read_item(item_id: int, q: Union[str, None] = None):
        return {"item_id": item_id, "q": q}

You are declaring the types of the parameters, and FastAPI parses and enforces them for you. This saves quite a bit of code, and lets you focus on your business logic. Writing the code this way also allows FastAPI to generate a meaningful description of your API, which can be schema (such as Swagger) that tools can use to generate clients, or it can be documentation pages for humans to read. Any good documentation will still require you to write things, but this gets you further, faster than using something like Flask.

This example[0] takes these concepts even further.

Or just glance at the summary and see that it has nothing to do with @app.post.[1]

FastAPI has also properly supported async routes for longer than Flask, from what I understand.

(I've never personally used FastAPI for anything serious, since I have rarely used Python for anything other than machine learning for the past 5+ years, preferring to use Go, Rust, or TypeScript for most things, but I am aware of it, and seeing its claims misrepresented like that is mildly annoying. FastAPI is far more appealing to me than any other Python web framework I've ever seen, and I've only heard good things about it. Based on my experiences in other languages, their approach to writing APIs is absolutely a good one.)

[0]: https://fastapi.tiangolo.com/#example-upgrade

[1]: https://fastapi.tiangolo.com/#recap

It seems we are talking past each other.

Typing is the base for many reasons I love FastAPI, so yes it is useful. And I speak as someone who has used it in production on multiple projects, and even converted some from Flask (but not because of speed).

Far from "fast to get going", starting with FastAPI is slower actually, but it takes you further (as you pointed out). The train of thought that "typing" leads to "fast to get going" which leads to "fast" in the name... Let's say I don't buy it.

The link to "performance" is difficult to miss, I don't think that is a coincidence. And it's OK. If this is what matters to devs that much, they would be stupid not to highlight it. I'm actually happy people are using it, even if for the "wrong" reasons.

Properly supporting async seems like the main reason why it's taken off.

You think no one cares about the convenience of having the type system do a lot of the work for you? Or being able to autogenerate client libraries? I find that position confusing.

Proper async support is decently important to me in any language or framework, but in the real world, I haven't often run into other developers who care much about that.

Async in Python is a huge deal as it is in any language, yes. For very real reasons (cutting down on incredible amounts of confusing boilerplate) to very lame reasons (it's been memed into developer consciousness enough that it becomes a primary yes/no gate for development teams).

I assure you, a large part of using fastapi for my company was the integration with pydantic for easy validation.

It's not that. Fast API comes with a way to declare python types to get for free:

- URL params, forms and query string parsing and validation

- (de)serialization format choice

- dependency injection for complex data retrieval (this one is very underrated and yet is amazing for identification, authentication, session and so on)

- output consistency guarantees

- API doc generation

If the latter requires you to do your own mini router to handle each verb separately, then yes. It greatly improves readability and reduces boilerplate to have the ability to have one handler per path x verb