Strongly disagree that use of FastAPI over Starlette is down to marketing.
I regularly use FastAPI instead of Starlette on small work projects and personal projects. The first thing I did when pointed at FastAPI was follow their very prominent links to the Starlette project. A cursory read of the Starlette docs shows that it’s not the same thing at all and not a viable alternative. I’d use other tools (in Python or other languages) before Starlette for my use case.
The way routing works, the Pydantic validation, and the auto-generated docs all mean that I can spin up a simple service, often in a single ~100 line or less Python file, shove it on a server behind Caddy for HTTPS, and literally have a usable, reasonably performant and self documenting API. Often in less than an hour.
Starlette simply does not do this for me. I hate boilerplate, hate template projects/repos, hate personally doing “devops”, managing configs, etc., and generally dislike anything that gets in the way of connecting an idea to the internet. Enterprise ready? Not in that form (though I’m sure FastAPI _can_ be), but useful: hell yes.
FastAPI requires nothing that doesn’t have a purpose, even in throwaway or prototype projects, is pretty quick, and works the way I think. In my eyes the project has added a HUGE amount of value to Starlette for some users and embodies the point of open source, which is about creating and sharing and improving upon useful code (preferably with attribution, which Starlette gets prominently in the FastAPI repo and docs), not recognition or building a “brand” or user base for yourself or your project. It’s not a marketplace.
This seems unnecessarily antagonistic - maybe you’re haven’t fully explored what it offers. FastApi is very transparent that it is a layer built on top of Starlette https://fastapi.tiangolo.com/features/#starlette-features. It also layers in several other features at really useful abstraction levels by bringing in Pydantic, and I think the dependency injection system and OpenApi integration was mostly built by Sebastian.
It’s got fantastic documentation and tutorials. For a small dev or full stack team, and especially someone just starting out, it feels unparalleled in what it gives you out of the box.
Not sure what else they could say, when 95% of FastAPI features come directly from Starlette. Again, the code on github speak for itself.
As for the remaining 5%, that's basically pydantic and the swagger / openAPI stuff: questionably useful and very easily reimplemented if need be.
The way I see it, FastAPI stole much of the recognition Starlette deserved. I find it a bit sad. Starlette is where all the async magic happens.
Although I don't think ripoff is a good word for describing their relation, I definitely think Starlette deserves more attention. As I prefer CBV I tend to lean towards Starlette.
I used starlette and switched to fastapi. For a one person project the bonus free swagger docs in fastapi were what got my attention. If that's also built in to starlette... I guess then the marketing worked on me.
I regularly use FastAPI instead of Starlette on small work projects and personal projects. The first thing I did when pointed at FastAPI was follow their very prominent links to the Starlette project. A cursory read of the Starlette docs shows that it’s not the same thing at all and not a viable alternative. I’d use other tools (in Python or other languages) before Starlette for my use case.
The way routing works, the Pydantic validation, and the auto-generated docs all mean that I can spin up a simple service, often in a single ~100 line or less Python file, shove it on a server behind Caddy for HTTPS, and literally have a usable, reasonably performant and self documenting API. Often in less than an hour.
Starlette simply does not do this for me. I hate boilerplate, hate template projects/repos, hate personally doing “devops”, managing configs, etc., and generally dislike anything that gets in the way of connecting an idea to the internet. Enterprise ready? Not in that form (though I’m sure FastAPI _can_ be), but useful: hell yes.
FastAPI requires nothing that doesn’t have a purpose, even in throwaway or prototype projects, is pretty quick, and works the way I think. In my eyes the project has added a HUGE amount of value to Starlette for some users and embodies the point of open source, which is about creating and sharing and improving upon useful code (preferably with attribution, which Starlette gets prominently in the FastAPI repo and docs), not recognition or building a “brand” or user base for yourself or your project. It’s not a marketplace.