
Show HN: FastAPI: build Python APIs with Go-like speed and automatic UI docs - tiangolo
https://fastapi.tiangolo.com/
======
tiangolo
FastAPI 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
It 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
Yes! 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.

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

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

~~~
lapnitnelav
Dude, are you a Go bot written to promote Go?

Have you considered that maybe not every one wants have anything to do with
the 8th wonder of the world that is Go?

Take it easy pal, let people enjoy things.

~~~
dr_wolf
It looks like some (extremely dedicated) trolling, don't take it seriously.
There is certainly nothing wrong in expanding the ecosystem of your preferred
language!

~~~
ilovecaching
The way I see it, you're offering no counterpoint and trying to discredit me
with a character attack, which makes you the troll.

------
m_ke
You 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
Yep, 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).

------
darrenf
Looks 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
> Looks great; been searching [...]

That's great!

> Small wrinkle [...]

Oops, good catch! Thanks. It's fixed now.

------
zedpm
Great documentation! The extra level of detail like explaining the command for
running the server is super helpful for less experienced users.

~~~
svenhof
Also love the fact that some of the code samples are unit tested to make sure
they are functional.

~~~
tiangolo
Nice 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
How 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
Molten 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).

~~~
qb
Thank you for the detailed answer!

~~~
tiangolo
:)

------
wodenokoto
For someone who is a little lost when somebody just says "API" ... Is this
like flask but without jinja-templating?

~~~
tiangolo
It'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.

------
darkwinx
It's looks great. I've been looking for something like this. I like the
documentation. It's very clear.

~~~
tiangolo
That's great to hear!

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

~~~
tiangolo
Maybe, 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
Yeah 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
Exactly. Totally agree.

------
Splendor
This looks awesome. I'll definitely be using this for the next API I build.

~~~
tiangolo
That's great!

------
andres32a
Best completion I've ever seen and a breath of fresh air. Love it.

~~~
tiangolo
:D

------
rmdashrfstar
Why should I use this instead of Falcon?

~~~
tiangolo
To 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
Note 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
Yep, 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.

~~~
timothycrosley
Glad to hear that :)!

Honestly, what you've built looks super solid and polished. In many ways, it's
what I _wanted_ hug to be - it's really inspiring to see someone build that.

~~~
tomchristie
Just wanted to second @tiangolo's "Thanks for paving the way with Hug" \-
Absolutely yup! It's a lovely bit of interface design - definitely had a
really positive impact on the space.

------
mahesh_rm
Been using it, works great.

~~~
tiangolo
Awesome!

------
mlevental
honest,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
Simply 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
> 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).

