FastAPI and ...

из коробки модные штучки там есть, тоже пробовал его юзать в более менее нормально-структурированном проекте, а оказалось куча проблем, не серьезных но геморойных до предела, хз мб уже решили.

да и документировать свое апи ты будешь так как автор это хочет, а не так как ты, так как ему вообще пох_й

документировать свое апи ты будешь так как автор это хочет

В каком смысле? Там же есть автоматическая автогенерация OpenAPI. Это не «автор это хочет», а практически стандарт. По крайней мере, используется весьма широко.

Бутылка - это https://bottlepy.org/? Если да, то сравнение неуместно, потому что бутылка синхронная. То есть при обработке одного запроса, скажем, параллельно несколько запросов в базу не сделаешь. Веб-сокеты тоже не прикрутишь.

P.s. я ковырял FastAPI, но как-то не зашло. И дело не конкретно в FastAPI, а в самом Python. Разочаровался я в нем - разонравился.

А зачем несколько запросов ? А у каждого юзера в Апаче свой поток.

В рамках выполнения одного http-запроса может потребоваться сделать несколько запросов к СУБД.

Пример: есть эндпоинт получения книги и рекомендаций для нее. Можно сделать sql запросы последовательно (получить из базы книгу, получить рекомендации), а можно взять из пула 2 коннекта и эти запросы выполнить асинхронно (одновременно).

Ок. А можно и на стороне выполняющего запросы сделать 2 асинхронных запроса к нттп.

Можно, но иногда это удобней делать на бэкенде, если sql-запросов нужно несколько сделать, а итоговый объект по смыслу не делится. Либо когда надо сделать несколько запросов на вставку данных. Но у асинхронных фреймворков есть и другие возможности: очереди, периодические задачи, сокеты и т.п. Можно это все делать отдельными приложениями, а иногда можно реализовать прямо в приложении.