Also what I thought … and indeed turns out to be the case in actual usage. It's quite fast to get a usable API up and running with FastAPI, starting from zero to the point of making useful requests to the API and getting back useful data. The actual speed of API access itself (the response times for the requests, etc) has never really been an issue I've wrestled with (me not being Twitter, etc. and not needing zillions of requests per second).

That's my take on it as well. Fast apu does use asyncio which may have speed avantages in some circonstances. But the main takeaway and the killer feature is the fact you build your api just declaring functions signatures.

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

Maybe - in that case I'm judging them wrongly. But flask (the king they dethroned) was faster to get going (with less features, granted) and their docs feature "Performance" [0] rather prominently.

Note that I don't hold this against them. They simply understand what makes the devs pick them and adjusted their market strategy accordingly. It would be nice if they didn't have to though.

[0] https://fastapi.tiangolo.com/#performance

Flask is faster to get going in what way? Writing types instantly saves you a ton of time and effort right out of the gate.[0]

And if your framework is faster, then of course you're going to mention it. Do you really think Flask or Django wouldn't point out that they were fast, if they were? I'm quite sure they would, since it's not shameful to educate the reader on what your framework offers compared to the competition, but they can't, because they're not.

Your link goes to the very bottom of that page, so is it really prominently featured compared to everything else they're trying to sell you on? It really doesn't seem like it. More convincing would be pointing to their list of "key features" at the top, which does mention performance first, but then quickly focuses back on "Fast to code" and "Fewer bugs".

[0]: https://news.ycombinator.com/item?id=33224324

flask took the approach of only providing basic funtionality and relying on 3rd party packages for things like openapi docs and thr like. fastapi has a lot more included and it makes the common tasks like documenting your api easier and more consistent