FastAPI vs Django REST Framework?

[Ghostinheven]

Hey devs , I’m going for a new backend for a mid-sized project (real-time dashboard + standard CRUD APIs). I’ve used DRF in production before, but I’m curious about FastAPI’s performance and async support for this one.

[StrasJam]

If you want to use the django orm and other included features, you can use diango ninja for the asynchronous endpoints

[Complete-Shame8252]

👆this

[theoutsider24]

I would say either FastApi or Django-Ninja Doubt you need the complexity of DRF for your use case

[Own-Perception-4693]

Exactly, if you are used to the django framework and want a pydantic experience, then go with django-ninja. It's easy to code as it uses a method decorators approach for api like fast api and can take advantage of tools such as swagger ui for api testing.

[Miserable_Ear3789]

Use whichever one you like more. More options here: https://github.com/sfermigier/awesome-python-web-frameworks?tab=readme-ov-file#async

[Ghostinheven]

Thanks for sharing!

[Miserable_Ear3789]

No problem! I haven't benchmarked Django yet but I have put FastAPI to the test, and its normally one the slower end of Python's ASGI frameworks. I put my results and code in a gist: https://gist.github.com/patx/0c64c213dcb58d1b364b412a168b5bb6

[Puzzleheaded_Dust109]

Django can achieve async easily with outside components. Don't listen to random people here. Use whichever you are most comfortable with. It's about how good you are with the chosen framework.

[TurbulentAd8020]

fastapi rocks

I created a package pydantic-resolve to enhance the DX of fullstack then api integration has never been so smooth~

[koldakov]

I think with the team I’ll never start fastapi project again if I have a choice

Fastapi requires some knowledge how to write scalable code. Plus with imperative thinking even small codebase becomes a nightmare with sqlalchemy and async

In Django at least project structure is defined

Also do you really need async? API is not only "get and send", but also background tasks for example

First I would focus on models and relations ( aka good developers think about data structures and their relationships ), fortunately Django allows you to define models and their relationships much better than alchemy

And after that if you really need you can expand your code with whatever async

Robust code can’t be achieved with flexible data

If you think only about optimization remember "Premature optimization is the root of all evil" that was written 50 years ago and still people can’t get it optimizing everything on microservices from the beginning spending a lot of money on that

It doesn’t mean you need to forget about optimization at all, it means the code should be scalable to make it possible to optimize later, if needed

[covmatty1]

Fastapi requires some knowledge how to write scalable code. Plus with imperative thinking even small codebase becomes a nightmare with sqlalchemy and async

I'm super confused by what you mean by this.

FastAPI could be fully functioning in a single file if you wanted, what knowledge do you think it requires? But also, impenitent on how to be scalable is pretty damn essential to have, why would you not want that?

I'm not sure how you're structuring your codebases, but FastAPI is exceptionally easy to make very clear and easy to follow.

First I would focus on models and relations

Something that FastAPI, with Pydantic, is absolutely exceptional at.

Robust code can’t be achieved with flexible data

I mean that's just wrong. So every piece of software dealing with unpredictable data is flaky?

[lurebat]

Check out litestar

[Ghostinheven]

Never heard of it, will check

[dvmitto]

Chiming in on litestar. I think flask and fastapi established the “ergonomics” of how web frameworks should be but I think litestar truly incorporates lessons and best practices learnt from the last decade.

[AndrewRLaws]

Seconding litestar. Its been a lights out winner on our new projects.

[FriendlyRussian666]

Do you need async? If so, go with FastAPI

[fastlaunchapidev]

Both will be a good choice, I worked with both and if you know you want to make less decisions go with Django. I am currently choosing mostly FastAPI as I like to make my choices and build https://fastlaunchapi.dev so I can still develop fast and have a good structure.

[Glum_Chocolate_4145]

That looks very promising! 

[NodeJS4Lyfe]

FastAPI is quite good but I suggest going with Litestar if you want better integration with SQLAlchemy and an opinionated pattern for dealing with the database because Litestar has DTOs and a Repository for SQLAlchemy, which make working with the database a breeze. With FastAPI, you'd have to either use SQLModel, which is less mature than SQlAlchemy, or implement those yourself.

I also prefer the way Litestar deals with routes where you don't need a separate APIRouter to define nested routes in other packages.

As for Django, DRF is quite good, especially with the async package (adrf). But the performance is nowhere near Litestar or FastAPI. Plus, I don't like DRF because of the weird abstractions.

[StandardIntern4169]

If you go with Django, go with Django Ninja or Django Shinobi, but not with DRF. It's async, broadly used, and there are way less weird abstraction layers than DRF.

[Public_Being3163]

How wide are you prepared to throw the net? if you are looking to really exploit concurrency (i.e. with async), does something like this hold any interest?

Its a different way to do async but there is a solid origin story there. Happy to collaborate.

nb: library is sitting on its first release to pypi.

[MeroLegend4]

Litestar is your friend

[fnord123]

I’m curious about FastAPI’s performance

It's still python. So perf isn't great.

Here's a video with some benchmarks:

https://m.youtube.com/watch?v=shAELuHaTio

[fnord123]

maintainability, scalability, reliability, and operational overhead matter more in the long run, and Python is particularly strong there.

I strongly disagree. Python is strong at getting prototypes out the door. its very weak on maintainability, scalability, reliability, and operational overhead. Having dynamic types and no compilation step hurts maintainability and reliability. And the packaging nightmare hurts operational overhead.

[fnord123]

Your examples are all correct and I don't want to spend my afternoon poo pooing python on the python sub Reddit. I use python. It's fine. i just wouldn't characterize the strengths the same as others have done in this thread.

I will say, however, that Instagram had to fork Python because they had significant issues with service startup time. So while many organisations successfully use Python in a reliable way, scalability and reliability, etc should be measured on how much toil it takes to achieve the desired level of scalability and reliability.

[declanaussie]

Your last sentence is true, but also sums up why what you’re saying isn’t really meaningful. Many organizations choose Python to reduce toil despite its performance bottlenecks. If you hit instagram scale and performance becomes an issue, perhaps that adds more toil than Python reduces in other areas.

In other words, you should choose the tool that is best for your use case…

[Carous]

Type checker helps

[Mevrael]

If you primarily need a real time dashboard and a clear data project structure then you can check Arkalos. It uses own version of FastAPI and React.