[m_ke]

Learning curve is super low. Main benefits are:

1. Performance, it's a wrapper on top of starlette/uvicorn, which brings the performance closer to nodejs (https://www.techempower.com/benchmarks/#section=data-r17&hw=...). (I did run into some issues with it though due to the default response validation when serializing large response bodies)

2. Lightweight background tasks (from starlette)

3. Documentation generation from type annotations.

It's a nice tool for microservices but coming from django you'll have to roll your own database management, authentication, sessions, caching, admin and etc. I'm also not a fan of the magic request unpacking using type annotations and prefer getting a request object as is done in django and starlette. IMHO most people would probably be better off with plain starlette and a 3 line decorator to handle request validation and response serialization.

[bransonf]

It looks pretty similar to flask as far as syntax goes.

Why do you think plain starlette is better? Are the type annotations annoying to debug?

[m_ke]

I had a few endpoints that had to handle url parameters, query parameters, http headers and bodies which could either be json, form data or files, handling all of those options using type annotated parameters ended up being pretty messy and I ended up just using the starlette request object.

I was trying it out for a machine learning service that had to send back large dense vectors and I hit some other performance issues (like https://github.com/tiangolo/fastapi/issues/360#issuecomment-...), due to the coupling of validation with serialization.