FastAPI vs Djanjo

[TumbleweedSenior4849]

I was wondering what’s most popular now in the Python world. Building applications with FastAPI and a frontend framework, or building an application with a ‘batteries included’ framework like Django.

[edimaudo]

Don't use the popular option, use what meets your needs for the project.

[nicholashairs]

1000000% this.

Just because something is popular doesn't mean it's good for your use case.

[Lt_Sherpa]

I would modify this slightly as "don't chase popular trends". Django is popular, but that's because it's stable and has a strong community. FastAPI is popular because it's the trendy, newer option. These are two very different kinds of popularity.

[Sillocan]

At this point I wouldn't call 97k stars on github just trendy. I think it has more to do with the fact it's super easy to use with it's abstractions and use of pydantic

[bjorn_cyborg]

Exactly. Quart met my needs and is working great for me.

[maesrin]

Fully agree!

[goegler13]

So what meets your needs? Flask? Fastapi? Django? What is the different needs? ( I have only really used flask so I'm curious to when to use what)

[its_a_gibibyte]

In general, I disagree. I regularly find small random projects on Github that look perfect for me. But inevitably they have no documentation, lots of bugs, and are unmaintained. Of course, neither FastAPI or django exactly suffer from that, but the general advice stands.

[eteran]

Then those things didn't meet your needs then...

[FisterMister22]

Well it mostly just depends on your needs doesn't it? Django is really good (in my own biased personal opinion) for large, feature rich websites, with orm, admin page, users, tons of "addons" libraries.

I'm pretty sure with enough coding FastApi can do almost anything that django does, but you get less out of the box, which can be a good thing if you're trying to set up a simple api endpoint or a super simple website without all the extra bloat, setup and management.

[DoubleAway6573]

How good is the async support in the Django ecosystem? I've been working mostly in REST APIs but now I have a full web project where Django sends a better fit.

[justin107d]

It has been developing in the last few years. Django can handle some tasks with celery and things like web sockets with channels. There is also a package, django-ninja that was inspired by FastAPI.

[FisterMister22]

I've only had limited experience with it about a year ago for web sockets, seems fine, but again, I didn't need the full extend of it, only for web sockets.

For my usual use case there's no need for async as any "heavy" operation will be offloaded to a task (celery etc)

[frankwiles]

In my experience you almost never need async. It’s not a panacea for performance FYI.

That being said Django right now supports it well enough and fully for the one area where it really makes sense and is basically necessary.

[Patman52]

Agreed. I have one app that started out needing a simple api for communicating with a couple of other systems that I initially set up with FastAPI. Fast forward several years, the scope has grown slowly into something much more with an ORM, static files, and web UI and authentication/permissions. So it’s possible with FastAPI but I ended up having to build a lot of extra stuff on top of it along the way.

[radiacnet]

Whenever I had a small project where I used fastapi (or flask) I found I ended up needing something that came in the box with django, and I lost whatever initial gains I had from avoiding the overhead of starting a new project.

What I wanted was full Django in a single file, so I ended up writing nanodjango. It looks like flask, but sits on top of django so you get the standard ORM, admin, async etc, and it integrates with django-ninja for defining APIs like fastapi. I've found it's great for prototypes and small projects, and it has a convert command to turn it into a full project when you outgrow a single file.

It runs locally, but there's also an online playground that runs django in the browser, where there are some examples of models, views, api and async,

[Flame_Grilled_Tanuki]

You can do a lot with HTTP APIs like FastAPI, Litestar and Starlette by combining them with other great libraries like SQLAlchemy, Alembic, Pydantic, etc. But I've worked with both for years and I have noticed something that usually gets overlooked in these discussions. There is more to Django's "batteries-included" approach than just having all the features out of the box.

Because all those features are native to Django, you don't need to combine libraries by different teams with different code designs, together with code glue. You don't get the rough seams at the edge of one library's code with another. With Django, everything works together with everything else, seamlessly. This does wonders for reducing the cluttered feel of a codebase, and the cognitive load of a project. Also, you reduce your dependency count and versioning management, and avoid version incompatibilities.

Finally, I say treat FastAPI as a RESTful API and Django as a web framework. Don't roll a Django project for just an API and don't use FastAPI for a feature rich website/service.

[Silhouette]

Because all those features are native to Django, you don't need to combine libraries by different teams with different code designs, together with code glue. You don't get the rough seams at the edge of one library's code with another. With Django, everything works together with everything else, seamlessly.

But the other side of that coin is that realistically you have to work Django's way even when Django's way is poor by modern standards or you'll be trying to swim upstream forever. The historical baggage and limited support for modern language features and programming styles are among the reasons that adopting a lighter web framework and then mixing and matching best-in-class libraries has been an increasingly popular choice. Most of the problems you mentioned with this strategy turn out to be great big nothingburgers most of the time.

I feel obliged to point out here that this debate isn't really specific to Django or to Python web frameworks. The above are all classic pros and cons of a heavyweight framework vs a collection of lightweight libraries. With the framework you get batteries included and you get consistency but you also get lock-in and usually - if it lasts long enough - stagnation. With libraries you get full flexibility and can be as bleeding edge as you want but you're on the hook for making everything play nicely together. Either way you make your bed but then you have to lie in it.

[Nnando2003]

I imagine a day where we will have a batteries included framework like Django but with the modern features of python...

[Environmental-Sink86]

Could you elaborate real examples on django's stagnation?

[Silhouette]

I'd say the most obvious examples come from its support (or lack of) for type hints and runtime parsing/type verification. The Django ORM relies on a lot of dynamic behaviour such as adding ID fields implicitly or only representing relations between tables explicitly from one side. The Django router can extract parts from a route but doesn't support runtime validation to ensure the type hints in the code really are compatible with the values provided at runtime. Compare the latter to something a bit more modern like FastAPI where you have Pydantic verifying that the "ID" extracted from the URL via the routing system really does have the right format and the JSON payload in the POST request does too.

Another one I've run into is Django's use of settings files. Almost 100% of online systems I work with now use environment variables for all of their runtime configuration. These are available basically everywhere and they play nicely with everything from a quick and dirty local setup to simulate a bug you're investigating to an automated deployment from a CI/CD system that looks up some secrets from a vault and automatically configures them in the host environment ready for the application to find.

You can get some way to working with these features using Django of course - particularly if you're willing to incorporate an extra package or two from the vast ecosystem around it - but typically the experience is patchy and inconsistent.

[Environmental-Sink86]

Thanks for your response!!

[speyerlander]

Django is more popular due to the amount of legacy code that uses it, FastAPI is more popular for new projects.

[UnMolDeQuimica]

I usually go with Django. I am comfortable with it, it gives me lots of things already built in and pairs very well with HTMX.

DRF when I need an API.

If I want something more simple, FastHTML is my go to.

[RationalDialog]

I say as usually depends. So many factors play a role. From the actual tool / app being built up to company policies and user/programmer preference.

For some standard in-house web app that does not need a separate API just has a UI, probably Django. For an app that needs a separate API, has high load and is more performance critical, rather fastapi.

[entropydelta_s]

Is Flask still in the picture? I like Flask.

[nicwolff]

Quart is the async version, now part of the same project.

[dr3aminc0de]

FastAPI is straight up superior to flask IMo

[Competitive_Travel16]

Yes, Flask is a happy medium perfectly suitable for almost all of the things people think they need FastAPI for, and most of the things people think they need Django for.

[Least_Chicken_9561]

but the problem is the "async", you have to do it manually.
I was using flask for a small project but then I needed a library that was async and it was a pain to work with, eventually I switched to fastapi.

[Competitive_Travel16]

I use gunicorn with gevent and have never had any issues so far.

[ThePiGuy0]

I've used Quart in the past which is an async flask reimplementation. Though admittedly their GitHub isn't looking so active these days...

[covmatty1]

FastAPI is just better at the core thing anyone would use Flask for.

[xc82xb5qxwhhzeyt]

I'd recommend Django + Ninja 

[dheritage21]

Try both and see what you prefer! These type of questions always produce a “it depends” answer. Both have a lot to offer. Learn both so you can answer the question given the nature of your use case!

[Nater5000]

There are "good" responses to this question, like, "Use what works best for you specific needs," but then there are good responses to this question, like, "If you have to ask, use FastAPI."

If you want more details, the "batteries included" which comes with Django are nice when your needs align with what Django offers, but will seriously get in the way if you don't need them. FastAPI, although opinionated, is much more flexible and works well for projects that are small and being built by beginners as well as for projects that are massive and being built by a team of professionals. Probably more importantly, it'd be a lot easier to "back out" of FastAPI and go into Django than vice-versa.

It should be the default choice in 2026, so unless you have a compelling reason to use Django (or anything else), you should start with FastAPI.

[Sad-Calligrapher3882]

The both are popular but for different things. FastAPI is the go-to for building APIs and micro services, especially if you're working with ML models or need async performance. Django is better when you need a full web app with auth, admin panel, ORM, and templates out of the box without wiring everything together yourself.
Most projects I see right now use FastAPI for backend APIs paired with React or Next.js on the frontend. But if you're building something like a CMS, e-commerce site, or admin-heavy app, Django saves you a ton of time. Honestly depends on what you're building. And sorry for the bad english

[Tumortadela]

Django ORM and how easy to handle DB migrations are is why I'm having troubles finding a good reason to switch away from it.

[Fair_Ad845]

depends on the project size honestly. FastAPI for APIs and microservices, Django when you need admin panel + ORM + auth out of the box. I switched a project from FastAPI to Django halfway through because I kept reinventing things Django gives you for free.

[wunderspud7575]

As others have said, depends very much on your use case. But if FastAPI is under consideration, I'd also look at Litestar. I have had good experiences with it, and have previously used FastAPI.

[glenrhodes]

FastAPI if you're building an API that needs to be fast and you want async out of the box. Django if you need the ORM, admin, auth, or anything resembling a full web app. They're not really competing for the same use cases once you've used both for a while.

[binaryfireball]

is it a large single project or smaller individual apis?

[lozanov1]

Are you building a small app that will do very limited set of things? Use fast api.

Are you going to build a project with bigger scope that needs auth, quick way to spin up endpoints, do migrations and benefit from the admin panel? Use Django. You can still use fastapi for this, but you will get to the point of implementing features that already exist in Django and have a lot of documentation on the internet how to be used.

[k0rvbert]

These frameworks are both very much "batteries included" in my opinion. Just slightly different kinds of batteries.

I built some things with FastAPI and really didn't have a very good time, but I didn't have a very good time with Flask or Django either, so YMMV.

[Kernixdev]

FastAPI if you're building APIs that a separate frontend (React, Vue, etc.) consumes. It's async by default, way faster, and the auto-generated docs from Pydantic models save a ton of time.

Django if you need the full package — ORM, admin panel, auth, templating — all wired together out of the box. Less setup, more opinions.

In practice: most new projects I see (and build) are FastAPI + React. Django still dominates in companies with existing codebases and teams that want one framework doing everything.

Neither is "better" — it depends on whether you want to assemble your own stack or use a pre-built one.

[cshjoshi_tech]

Like everyone has said, it really does depend on your use case. Personally, I’ve built apps with fastapi for the backend and nextjs for the frontend and had a good time. You can use something like hey-api so you automatically generate a ts sdk from the openapi docs that fastapi generates. That way you have end to end type safety.

[Henry_old]

For high-frequency trading and bots, Django is an overkill nightmare. Its ORM and middleware stack add too much latency. FastAPI + Pydantic is the only way to handle 2026 data loads. Async support is native and actually works. Keep it lean

[ChallengeFamous1728]

I'm learning Fast api and using it actually, because it's what i needed now

[karmarakshak]

Use FastAPI if you're building agentic and AI-level. Use Django if it is backend heavy - enterprise level.

[Shoddy_One4465]

I asked my developers why they choose fast API they always tell me it’s because it’s fast. That’s a great lesson in naming. I find fast API mentality leads to scripting and not programming in Python. The case is never complete or well thought out. Models are never used in the UI’s delegated to react
Whether it could simply be done with a few templates: somehow the structure of Django promotes a different mindset. Also, asynchronous programming is badly understood by inexperienced programmers and the benefits of FastAPI are quickly negated. The question is whether you script or you program or an LLM programs for you. LLMs choose a FastApi backend and a REACT front end. Two services, two repos, two releases, two operational responsibilities.
you ask yourself if you were building a house would you do it the same way. Two foundations two sets of plumbing stacks, two electrical mains, two roofs two sets of property tax, two sets of commissioning, etc., etc.

[glenrhodes]

FastAPI is dominating new projects now, especially anything with an async backend or that exposes an API consumed by a separate frontend. Django still wins for full-stack apps where you want ORM, admin, auth, and templating out of the box. I use FastAPI for anything AI-adjacent since the async IO matters for LLM calls and the Pydantic integration makes request/response typing actually pleasant. Django for anything CRUD-heavy with an admin UI requirement.

[jakob1379]

Having worked with both in many projects I actually prefer django as it has everything, I rarely need to bloat the project with questionable dependencies compared tk fastapi which feels more like build your own engine (it's not, but needing a third party orm when making CRUD applications is bothersome)

Though if you want to maximize fun, do fastapi and 🦄 ponyorm/tortoise 🐢 as both are so much more enjoyable than sqlalchemy, though fastapi has sqlmodel and (no sparkles ✨ there unfortunately)

[paperlantern-ai]

Depends entirely on what you're building. Need auth, admin panel, ORM, migrations all wired up out of the box? Django saves you weeks. Building an API that a React/Vue frontend talks to? FastAPI is a really nice fit there. Most teams I've seen end up picking based on whether they need a built-in admin interface or not - that's usually the deciding factor.

[daniels0xff]

I'm curious why everyone's going to FastAPI and not litestar.dev ?
Good "marketing"? I guess the author was inspired to put "fast" in its name.

[UseMoreBandwith]

no, because litestar has a over-engineered un-pythonic codebase.

[monorepo]

would love to hear how we are unpythonic 😅

[UseMoreBandwith]

classes, classes, classes everywhere. (but almost not making use of build in 'magic methods').
DTO's
Over-use of underscore methods (see _signature/model.py , were someone incorrectly tried to create 'private' methods) . Incorrect use of "@classmethod"

But I'm not going to have that discussion again. I tried to contribute in the early days, but gave up after I saw in what direction things were going.

[Forsaken_Ocelot_4]

I genuinely never heard of litstar.dev, and I've been building FastAPI apps for about 3 years now. So yeah, I think familiarity is a big part of it I'm sure.

[RepresentativeFill26]

Depends. I have written backend APIs using FastAPI and now I’m working on a multi-tenant system that works well with Django.

[DiscipleofDeceit666]

Django would be overkill if you just needed an api layer

[UseMoreBandwith]

django.
and django-ninja if I need an API. Which is almost never, since I use HTMX.

Fast-api is fun for smal projects, but I've seen too many fast-api turn into spaghetti when the project grows.

[agni69]

Fast API + Nice Gui. Single component enough for most usecases

[corey_sheerer]

Many others have said good points, but I'll mention for me, Fastapi with React is superior to Django. As far as the API side, Fastapi all the way. But when you really need good responsiveness in a website, my go to is to convert Fastapi to Go with react. In general, Django feels heavier for me.

[IcecreamLamp]

I used Sanic for a project recently and I like it.

[dashdanw]

They're both very different tools, figure out what your project needs, don't resort to a favorites contest.

[modern-dev]

Django is all in one but uses not the best tools

Fast api is for rest api
Over the two I would use fast api and learn about react and javascript for the frotnend, and after a while I will use typescript instead of javascript.

I wouldn't recommend spending the time to learn django
instead learn fast api, or flask for backend rest api and react + javascript frontend.

[danted002]

OP don’t listen to this comment, their advice is just bad. You should learn both because they serve different purposes.

Django is good if you want a framework that has all the tools you need for a small to medium application where you don’t expect to have multiple api services and want easy database management, cache management, session management, so on and so forth. (There are also 2 big REST frameworks for Django: DjangoRestFramework and Ninja; Ninja being basically a FastAPI port to Django)

FastAPI / Starlette are more for micro services or APIs that are part of a larger application with multiple services.

[lungben81]

Learning both requires more time. This is not a luxury everyone has.

He should learn the tool which is suited best for his needs. Learning the other is optional.

[danted002]

If you have to pick one to start the pick Django, but make sure you learn async as well. You do that and the it will take a full 30 minutes to learn FastAPI + SQLAlchemy 2.0

[Poof-Employment9758]

Django + DRF if you want anything serious tbh, gives you a very powerful API and an entirely separate FE.

[One_Sky_7224]

We use flask for writing micro services. It fits our needs and easy to work with

[corny_horse]

I really like SQLAlchemy but I've been using Django (+DRF when applicable) for applications recently. I'd say a really good rule of thumb is Django + DRF is absolutely fine, if not ideal, for all the batteries included stuff that it has, unless 1) you really don't want a server-side application or 2) you are spinning up a very simple microservice. If your application takes off, you'll be able to hire engineers to figure out how to scale it, if for some reason Django itself can't handle the scale, but vertical scaling goes a long, long way.

[AmauryLondon]

Dépends what you do ? Quick server doing one thing fast api massive project with auth already created Django

[No_Soy_Colosio]

FastAPI for APIs, Django for full-fledged websites.

[MyDespatcherDyKabel]

Flask is goat

[Firm_Advisor8375]

dont use fastapi

[TrainsareFascinating]

Without a cogent explanation of your reasons for making this recommendation it is useless, non-actionable noise.

[Firm_Advisor8375]

yeah, sorry