15 ms·
Show HN: FastAPI: build Python APIs with Go-like speed and automatic UI docs
- tiangolo 8y agoFastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+. It is one of the fastest Python frameworks available, as measured by independent benchmarks. It is based on standard Python type hints. Using them, you get automatic data validation, serialization, and documentation. Including deeply nested JSON documents. And you get editor completion and checks everywhere. Designed around the OpenAPI (Swagger) and JSON Schema standards. It includes 2 alternative interactive API documentation systems that are generated automatically. OAuth2 capable from the start (including JWT). Dependency Injection system, compatible with all databases (relational and NoSQL), Websockets, GraphQL, CORS, etc.
- franey 8y agoIt seems like a lot of the "FastAPI features"[1] are coming not from FastAPI but from Starlette: - Just Modern Python - Editor support - Short - Unlimited "plug-ins" Would it be fair to say that this is Starlette + an API schema + OAuth2 + data validation? [1] https://fastapi.tiangolo.com/features/#fastapi-features https://fastapi.tiangolo.com/features/#fastapi-features
- tiangolo 8y agoYes! Sort of... Most of FastAPI features come from Starlette AND Pydantic. In FastAPI you declare the parameters of your request (including deeply nested JSON bodies) as function parameters. So, "editor support" here means, for example, autocomplete even for deeply nested models. Also, you get automatic data validation and serialization. Automatic detailed errors in your API responses. Also, it has a powerful dependency injection system, that helps in a lot of cases.
- gravypod 8y agoDo you have any examples of a good project layout? How do I have multiple controllers, large numbers of models, etc. There's very little in the way of "just a restful backend" templates in Python.
- tiangolo 8y agoYep, there are a couple of project generators, including Docker integration, Celery, a simple frontend, load balancer with HTTPS etc. In two flavors: * With PostgreSQL and SQLAlchemy: https://github.com/tiangolo/full-stack-fastapi-postgresql https://github.com/tiangolo/full-stack-fastapi-postgresql * With Couchbase: https://github.com/tiangolo/full-stack-fastapi-couchbase https://github.com/tiangolo/full-stack-fastapi-couchbase
- mahesh_rm 8y agoBeen using it, works great.
- tiangolo 8y agoAwesome!
- andres32a 8y agoBest completion I've ever seen and a breath of fresh air. Love it.
- tiangolo 8y ago:D
- darkwinx 8y agoIt's looks great. I've been looking for something like this. I like the documentation. It's very clear.
- tiangolo 8y agoThat's great to hear!
- mlevental 8y agohonest,sincere question: i don't understand why people do this - build these frameworks. it's hundreds of independent labor hours and forgoes the key value prop of python (or whatever language they're reimplementing the wheel in): the existing ecosystem. i would never use this over flask or django because the community around each of those frameworks. that includes plugins, docs, blog posts, SO posts, etc. further more i'm not going to trust that one shop will exist forever and maintain this framework to the same extent that django is maintained. so in effect by adopting this framework i take on the maintenance responsibility. but why would i ever do that? it's not interesting work (very little groundbreaking research left in the http server space i think), it's thankless, and it's just completely unnecessary - every time i submit a PR i'll be looking enviously at django foundation's latest release. so why would anyone write something like this and why would anyone ever adopt? if you're going for speed without ecosystem then just use Go or Java or C# to begin with. is it just NIH syndrome?
- heavenlyblue 8y agoSimply because any sufficiently old Django app has the same intro curve as any other (possibly customised) framework. Have you actually used Flask, by the way? Or the older version of it called Pyramid? The truth with it is that it's not only complex, but also doesn't prefer any of it's optional components. Any project you'll be building in it is going to be custom anyway.
- piquadrat 8y ago> Have you actually used Flask, by the way? Or the older version of it called Pyramid? Flask is in no way related to Pyramid. It came out of an April Fools joke in 2010 (http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/ http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/). Pyramid, OTOH comes out of the Plone/Zope communities (it used to be known as repoze.bfg).
- tiangolo 8y agoYeah, in fact, up to FastAPI, my main stack was based on Flask with several plug-ins, and I created several project generators with all that. FastAPI learned a lot from many of these tools and techniques.
- Thaxll 8y agoWhen you look at what you need in Python to get semi-decent performance: - C library everywhere ( network, serialization ... ) - server that manages process ect ... At some point if you need that kind of things just pickup a language that does it out of the box.
- jniedrauer 8y agoI'd like to see a more streamlined model for generating swagger files/generating APIs from swagger files in Go, but I mostly agree.
- tiangolo 8y agoYeah, the idea is to take inspiration from Go and similar languages, using the new async (coroutine) features in Python that give it better concurrency handling, and the benefits of types. Without having to deal with a lower-level language.
- tiangolo 8y agoMaybe, but Python is still quite easy to pick, the only one that can do Deep Learning and Machine Learning well, etc. So, if we can use it, take advantage of its benefits and have tools like this that simplify everything without too many constraints, I would say it's a good tradeoff.
- m_ke 8y agoYeah for data science and CRUD workloads python is great. The performance difference between go and python in those settings are negligible and python wins out on ease of use and ecosystem.
- tiangolo 8y agoExactly. Totally agree.
- grumpopotamus 8y ago
- m_ke 8y agoYou should also check out starlette and other supporting projects that Tom Christie (of DRF fame) is working on right now. Both FastAPI and Responder are thin wrappers around starlette. Tom Christie has been quietly building what's starting to look like an async first decoupled version of django: - https://github.com/encode/starlette https://github.com/encode/starlette - https://github.com/encode/orm https://github.com/encode/orm - https://github.com/encode/typesystem https://github.com/encode/typesystem - https://github.com/encode/databases https://github.com/encode/databases - https://github.com/encode/apistar https://github.com/encode/apistar - https://github.com/encode/uvicorn https://github.com/encode/uvicorn
- tiangolo 8y agoYep, FastAPI is based on Starlette, heavily inspired by the (now "deprecated") APIStar. What it adds is automatic data validation, serialization, and documentation, with Python type hints. All using Pydantic. So, you declare request parameters and bodies with standard Python type hints (even for deeply nested JSON bodies) and it automatically does all that. It also has a simple but powerful dependency injection system. And thanks to Tom Christie's work, it is compatible with all those tools too (databases, orm, uvicorn, all from Starlette, etc).
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- darrenf 8y agoLooks great; been searching for something to rewrite a 6yo side-project with and this looks just about perfect. Small wrinkle: I spotted a broken link on the "deployment" page - "Bigger applications with multiple files" doesn't link to the right place (in fact it links nowhere, the `href` attribute has no value).
- tiangolo 8y ago> Looks great; been searching [...] That's great! > Small wrinkle [...] Oops, good catch! Thanks. It's fixed now.
- wodenokoto 8y agoFor someone who is a little lost when somebody just says "API" ... Is this like flask but without jinja-templating?
- tiangolo 8y agoIt's designed to be very helpful while building web APIs that communicate JSON over HTTP. You can have semi-automatic data validation, serialization (converting from JSON to Python data types, etc). And an automatic web user interface that documents your API. You don't have to do anything to have that web interface, it's done automatically from your definitions of the data types that you need. It is also compatible with Jinja templates. It's like a modern Flask with several benefits, especially for web APIs.
- rmdashrfstar 8y agoWhy should I use this instead of Falcon?
- tiangolo 8y agoTo use Python type hints, and get automatic data validation, serialization, and documentation for your API (including interactive UI docs for your API). All that, even for deeply nested JSON bodies. And by using type hints, you get autocomplete everywhere, type error checks, etc. Your API gets documented with standards: OpenAPI and JSON Schema. Or to be able to have WebSockets. Or for its dependency injection system, that saves you a lot of code and plugins. You can check the features here: https://fastapi.tiangolo.com/features/ https://fastapi.tiangolo.com/features/ And you can see alternatives and comparisons here: https://fastapi.tiangolo.com/alternatives/ https://fastapi.tiangolo.com/alternatives/
- timothycrosley 8y agoNote that if you are currently using Falcon, another route to get many of these features is to use hug (https://github.com/timothycrosley/hug https://github.com/timothycrosley/hug) which inspired many of API Star features back in the day - and is part of the Falcon ecosystem. But there's also a lot of really amazing work done in this ecosystem that hug doesn't currently support - I may have a busy couple of months ahead :). (DISCLAIMER: I am the creator of hug)
- tiangolo 8y agoYep, and Hug was one of the first tools I saw with this style of declaring parameters with types in the functions, along with APIStar. Great job! And thanks. It helped inspiring the creation of FastAPI. Apart from other of your tools that I use all the time, like isort. An advantage I see of Hug: the same Hug application can be a CLI app. A couple advantages I would see of FastAPI (disclaimer, I'm the creator :) ): * The API schema uses the standards OpenAPI and JSON Schema * It includes a couple of interactive API documentation web user interfaces (Swagger UI, and ReDoc). Thanks to being OpenAPI. * It uses standard Python type hints, not custom types included as part of the library. * The dependency injection system. * Websockets.
- ilovecaching 8y agoAnother way to get Go like speed is to use Go. Go has an excellent built in http web server, and unlike Python it comes standard with a bug reducing type system and an easy and intuitive syntax. In fact, the entire specification of the language can be read in an hour by a novice programmer. Not only that, but Go has best in class editing support in VSCode and Vim, has an official code formatting tool (sorry black), and makes writing concurrent code painless with a syncronous abstraction (sorry asyncio). Also it may have good response times in a vacuum but there’s still the Python memory tax, startup times (which matter when you need to scale horizontally), and scaling of latency to think about.
- tiangolo 8y agoYeah, the advantage here over Go would be to have automatic data validation, serialization, and documentation, all based on standards: OpenAPI and JSON Schema. Including automatic web user interface for API documentation. And maybe the dependency injection system. And Python's ecosystem with lots of packages. And that Python is the best/main way to do Machine Learning/Deep Learning. I personally don't think new asyncio (Python 3.6) is more difficult, but that's more personal taste. Indeed, FastAPI inherited benefits from ideas in Go and other languages and frameworks.
- ilovecaching 8y ago> Yeah, the advantage here over Go would be to have automatic data validation, serialization, and documentation, all based on standards: OpenAPI and JSON Schema. Including automatic web user interface for API documentation. Golang has libraries for all of the things you mentioned, and web tools to generate APIs based on those schemas. There's no advantage here over Go. > And maybe the dependency injection system. Go has interfaces, which facilitates easy DI. No advantage there, and Go sells itself on not having a magic DI framework like the crap Angular 1 had. > And Python's ecosystem with lots of packages. Python's ecosystem may have more packages taken as a whole, but Go has a richer web and infrastructure community thanks to being a web first language and growing out of the DevOps community. > And that Python is the best/main way to do Machine Learning/Deep Learning. Which means nothing. You shouldn't be running ML in your web server. You use grpc or http to make requests to your ML backend, or generate a config for the web server to consume. > I personally don't think new asyncio (Python 3.6) is more difficult, but that's more personal taste. Even if it isn't more difficult, functions have to be colored async which leads to ecosystem fragmentation. It's a huge pita.
- zedpm 8y agoGreat documentation! The extra level of detail like explaining the command for running the server is super helpful for less experienced users.
- andres32a 8y agoI agree, this is what made me fall in love with fastapi.
- tiangolo 8y agoThat's great to hear!
- svenhof 8y agoAlso love the fact that some of the code samples are unit tested to make sure they are functional.
- tiangolo 8y agoNice observation! Yes, most of the tests come directly from the docs, that way, by having full test coverage, means that at least a big part of the functionality is not only tested but also documented somewhere.
- qb 8y agoHow does this compare to https://moltenframework.com/ https://moltenframework.com/? They both provide type hints and are inspired by API Star. Why should I use FastAPI over molten?
- tiangolo 8y agoMolten also helped inspire parts of FastAPI. And they are indeed quite similar in several things. Molten is based on WSGI, FastAPI is based on ASGI. So, you can do async/await stuff in FastAPI. FastAPI inherits directly form Starlette, so it inherits its benefits, like testing tools, GraphQL in-process background tasks, etc. And it benefits from the ASGI ecosystem, for example with plugins to handle Django-Channels like Websockets, deployment to "serverless", even including other tools like Socket-IO. FastAPI is based on Pydantic instead of an internal library for declaring schemas, so any improvements there are inherited here. It supports Flask like route decorators. The dependency injection is simpler, probably more intuitive (but this is more subjective). The same with several other parts. But again, Molten is a great tool, and was one of the tools that inspired FastAPI (it's even mentioned in the docs).
- Splendor 8y agoThis looks awesome. I'll definitely be using this for the next API I build.
- tiangolo 8y agoThat's great!