Architectural Decision: Django vs FastAPI for a Remote-First Project

Context

In remote-first teams, architecture decisions must align with the complexities of distributed engineering cultures. Our recent project required a robust backend capable of handling international compliance, multi-timezone workflows, and rapid feature development. With various options on the table, we focused on two prominent frameworks: Django and FastAPI.

The Problem

We were tasked with building a web application that needed to support multiple regions with distinct legal and compliance requirements, including GDPR and CCPA. Furthermore, the application needed to be scalable, maintainable, and fast enough to handle fluctuating loads. The primary challenge was balancing speed of development with performance and regulatory needs.

Options Considered

1. Django: A mature, full-featured web framework known for its "batteries-included" philosophy and strong community support. It offers a comprehensive ORM, built-in admin interface, and a plethora of third-party packages. However, its synchronous architecture may become a bottleneck in highly concurrent situations.
2. FastAPI: A modern, async-first framework that enables fast development of APIs with automatic OpenAPI documentation. It leverages Python's async capabilities for superior performance under load and can handle many concurrent requests efficiently.

Decision Process

Our team evaluated both frameworks based on the following criteria:

• Performance: FastAPI demonstrated significantly better performance in handling concurrent requests due to its asynchronous nature. Benchmarks indicated that it could handle roughly 300% more requests per second compared to Django under similar conditions.
• Development Speed: Django provides a higher level of abstraction with its built-in features, which can accelerate the initial development phase, especially for CRUD applications. However, FastAPI’s simplicity and use of Python type hints allowed for rapid iteration in API design.
• Compliance and Security: Both frameworks can be made compliant with standard security practices. However, Django's extensive middleware support and built-in security features (like CSRF protection and user authentication) provided immediate advantages for our compliance needs.
• Team Familiarity: Our team had varying levels of experience with the two frameworks. While a subset was very comfortable with Django, others were excited about FastAPI’s modern approach.

Outcome

Ultimately, we chose FastAPI for its performance advantages and its alignment with our team's desire to adopt an async architecture. The decision allowed us to build a responsive application capable of handling high loads while also ensuring compliance with the necessary regulations. We supplemented FastAPI with a lightweight ORM like Tortoise-ORM to facilitate rapid data manipulation while maintaining a non-blocking architecture.

What We’d Do Differently

In hindsight, we could have better addressed the learning curve associated with FastAPI for our team members less familiar with asynchronous programming. Although we conducted workshops and provided resources, a more structured onboarding process could have accelerated our ramp-up. Additionally, integrating a robust monitoring system from the outset would have improved our ability to track performance metrics and quickly address any bottlenecks as they arose.

Conclusion

By prioritizing performance and async capabilities, our team successfully navigated the complexities of building a global, compliant application. The decision to use FastAPI has allowed us to remain agile and responsive to changing business needs, a critical factor in our remote-first environment.

Bottom line

Choosing the right framework in a remote-first setting requires careful consideration of performance, team skills, and project requirements. For future projects, we will prioritize training and monitoring to enhance our development efficiency.