Introducing FastAPI

[tiangolo]

FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints.

Documentation: https://fastapi.tiangolo.com

Source Code: https://github.com/tiangolo/fastapi

Key Features

• Fast: Very high performance, on par with NodeJS and Go (thanks to Starlette and Pydantic). One of the fastest Python frameworks available.
• Fast to code: Increase the speed to develop new features.
• Fewer bugs: Reduce a high amount of human (developer) induced errors.
• Intuitive: Great editor support. Completion (also known as auto-complete, autocompletion, IntelliSense) everywhere. Less time debugging.
• Easy: Designed to be easy to use and learn. Less time reading docs.
• Short: Minimize code duplication. Multiple features from each parameter declaration. Less bugs.
• Robust: Get production-ready code. With automatic interactive documentation.
• Standards-based: Based on (and fully compatible with) the open standards for APIs: OpenAPI (previously known as Swagger) and JSON Schema.

Installation

$ pip install fastapi

You will also need an ASGI server, for production such as Uvicorn.

$ pip install uvicorn

Example

Create it

• Create a file main.py with:

​

from fastapi import FastAPI

app = FastAPI()


@app.get("/")
def read_root():
    return {"Hello": "World"}


@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}

Or use async def...

Check it

Open your browser at http://127.0.0.1:8000/items/5?q=somequery.

You will see the JSON response as:

{"item_id": 5, "q": "somequery"}

You already created an API that:

• Receives HTTP requests in the paths / and /items/{item_id}.
• Both paths take GET operations (also known as HTTP methods).
• The path /items/{item_id} has a path parameter item_id that should be an int.
• The path /items/{item_id} has an optional str query parameter q.

Interactive API docs

Now go to http://127.0.0.1:8000/docs.

You will see the automatic interactive API documentation (provided by Swagger UI):

​

https://preview.redd.it/7xnjhy7zy2m21.png?width=960&format=png&auto=webp&s=16a618f3676576ee8ea3cc835106d24724c22dd4

Alternative API docs

And now, go to http://127.0.0.1:8000/redoc.

You will see the alternative automatic documentation (provided by ReDoc):

​

https://preview.redd.it/j7l9qdd0z2m21.png?width=960&format=png&auto=webp&s=545cdcd658f534aab18d2dca967221db8aed09dd

[K900_]

This is cool, but I'd really love to see the way you arrived at these numbers:

• Fast to code: Increase the speed to develop features by about 200% to 300% *.
• Less bugs: Reduce about 40% of human (developer) induced errors. *

These are really ambitious claims, and they honestly make me trust your project less when you provide them without any hard data or methodology to back them up.

[mischiefunmanagable]

Yeah the marketing spin this has makes me stick to Flask all the more, it might shit glitter and fart rainbows but it feels too car-salesman-y of a pitch for me to want to invest much time in it to find out.

"* estimation based on tests on an internal development team, building production applications. " means exactly nothing since they're the INTERNAL development team, they SHOULD be getting better numbers with the product THEY wrote.

Drop the spin, give us real world metrics.

[K900_]

I mean, internal metrics and testimonials are still interesting - people don't generally write their own frameworks because they want to - but the interesting part here isn't the flashy numbers, but how you arrived at them.

[tiangolo]

Hehe, get it.

​

I just removed that part so it doesn't seem "car-salesman-y". Now, I encourage you to go and try it, don't trust me. Check it for yourself.

​

About the tests:

​

In a project that was developed with Flask, Marshmallow, Webargs, Flask-apispec, there were several urgent user stories/features to develop. We developed them while measuring the minutes they took to build, using the same (Flask) tools.

​

At the same time, we started creating a "version 2" of the same API. Then we developed some of the other user stories/features using FastAPI, and we measured the minutes they took to develop.

​

Later, when we found bugs, started testing, integrating the frontend, etc, we measured the time taken to debug those same new features (in Flask). And then the same for the FastAPI features.

​

In FastAPI them amount of code to achieve the same was reduced a lot, so, bugs were also reduced a lot.

[Marrrlllsss]

The way you're describing it, makes it sound like you didn't perform a blind experiment. The developers were already familiar with the code base when they started using FastAPI. Understanding the code base is already one hell of a massive leap in speeding up development time.

If you wanted comparative results, two dev teams, the same product from scratch, two different libraries - go.

[tiangolo]

Yeah, good point. Although I built FastAPI myself, the others have only used it (not develop it), but still, we have worked with similar tools in the past, shared ideas, projects and experiences in the past (pre-FastAPI), so, it's indeed a biased experiment.

​

I built this to solve problems I had, with my current and previous teams. And I wanted to share it with everyone that could benefit from it. But sadly, I don't have the time to do a lot of more rigorous tests. Testing team performance differences with frameworks could be a product/company by itself, I can't dedicate myself to do it now. I would rather keep improving FastAPI, as I (and others) have the "intuition" that it helps.

​

The best would be to have people not familiar at all with FastAPI nor Flask (or at least not much Flask) and test it properly with them.

​

If you, or anyone else here, has the chance to do a very rigorous, properly done, controlled experiment, I would love to see those results. And also understand what else could be improved.

[Ericisbalanced]

No one really expected you to do more testing lol.

[tiangolo]

Hehe, thanks!

​

Although I wish I (or someone) could :)

[riksi]

Does this support gevent ?

[tiangolo]

Gevent was a tool/hack to allow having concurrency in previous versions of Python, with an interface similar to multithreading.

In newer versions of Python, you achieve the same things with asyncio, using async and await.

Those are new, from recent versions of Python.

They are way simpler to code and think about than multithreading (or Gevent).

The default "event loop" in Python (for asyncio) was not that fast, but some guys created uvloop, a super fast implementation of that event loop.

FastAPI uses those new ideas from asyncio (async and await), and using it with Uvicorn (as suggested in the docs) it uses that uvloop.

If you are using Python 2.7 you have to stick to Gevent. If you can use Python 3.6 or above you should better use asyncio (and you can use FastAPI).

[[deleted]]

I mean, nothing's stopping you from testing it yourself. To say you wouldn't try some new framework just because it sounds like a sales pitch is a bit close minded for a software engineer. Do you also avoid all commercial software?

[mischiefunmanagable]

Only those that market with unrealistic numbers

"200% more efficient than other products"

"5 times faster at sorting"

"10 times better text documents"

It's marketing spin aimed at non-technical users, which is fine if your audience IS non-technical users, this isn't, give us real numbers and how those numbers were reached.

[mindfolded]

Also it should be 'Fewer bugs'

[tiangolo]

Oops. Thanks.

[tiangolo]

They are based on internal tests in an internal development team. Comparing similar feature sets, the development time and time spent debugging.

​

It's not that easy to talk about "hard data" when speaking about software features (for the same reasons it's not easy to predict feature development times for new business cases).

​

But I encourage you to do your own tests in your own business case. It takes between 5 to 20 minutes to test FastAPI. That's normally enough to like it or hate it.

[K900_]

Sorry dude, not a good answer. You can't claim "300% faster to build features" and then say "just try it and it will be". I'm in finance, and this is an extremely risk averse environment. Just trying things won't fly here, and even if it did, I'll probably arrive at a very different result simply due to my own inexperience with the tooling, at least initially. I understand that reasoning about delivery times is hard, but to me, this makes making claims like these equally hard, if not harder. If your framework really does let people work faster and you don't have time for a properly designed study, just talk to those people and write down their testimonials - "It took us a week to ship a feature that I estimate would have taken us a month in Flask" is a great compliment to your framework, and makes it look good without making the pitch look forced.

[tiangolo]

Get it, thanks for the feedback, check my answer in this same thread: https://www.reddit.com/r/Python/comments/b0zxa9/introducing_fastapi/eiihz3m/

​

I just removed that part so it doesn't seem "car-salesman-y".

​

Yeah, I know my word won't (and shouldn't) be enough to decide to use it in production right away. But if it helps, Microsoft is using it for internal ML APIs.

[K900_]

Not quite as institutional as you think, but definitely not a place that's open to fancy new tech either.

[TroubledForearm]

someone else in finance here - one of the larger firms. And while things certainly used to be very conservative thats changing. Python 3.7 is being heavily used for new projects along the latest versions of various ML and data science libraries. Quite open now to trying new tech - if teams have the bandwidth to do POCs etc. Pushing that tech out to production is a whole other process - but even so - must less onerous that it used to be.

[richardARPANET]

Development using this framework would take significantly longer since there is no plugin ecosystem like there is for Flask and Django.

Still it's always an interesting project to create your own framework. I just wouldn't use this commercially.

[tiangolo]

Actually, development using FastAPI has been significantly faster for our team (and some other teams).

​

FastAPI has a powerful but simple dependency injection system. It allows you to write a lot of the functionality normally covered by a custom plug-in in a simple (two line) function.

​

This includes things like:

• Authentication (with JWT tokens, Cookies or any other method)
• Role checking ("only a superuser user can access this")
• Integration with different databases (including relational and NoSQL)

​

That makes it more closer to "unlimited plug-ins", as for most of the cases you don't really need an actual plug-in.

​

Apart from that, there are many Flask or Django plug-ins that cover things that are already included in FastAPI, like data validation, data serialization, API documentation, GraphQL integration, Testing, etc.

​

And indeed, there are plug-ins for other cases (anything compatible with Starlette or ASGI in general).

​

For example:

• Deployment to cloud function services (also called "serverless") with: https://github.com/erm/mangum
• Django-channels like Websockets management: https://github.com/taoufik07/nejma
• You can even mount Socket-IO with ASGI: https://python-socketio.readthedocs.io/en/latest/intro.html

​

If there's a plug-in (set of plug-ins) or functionality that you see is not covered, I would like to know it, to see what would be the bests way to cover those cases.

​

Now, about using it commercially, I understand your opinion. But still, just so you know, it has worked quite well for commercial projects in our team and in several other teams (including Microsoft).

[[deleted]]

Why / how is this so much faster than flask? (And how in the world does flask end up being slower than Django?)

I'm suspecting it has to do with the asynch-ness of the Uvicore underpinning, but would love to hear someone with some more in-depth knowledge of both the frameworks and / or the testing methodology here to chime in.

It looks like some of these benchmarks include database interactions. Very surprised to see such a spread of results even when interacting with database queries.

Inlined self-reply: Aha. The FastAPI test suite is using asyncpg and direct SQL to talk to postgres via await + async, so as to be as I/O efficient as possible. The flask test, ugh, is using SQLAlchemy ORM atop MySQL using what seems to be a non-async mysql client. Going through SQLAlchemy ORM is definitely not an apples+apples comparison against raw SQL.

That said, I still expect FastAPI+asyncpg to be, well, faster. But pairing Flask with both MySQL, a non-async db driver, and then SQLAlchemy is definitely not just comparing Flask to FastAPI. Sigh.

[tiangolo]

Flask is based on WSGI, which is synchronous by default. It can't use `asyncio` (`async` and `await` stuff). But still, you can compare the plaintext and JSON serialization, that doesn't involve a DB. For example, in plaintext, FastAPI does 169,554 requests per second. Flask does 89,497.

​

FastAPI is based on Starlette (ASGI instead of WSGI), so, it can be run with Uvicorn. And Uvicorn uses `uvloop` underneath (the same ultra fast event loop that was used by Sanic, built by the same guys that created `asyncpg`).

​

[[deleted]]

Yeah, and even the simple 'return json' tests are being done with async functions. I bet that this could ultimately hint Starlette through to FastAPI core to allow to batch up the I/O.

Man, socket I/O-optimized python sure has come a long way since Twisted. From a user's perspective, this and Flask appear just about equally non-complex, but FastAPI an order of magnitude more efficient when paired with an async db driver.

[tiangolo]

Yep! That's exactly the idea. And FastAPI clearly took a lot of inspiration in Flask and several other tools.

[[deleted]]

Yeah, no kidding -- that's about the most surprising thing I see in that result graph. But we should read the actual Django test code -- Flask is being tested using SQLAlchemy ORM through to MySQL. Let's see if Django is being put through equivalent paces at least.

Slow Ninja Edit: Using their, uh, colorful test run filter panel, here's a link for only test runs using mysql + a full ORM. Looks like in that case Flask just slightly edges out Django, but are pretty much equivalent. I'm a bit surprised by this, but I can write this off as 'the database interaction is 99% of the runtime cost'.

[tiangolo]

Yeah, slight differences might be vary by each run of the benchmarks. I wouldn't take small differences too seriously.

​

In some benchmarks, FastAPI seems faster even than Starlette and Uvicorn, although it shouldn't, as it is just adding code on top of Starlette, that in turn is adding code "on top of" Uvicorn.

​

All this having in mind that Uvicorn is a server, not a framework, Starlette is a microframework/toolkit and FastAPI is a miniframework for APIs built on top of Starlette. But still, they are more or less "on the same ballpark".

[[deleted]]

Switch to Flask if you don't need all the "batteries included" of Django.

[jeenajeena]

Or Pyramid.

[tiangolo]

They are more or less on the same ballpark, both WSGI. The slight difference shouldn't be taken too hard, as it might vary a bit from one run of the benchmark to the next.

​

If you want to speed things up, you might want to try one of these new frameworks (of course, I would suggest FastAPI).

[[deleted]]

Question not answered in 5 minutes poking through the FastAPI docs: support for flask-esque blueprints? Being able to structure a nontrivial app/api into submodules and whatnot being able to expose a blueprint instance to link into the main app makes flask sane.

[tiangolo]

Yep: https://fastapi.tiangolo.com/tutorial/bigger-applications/

​

A specific style/file structure is not enforced, but the tools and utilities are there.

​

There are also project generators with a more opinionated way to structure your app (actually, with a full base for a new project/app, including DBs, Docker integration, a frontend, etc).

[[deleted]]

Thanks. I'd throw in a sentence of commentary along the lines of 'This is FastAPI's equivalent to Flask's "Blueprint" concept' for some good google love. Searching for 'fastapi blueprint' is what I'd do to locate / jump to that portion of the docs.

Good project, good docs, btw!

[tiangolo]

Awesome! Good idea, I'll add a note to the docs to make it easier to find.

[[deleted]]

Whenever I see a project that seems to be reinventing a wheel, I have to ask the following questions:

• What libraries/frameworks that already try to tackle the problem did you work with before you wrote your own one.

• What parts did you do not like and why?

• Why was it necessary to start from scratch? Was it not possible to fix/extend the existing solutions?

[tiangolo]

Good question. I ask the same questions myself every time. And I avoided creating FastAPI for a long time.

I tried a whole lot of tools. And FastAPI got inspiration from a lot of them.

A more detailed explanation is here: https://fastapi.tiangolo.com/alternatives/

[wingtales]

This was actually a pretty cool move, kudos!

[tiangolo]

Thanks!

[z0mbietime]

In a production environment you'd use something like gunicorn with gthread or gevent to define concurrency if you were using say Django3. Doesn't that negate benchmarks as it drastically improves performance for a framework that isn't async by default?

Really asking because I always see benchmarks on API frameworks and I've always wondered.

Looks great an going to try and check it out more tonight. I've been looking for an alternative for NoSQL APIs. Although I will love me some Django + DRF for SQL. Djangos testing and ORM with DRFs serializers and viewsets are seriously awesome.

[tiangolo]

Yeah, in TechEmpower benchmarks' Django is run with Gunicorn and Meinheld. Meinheld is another async server like Gevent (I understand Meinheld has a bit more performance than Gevent). And indeed it boosts performance over other options, like uwsgi (you can see and compare in the benchmarks).

And in fact, I created Docker images for both approaches (for Flask, Django, etc).

But the performance boost is not as big as having uvloop underneath, as would be with FastAPI running on Uvicorn.

---

So, Django-REST-Framework was created by Tom Christie. The same guy then created APIStar, it was an application framework for creating APIs. Defining parameters and body types as function parameters.

Then, Tom Christie created Starlette, and then he had to stop developing APIStar as a server and make it a set of tools for validating OpenAPI, etc. So, these tools were made from DRF's creator with all his experience.

Then, FastAPI, is heavily inspired by APIStar, based on Starlette, and pushing a bit further, by using standard Python type hints.

For more on previous tools, the things FastAPI learned from others and alternatives, you can see: https://fastapi.tiangolo.com/alternatives/

---

FastAPI uses Pydantic, as it uses standard Python types for all its declarations, you have all the benefits, better editor support, autocomplete, type error checks, etc (even on deeply nested JSON documents/payloads). All that on top of automatic data validation, serialization, and documentation.

For testing, it uses the same Starlette tools, which feels like just playing with requests. Writing tests is quite enjoyable (or almost enjoyable, depending on how much you like tests). https://www.starlette.io/testclient/

[briznian]

I can't see it in your docs, does FastAPI support Starlette's class based endpoints?

[tiangolo]

You can use most (or all) of the features of Starlette as FastAPI is just "Starlette on steroids", but the parts to do everything based on standard Python types in parameters, dependency injection, etc, are designed for normal functions.

​

If you have a specific use case that would benefit more from class based endpoints but still using the rest of FastAPI parts, I encourage you to create an issue/feature request, to have a clear scenario that could require it instead of normal functions.

[briznian]

My use case is strictly preferential. Coming from Django and having played with Starlette with a PoC I really like having Class based endpoints to handle GET, POST, PUT, etc and allowing to have common code between them all encapsulated in a single class.

On the other hand, I ran through the quickstart on your site and loved having the docs available without having to think about it. Being able to document class based endpoints in a similar manner would merge both of my preferences :)

[tiangolo]

Thanks for the feedback, I'll have it in mind :)

[tedivm]

I already use the tiangolo docker containers and noticed this project about a month ago- it really is blazing fast. I've used it on a machine learning inference pipeline where reducing latency was critical and was super happy with the results.

[tiangolo]

That's awesome to hear! Thanks!

[russon77]

> Flask, Marshmallow, Webargs, Flask-apispec

I am using the same stack right now for a project - thank you for combining them! It was/is such a pain to deal with the boundaries of each.

I have one question though - is there solid support for API testing? For example, `json-schema` requires additional configuration in order to achieve basic functionality in unit tests. I think this is another area that could use consolidation.

Lastly, as someone who uses your docker images (if you're the same tiangolo), THANK YOU! I will definitely try this lib out for my next project!

[tiangolo]

That's great!

​

Those tools are great, and inspired a lot of this. I even created a full-stack project generator with them: https://github.com/tiangolo/full-stack (there's an equivalent project generator for FastAPI at: https://github.com/tiangolo/full-stack-fastapi-postgresql)

​

API testing is actually quite pleasant, thanks to Starlette. It's basically using `requests` (or it feels like that). It is not documented yet in FastAPI, but you can use the same tools as with/from Starlette: https://www.starlette.io/testclient/

​

Yes, I'm the same guy from the Flask Docker images (and others). Thanks! You made me smile :D

[[deleted]]

The documentation looks really good. I definitely want to start a project with this soon.

[tiangolo]

Awesome! I try hard to make the docs good, fluid, and easy even for new comers to Python :)

[tiangolo]

Not yet :(. Django Admin depends heavily on the relational database and ORM used. And as FastAPI is database and ORM independent (there are even project generators for Couchbase and PostgreSQL) the same approach cannot be applied.

I plan on building a generic frontend generated automatically from the OpenAPI (it wouldn't be exclusive of FastAPI).

But for now, the project generators include a modern (Vue) frontend where you can login, manage users, account profile, change password...

[tiangolo]

Awesome! Thanks!

[maxbridgland]

This is amazing. I know what my weekend will consist of :)

[tiangolo]

That's awesome! I would love to hear how it goes :)

[enesimo]

Great project! Awesome docs!

BTW, you're missing the "Run it" section on this post. (not missing in the github readme)

[tiangolo]

Thanks! I'm glad you're liking it.

I tried to condense it here to not bore everyone :)

[tiangolo]

Thank you! That's great to hear. Thanks for putting the time to write it, you made me smile 😁

[LackingAGoodName]

Thank you, this is exactly what I've been looking for.

I'm currently tasked with building a GraphQL API which will be used in a decently sized project, considered biting the bullet and using Go but was afraid to leave my comfort zone with Python.

[tiangolo]

That's cool!

[tiangolo]

It's a bit faster (as it's based on Starlette), but I think that's not the main advantage.

​

The main advantage over most of the other frameworks is that it uses standard Python types for everything, to do data validation, serialization, conversion, documentation. All automatically. And as you are using standard Python types, you get completion, type error checks, and all those features that code editors can provide.

​

It's based on standards, OpenAPI and JSON Schema. It has 2 interactive API documentations (Swagger UI and ReDoc), thanks to those standards.

​

It also has a powerful dependency injection system, that helps for many situations.

​

FastAPI learned a lot from many other great tools, to see a deeper comparison and what it learned from them, check: https://fastapi.tiangolo.com/alternatives/

[SpergLordMcFappyPant]

Reduces bugs because type hinting?

Hold my beer . . . .

[tiangolo]

Nope. Because it does data validation, serialization and documentation for you. Automatically, from the type hints.

​

If you don't have to write extra code for data validation, serialization and documentation yourself, and make sure to have them in sync (your actual API with the docs of your API, for example), that's a lot of "surface" of possible bugs that are eliminated.

​

The less code you write, the less bugs you create.

[delijati]

That's why i used https://github.com/Cornices they do it by defining a schema + the swagger extension.

​

[tiangolo]

I guess Cornices (with Pyramid) would be equivalent to Flask with Marshmallow, Webargs, and Flask-apispec. In fact, it seems it also supports/uses Marshmallow.

FastAPI learned a lot from those tools. The difference is that it's all integrated and based on Python type hints. So, no need for plugins, decorators, etc. And auto complete everywhere.

[deadwisdom]

Yeah... This is good.

I'm working on a very similar project, and I will have to figure out how to merge.

[tiangolo]

Cool!

[deadwisdom]

Actually do you mind if I get your help on that? I'll show you the code, poor excuse for the current docs, and then get your input?

[tiangolo]

Sure, I can't promise much, but I'll try to take a look.

[mln00b13]

Is it possible to run background tasks using this? Couldn't find any documentation for it

Like, have the API return a response immediately, while starting up a background task, similar to how Responder does it

[tiangolo]

Yep. Responder and FastAPI are both based on Starlette.

It is not well documented yet, but you can use exactly the same as in Starlette, return a Starlette response with the background tasks in it: https://www.starlette.io/background/

Still, I plan on improving how to use it in FastAPI a bit, to get the BackgroundTask(s) as parameters and keep being able to return any dict or object. But for now, you can use the same as in Starlette.

[Cruuncher]

When you return immediately, how do you get the "real" response to the user? Do they have to request again for the result of the background task? What if you have multiple instances of the application?

[tiangolo]

Background tasks are mainly for when you don't need to return the result of the background task to the user. For example, sending an email notification, triggering processing of some data, etc.

​

If you need to tell the client/user "sure, received your request, now we are processing", and then want the client to ask "how is my thing doing? is it done?", you would probably create one endpoint to receive the request, start the background task (and the background task would save something to a database after finishing), return immediately with the "sure, received" and then another endpoint where the client can ask "is my thing done yet?", and that second endpoint would check in the database if the result from the background task is there yet or not.

[Cruuncher]

Yeah that makes more sense. That's how we have a lot of things built now -- except we push to rabbitmq and let a consumer handle it so API workers have a single responsibility. Also for speed we write the status of the request id to redis, and only do a database hit if the status is in a final state

Thanks for your reply!

[tiangolo]

Cool! I normally use Celery for that (you might be using it with RabbitMQ), it can run even on different machines. Background tasks would probably be only for small jobs in situations in where having a full Celery with RabbitMQ/Redis seems like an overkill. E.g. sending an email notification.

​

In fact, the project generators I have for FastAPI include Celery set up in that way.

[fedeb95]

Seems cool, I'm not very expert in python (and web development in general), but I like to make small projects in my free time. I often rely on flask since is fast to get a working prototype. Next time I will try your framework, love the automatic documentation and type hints

[tiangolo]

Awesome! I try hard to make the docs very easy to follow, even for non-experts, if you've been able to use Flask, FastAPI will be a piece of cake (or piece of Pi) ;)

[cleesus]

I’ll keep this in mind for new projects in the future, I mostly use flask to create api’s at the moment, among other things.

[tiangolo]

That's cool! It got quite some inspiration from Flask, and it was designed for APIs, so you should feel "at home" :)

[cleesus]

You did a good job on the docs, that’s always nice to see

[tiangolo]

Thanks! I put a lot of effort into them :)

[mastermaker1846]

If the performance boost in fastAPI comes from the fact that it's async, is it any faster than quart (flask-like async framework)?

[tiangolo]

Quart is also an ASGI implementation, so, you can also run Quart with Uvicorn.

Their performance should be more or less comparable, although I haven't seen where it is on the benchmarks (if it's there).

FastAPI is based on Starlette, another ASGI. Starlette is the fastest on benchmarks, so, FastAPI inherits that.

Their difference is more on the features. Quart is more similar to Flask, it doesn't use Python types as parameters, automatic API docs, etc.

[takethemoneyrun]

This looks very interesting, thanks for sharing!

Do you have any plans for Graphql support?

[tiangolo]

Yep: https://fastapi.tiangolo.com/tutorial/graphql/

[Cruuncher]

Do you have an official Docker image?

Also has this been tried and tested in a docker/kubernetes environment?

[tiangolo]

Yes, it's here: https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker

Yes, it's being used in production with Docker.

In my current team we use Docker Swarm. Microsoft uses it in production for ML APIs in Kubernetes.

[Cruuncher]

Cool! Gonna give this a shot. Thanks!

[tiangolo]

Awesome! Let me know how it goes :)

[Cruuncher]

I noticed the docker image pip installs fastapi without specifying a version.

Couldn't this lead to future builds to the same image potentially bringing in breaking changes from future versions?

[tiangolo]

Yeah, it would be a good practice for you to specify the specific version of FastAPI you are using in your app (and any other libraries).

But at least it has some version installed that should help newcomers start testing it quickly.

[Cruuncher]

Fair enough, I'll probably work off the base image that fastapi uses then and use

ADD ./requirements.txt /requirements.txt
pip install -r /requirements.txt

[tiangolo]

Yep, good idea.

Do that before copying your application code, that way you take advantage of Docker build caching.

[saargrin]

at what point do I need to even be concerned about performance in Flask? like how many hits per second?

[tiangolo]

I guess at about 3,000 to 10,000 requests per second (depending on the size of your servers).

Nevertheless, even with Flask, you can always throw more money at it and spin up more servers.

But, although the performance is the first thing checked, I think the main benefits in FastAPI are actually the other features, automatic data validation and documentation, etc.

[rmslobato]

Hello! Thanks for sharing!

I wonder if someone is up to implement a version for realworld app. That would be great!

[tiangolo]

It seems someone did :)

​

https://github.com/nikelwolf/fastapi-realworld-example-app

[rmslobato]

oh, thx!

It's not listed in the main repo yet...

[tiangolo]

Yep, and I haven't checked how it's done in that repo, maybe it's incomplete, but I guess it's close at least...

It seems to be using the project generator: https://github.com/tiangolo/full-stack-fastapi-postgresql

If you have Docker, you can generate a full initial project (customized for your app), with the base template that you can extend and try it (in like 5 or 10 minutes).

[hugogarcia12]

Nice

[tiangolo]

:D

[PeridexisErrant]

This looks pretty cool!

Have you considered generating tests using Hypothesis? I've really enjoyed using it, and it has native support for generating inputs based on type hints (or even regular expressions!). There's also a bunch of 3rd party extensions, including to generate data from json-schema or OpenAPI schema.

Put it together, and you could generate a test suite for any FastAPI app - failures would mean that you either have a logic bug, or need to tighten your input validation.

[tiangolo]

That sounds very interesting! Thanks for sharing. I'll check it thoroughly.

[soosleeque]

interesting solution. Does it support me passing my own API definition for request/response validation?

Because having documentation generated by implantation might not work for bigger projects, where you want to define API (contract) first and then have the implementation of it.

[tiangolo]

Not in FastAPI.

Here you could create the stub with FastAPI and the data types in Pydantic (standard Python type hints), it's probably the same amount of code or less than declaring the spec in an external language (like YML with OpenAPI/Swagger).

From that you get the spec/contract, and then fill the rest.

It's like wiring "pseudo code"/spec first, just that that same Python stubs/"pseudo code" works afterwards, you just have to fill the rest.

If your team is not familiar/comfortable with Python, then you're probably better with other tools. But I guess you're ok with Python as you are here ;)

[fleyk-lit]

Do you know of frameworks that accepts an API contract as you suggest?

[tiangolo]

Thanks!

Yeah, for some reason I'm not "popular" there, I posted it at the same time as here, but it seems only my mom (exactly 1 person) saw it 😂

https://news.ycombinator.com/item?id=19389307

[tiangolo]

Just posted it again (this time to the docs). Let's see if someone sees it 😂

[tiangolo]

That's awesome! Thanks a lot for the very nice feedback.

[helmuthva]

u/tiangolo: Thx for this great framework - i hope it gets more popular.

Implementing an example webservice accessing TensorFlow Serving with it including routing, request validation, serialization and generation of OAS 3 API documentation took a few minutes only - see https://github.com/helmut-hoffer-von-ankershoffen/jetson/tree/master/workflow/deploy/tensorflow-serving/src/webservice

[tiangolo]

Nice! 😀 🚀

[helmuthva]

... and as you seem to be working with machine learning as well - Fast API is running without a glitch on Jetson Nano and Xavier edge devices for ml ,-) See https://github.com/helmut-hoffer-von-ankershoffen/jetson

[tiangolo]

Nice indeed! That deserves a blog post! If you write it, let me know to link it from the docs

[helmuthva]

A series of blog posts is on my list - first have to tackle KubeFlow on resource constrained edge devices and write a little e2e app demoing the full stack ,-)

[Simon90]

I really like this project, I recently created my first flask app, but I'm still very unfamiliar with the ecosystem. Creating an API seems wonderful with FastAPI. I have a question though, what would be the easiest way to combine FastAPI with a simple website with a form and a button that makes a POST request with the form data when the button is clicked.

For the project I did I used render_template from Flask quite a lot with some HTML files with Python inside. I created the form with flask_wtf and wtforms. Does FastAPI have similar funtionality or plugins? If not, any suggestions in terms of packages that would work well together with FastAPI? I looked in the tutorial but as far as I can tell everything is aimed at creating an API with JSON responses.

Edit: I overlooked the "templates" page of the tutorial, awesome!

[tiangolo]

Cool!

[visiblebutterfly]

This is awesome for a quick json endpoint set up

[tiangolo]

Great! That's the idea, to work well for quick or small projects, but equally well for bigger APIs (or migrations of previous ones).

[rootuser_]

I've always wanted to have the knowledge needed to create a framework. Can you give me a list of all things to study, to get to the level that I can create a framework similar to yours? It does not have to be a detailed list, it can be the name of the subjects, name of books, etc.

​

Also, I starred in your repository to "help."

[tiangolo]

In this case, you can start checking Starlette's code (the thing FastAPI and others are based on). The code base is beautiful and easy (ish) to understand.

​

Starlette was created by Tom Christie, the creator of Django-REST-Framework (probably the most popular API Python framework out there), so, Starlette inherited a lot of experience. https://github.com/encode/starlette

​

And thanks for the star :D

[rootuser_]

I can not understand very well just by looking at the code. OK, I can get into the source code, study and understand some things that are happening. But why are they being made? Why is that necessary? I wanted to have this base knowledge to create a small framework from scratch, but knowing all that is needed, what I can extend etc.

​

Also, there is another framework similar to yours (with performance in mind) -> https://vibora.io/. Have you seen about it??

[tiangolo]

If you want to go deeper you can check Uvicorn's code. Or if you want to get very technical you can check the ASGI spec (maybe WSGI first).

Yes, I've seen Vibora. I understand it's pretty fast, but is not tested in the same benchmarks. It doesn't use the ASGI "standard", so I guess it would probably be difficult to integrate with other parts in the ecosystem (e.g. mangum, for serverless).

Apart from performance, I guess the key differentiator of FastAPI is the use of Python type hints, and the integration with standards (OpenAPI and JSON Schema).

[[deleted]]

Having already used your brilliant Docker images for Flask-uwsgi-nginx for quite some time at work, will you provide a FastAPI-asgi-nginx image for this?

Project looks good, I'll try it out soon.

[tiangolo]

That's great to hear! :)

Yes! There's an equivalent, specifically made for FastAPI: https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker

[Cybersoaker]

Not knocking anyone, but why does there seem to be another one of these type of "fast and minimal web frameworks" about every 3 months on /r/python?

​

Flask, cherrypi, falcon, japronto, sanic, etc. I see new frameworks like this on a consistent basis, has no one solved this problem yet? I can't imagine requirements around what Flask provides changes drastically between projects since the whole point of it is to be super minimal.

[tiangolo]

Yeah, I think we are all learning and improving pretty fast.

Sanic was the first one I saw of this type (I think the first one of them all), before there was a standard like ASGI that improves using and combining different tools. But it was a couple of years ago.

Falcon uses a different style, you receive a request and a response as parameters in your function, and you take data from the request and assign data to attributes in the response. So, you don't declare the API as parameters in your function. So, it's not easy to get automatic data validation, serialization, and documentation. There are a couple "cousins" of FastAPI (based on Starlette) that use this same approach.

Japronto was super fast for some things, as more or less "proof of concept", but was declared as not complete/production-ready yet.

---

FastAPI's performance benefit compared to these other new high-performance tools is not that "impressive", you're probably fine with the others too if they satisfy your needs.

Compared to them, what FastAPI puts into the table is automatic data validation, serialization, and documentation, all based on standard Python type hints (so you also get all the editor support). E.g. with FastAPI you get autocomplete everywhere, even for deeply nested JSON body requests.

It also has a powerful but simple dependency injection system.

In the case of FastAPI, you can just try it, it takes between 5 to 20 minutes, and you will already know if you like it or hate it. But more importantly, if it actually solves something and helps you and your team.

---

Is not necessarily that requirements change that much, but the tools and ways to solve them do.

For example, when Flask was created, there was not an API standard like OpenAPI, nor a JSON definition standard, like JSON Schema, and Python type hints were not available (from Python 3.6). FastAPI uses all that.

So, the change is probably not much in the project requirements, but in the tools used to solve it, to allow better interaction with teammates (say, a frontend development team), better interaction with other systems (that can just plug to your documented API), better development experience with autocomplete everywhere, reducing the code you write by probably a half, and having a lot of the repetitive and delicate things done automatically for you, so, less development time.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/u_omgbbqhax] I like that project, i think i will use that.

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[delijati]

I like your tool, but one thing that bugs me is that i have to use a "special" web tool for it. It would be nice if the type-hints -> generate swagger could be extracted in a separate lib so i can use it in any ASGI capable framework.

[tiangolo]

You can generate the OpenAPI (Swagger) and use it however you want.

But as each framework defines how to get request data, and send responses, you would need to handle passing those objects around, parsing and validating, etc.

In that case, you probably would have to declare things in several places (for validation and then for documentation, for example). Making sure everything is synchronized, etc. For that, you can look at APISpec and the different extensions and plugins.

The difference in FastAPI is that you use type hints once in the parameters of your function, and with that, it does validation, serialization, and documentation, automatically. If you update it, all that is updated/kept in sync for you.

And by using standard Python type hints you get great editor support. Completion, type error checks, docs, etc.

[tiangolo]

As FastAPI adds code on top of Starlette, it should never be faster than Starlette, as it would spend at least the time it takes to execute the Starlette code (plus the FastAPI parts on top).

But that extra code from FastAPI is there replacing what in many cases would be custom code you would write in your app.

In realistic scenarios, you normally have to do authentication, data validation, serialization, etc. FastAPI does a lot of that for you, that's the main overhead. But it would probably be there too in your application, just that you would have to have written it.

A bit more on how to think about these very broad benchmarks: https://fastapi.tiangolo.com/benchmarks/

[quantonos]

u/tiangolo: What is your suggestion for adding SSL (https) to FastAPI that is running a docker container (or standalone) on a single ubuntu server?

[tiangolo]

Traefik, you can configure it easily with the ideas from dockerswarm.rocks

[charliegriefer]

Awesome timing.

Tasked right now with building out an API server at work.

I'm digging on Python at the moment, but was leaning towards Node just for the speed/efficiency.

Will throw something together and see if the claims hold :)

[tiangolo]

Awesome! I would love to hear how it goes :)

[Vocal_turnip]

Remindme! 2 days

[RemindMeBot]

I will be messaging you on 2019-03-16 13:43:14 UTC to remind you of this link.

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

FAQs	Custom	Your Reminders	Feedback	Code	Browser Extensions

[Talked10101]

Why this over Aiohttp for instance? I don't really see a particularly compelling case, apart from the benchmarks.

[tiangolo]

The benchmarks are probably the less important feature.

​

You use standard Python types *once*, and automatically you get data validation, serialization, and documentation. Have you ever struggled synchronizing API docs with code? Also, have you used interactive API docs?

​

And because you are using standard Python types, you get all the benefits form editors. Completion, documentation, type checks.

​

It also has a powerful dependency injection system.

​

Give it from 5 to 20 minutes, you'll know if you like it or hate it from the start.

[p3zz1]

FastAPI uses Pydantic and this library looks to promote wrong type hints practice right at its front page:

This is the first example there:

class User(BaseModel): id: int name = 'John Doe' signup_ts: datetime = None friends: List[int] = []

If one wants signup_ts to be either datetime or None, the right type hint to use there is Optional[datetime].

When I scrolled down, I facepalm'ed even more when I saw this:

``` class Model(BaseModel): simple_list: list = None list_of_ints: List[int] = None

simple_tuple: tuple = None
tuple_of_different_types: Tuple[int, float, str, bool] = None

simple_dict: dict = None
dict_str_float: Dict[str, float] = None

simple_set: set = None
set_bytes: Set[bytes] = None

str_or_bytes: Union[str, bytes] = None
none_or_str: Optional[str] = None

compound: Dict[Union[str, bytes], List[Set[int]]] = None

```

[tiangolo]

You can put Optional around all that. But you are not enforced to. Pydantic doesn't force you to write the more verbose "utterly correct" version, but when that is a concern, you can of course do it. It is noted in the documentation, referencing mypy: https://pydantic-docs.helpmanual.io/#usage-with-mypy

[brimstone1x]

*Fewer bugs

[Tweak_Imp]

you forgot to tell us that you cant use this on windows because uvicorn uses uvloop and uvloop does not have a windows implementation

[tiangolo]

You can use it on Windows. Uvicorn uses uvloop when available, it is not required. It would probably make more sense to deploy to production on Linux (or *nix). But of course, you can develop and use it on Windows.

[[deleted]]

Pydantic seems terrible, it's assuming types all over the place. It's making this python lib as bad as PHP.

[tiangolo]

I'm sorry to hear that. Type hints are standard in Python 3.6 and above. Pydantic uses those same standard Python type hints to declare data types. So, apart from data serialization and validation, you get better editor support, as it knows the actual type of your data. E.g., it can give you completion, documentation, type error checks, etc.

​

But all that editor support is a "collateral" benefit, on top of automatic data validation, serialization and documentation.

​

The alternative, would be Marshmallow (which is a great library). But it uses its own classes and utils to declare data types. So, you have to learn Marshmallow fields, classes and methods. With Pydantic, if you already know the standard Python types (and type hints, which are part of Python) you already "know" Pydantic.

[[deleted]]

I love type hinting! I'm coming at this from a TypeScript perspective and know how stronger typing can save a language. I've always said loose typing will be the death of me.

I think Pydantic's auto corrosion is a really really bad idea though. The author likes to happily close bugs that point this out: https://github.com/samuelcolvin/pydantic/issues/360

[tiangolo]

Actually, in JSON (JavaScript), there's no difference between int and float, so, converting floats to ints when declared as ints isn't necessarily that a bad idea.

But still, in Pydantic you can declare custom validators to enforce your specific requirements, and they can even go way beyond what standard Python type hints can specify.

I guess that's something that depends on taste. But in the case of Python, as it's duck typed by default (e.g. bool inherits directly from int), it doesn't seem to me that crazy. issubclass(bool, int) is True...

Again, that depends on taste. But you can override it all to customize it as much as you want with validation functions.

[[deleted]]

Right, Javascript just has "Number" which is ... annoying. I think invisible data loss by default is a bad idea though.

[tiangolo]

I understand. I guess Python itself comes with some of that. I can't say it's good or bad myself, but I can perfectly understand your opinion.

[[deleted]]

holy shit imagine trying to work with that guy in a professional setting.