As a long-time Django developer, I've observed FastAPI's rising popularity within the Python community, and for good reasons. FastAPI boasts ease of use, performance, clean syntax, Python type hints integration through Pydantic, native async support, and lots of other features that might make Django enthusiasts envious.
Yet, I've chosen not to dive deeper into FastAPI, opting to stick with Django instead. Here are my ten personal reasons:
1. Boring Tech Over Fancy Tech
While I acknowledge FastAPI's compelling features, I've come to value solidity above all. Django is the king of stability, with minimal breaking changes and regressions over the years. Each update undergoes rigorous testing, and the framework has few external dependencies, thereby avoiding significant pitfalls.
Django has stood the test of time. It's dependable technology that simply works.
2. Abundance of Resources
After 18 years, Django has amassed a wealth of resources, many of which remain relevant (especially for backend development) and well-maintained. Answers on Stack Overflow are valid years later, and ChatGPT consistently provides relevant advice based on extensive content.
When I encounter a unique issue, there's likely a package available to address it, or at least a blog post detailing a solution.
3. Flexibility for Full-Stack or Backend
Using Django purely as a backend framework is entirely feasible, despite its full-stack capabilities. It's possible to do more with less. Admittedly, learning Django from scratch with a focus only on backend development can be challenging due to the scarcity of targeted courses.
However, even for single-page applications, having the option to create basic frontends with Django can be advantageous for simple, non-client-facing CRUD applications without the need for dynamic behaviors.
4. ORM Preferences
Having spent years with Django's ORM, switching to SQLAlchemy or any other ORM feels unnatural. This isn't a critique of SQLAlchemy's quality but rather an acknowledgment of the difficulty in adapting to a different system.
While FastAPI offers ORM alternatives, experience has taught me that opting for less common solutions incurs its own set of challenges, including reduced documentation and support.
5. Limited Usefulness of Async Features
Despite FastAPI's advantage of native ASGI server support, I've questioned the necessity of async features in Django, even with the option to use Django-channels. Having worked with JavaScript's promises and async/await, I've realized that such features complicate matters more often than not, as the majority of tasks don't require them. For truly asynchronous tasks, tools like Celery suffice, and for websockets, solutions like Soketi server server or Pusher are available.
6. Misleading "Less Boilerplate" Claims
This critique isn't directed at FastAPI but at frameworks that oversimplify their introduction with "hello world" examples. The ease of starting a project doesn't equate to its manageability or scalability over time.
Django's initial setup might seem complex, but its structure and conventions guide developers as projects expand, making the initial overhead worthwhile.
7. The Value of Conventions
Django's conventions offer a roadmap for avoiding common pitfalls and understanding optimal architectural practices. While sometimes restrictive, these conventions facilitate easier collaboration and decision-making among developers. Framework builders are smarter than me, and 99% of the time, what they enforce will help me avoiding pitfalls, and will teach me what a good architecture looks like in the same time.
8. Performance Isn't Everything
Although Django may not be the most performant framework, especially when compared to FastAPI, I've observed that development skills significantly impact performance issues more than the inherent capabilities of the technology used. Furthermore, not every project requires extreme performance levels, and for those that do, Python might not be the first choice.
9. Concerns Over Project Sustainability
The dependency on a single main maintainer for project sustainability is concerning. The potential abrupt cessation of their involvement poses a risk, despite my own use of Vue.js, which similarly relies on a key individual.
10. Considering TypeScript Frameworks
As a full-stack developer familiar with TypeScript and Vue, I find the prospect of using a full-stack TypeScript framework like AdonisJS, coupled with ORMs like Prisma, more appealing for projects with straightforward backend needs. This approach simplifies project management with a unified language across both front and backend.
Choosing where to invest one's time in learning new technologies is a personal decision, shaped by individual preferences, project requirements, and long-term goals.