Fastapi: Comparing django with fastapi ?

Created on 3 Nov 2020  路  3Comments  路  Source: tiangolo/fastapi

Hi,
I have worked in Django and I really loved it but then i got to know it doesn't support asynchronosim natively and i was introduced to FastAPI. Can FastAPI do everything Django does ? like creating web applications (not just API) and what are the technical differences between the two ? I maybe giving a presentation where I wanna include a section of why choose FastAPI over Django or similar old frameworks.

question

All 3 comments

FastAPI is intended for APIs first. For the website portion of a web service, you would be better off with Django and Flask. That isn't to say you can't have Django or Flask make calls to the APIs you build with FastAPI, even run them in the same WSGI/ASGI web server.

However the benefit of using FastAPI for the data access/api calls behind a website is that it can be absurdly simple to write, and fast for end users.

If your question is answered, can you please close the issue? Or clarify what isn't answered?

The answer depends on what are you trying to achieve.

With FastAPI, yes you can do everything that you can do in Django, since FastAPI is a micro-framework, the solution could be different because Django is a high-level web framework and offers so many things out of the box.

But that does not mean you can not do them with FastAPI, in the end, all of these frameworks stand on layer 7 right? So why not?

Yes, you can create web applications, and as your project grows you probably could concern about reliability and scalability, in that point you can considering moving from MVC to Microservices, and FastAPI does it so well.

  • Since this is a micro-framework, you can create applications with minimal effort.
  • OpenAPI and Swagger integration is absolute.
  • FastAPI is faster, a lot.

Here are the benchmarks from TechEmpower

Test Type | Django | FastAPI | Summary
:-----------------------:|:-------------------------:|:-------------------------:|:---------------------------:
JSON Serialization | 72.039 | 170,128 | In this test, each response is a JSON serialization of a freshly-instantiated object that maps the key message to the value Hello, World!
Single Query | 19,264 | 66,185 | In this test, each request is processed by fetching a single row from a simple database table. That row is then serialized as a JSON response.
Multiple Queries | 1,491 | 13,022 | In this test, each request is processed by fetching multiple rows from a simple database table and serializing these rows as a JSON response
Fortunes | 14,699 | 51,981 | In this test, the framework's ORM is used to fetch all rows from a database table containing an unknown number of Unix fortune cookie messages (the table has 12 rows, but the code cannot have foreknowledge of the table's size).
Data Updates | 568 | 5,909 | This test exercises database writes. Each request is processed by fetching multiple rows from a simple database table, converting the rows to in-memory objects, modifying one attribute of each object in memory, updating each associated row in the database individually, and then serializing the list of objects as a JSON response.
Plaintext | 78.132 | 159,381 | In this test, the framework responds with the simplest of responses: a "Hello, World" message rendered as plain text

Was this page helpful?
0 / 5 - 0 ratings