|
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. |