Theo Khảo sát các lập trình viên Python JetBrains năm 2020, Django và Flask là hai framework web Python phổ biến nhất cho đến thời điểm hiện tại. Không có gì ngạc nhiên khi Flask đã vượt qua Django để chiếm vị trí hàng đầu vì ngành phát triển web đang có xu hướng hướng tới các khuôn khổ nhỏ hơn, dịch vụ vi mô và nền tảng "không máy chủ" trong 5 năm qua.
Cũng có khả năng việc Flask được dùng nhiều hơn so với Django ít liên quan đến xu hướng của ngành mà liên quan nhiều hơn đến người dùng JetBrains?
Django và Flask đã trở nên phổ biến, được hỗ trợ rộng khắp và có các cộng đồng đông đảo người dùng đồng thời Django và Flask cung cấp các phương pháp tiếp cận hiệu quả để phát triển ứng dụng, cho phép bạn tập trung thời gian và năng lượng vào các phần độc đáo của ứng dụng thay vì sinh code tự động (core scaffolding). Cả hai framework này đều được sử dụng để phát triển các ứng dụng web nhưng sự khác biệt chính nằm ở cách chúng đạt được mục tiêu. Nếu Django như một chiếc xe hơi thì Flask như một chiếc xe đạp. Cả hai đều có thể đưa bạn đi từ điểm A đến điểm B, nhưng cách tiếp cận của chúng khá khác nhau. Mỗi loại xe đều có ưu điểm và ứng dụng của riêng nó. Tương tự với Django và Flask cũng vậy.
Trong bài viết này, chúng ta sẽ xem xét các trường hợp nào nên sử dụng Django và Flask để đạt hiệu quả tốt nhất cùng với những điều đã làm cho chúng trở nên độc đáo, từ quan điểm mang tính chất giáo dục và phát triển.
> Tham khảo: LỘ TRÌNH HỌC LẬP TRÌNH WEB chung cho người mới học.
Triết học
Django và Flask đều là các framework web miễn phí, mã nguồn mở, được thiết kế dựa trên Python để xây dựng các ứng dụng web.
Khi so sánh với Flask, Django đề cao sự ổn định cũng như cách tiếp cận "bao gồm pin" , trong đó một số loại pin (tức là các công cụ, mẫu, tính năng và chức năng) được cung cấp ngay lập tức. Về độ ổn định, Django nhìn chung có chu kỳ phát hành dài hơn, cứng cáp hơn. Vì vậy, các bản phát hành Django đi kèm với ít tính năng mới mẻ hơn nhưng có khả năng tương thích ngược mạnh mẽ hơn.
Theo Werkzeug, Flask xử lý tốt trình sinh code tự động cốt lõi (core scaffolding). Ngoài ra, bạn nhận được định tuyến URL, xử lý yêu cầu và lỗi, tạo khuôn mẫu, cookie, hỗ trợ kiểm tra đơn vị, trình gỡ lỗi và máy chủ phát triển. Vì hầu hết các ứng dụng web cần nhiều hơn một chút (như ORM, xác thực và ủy quyền, để đặt tên cho một số ứng dụng), bạn có thể quyết định cách bạn muốn xây dựng ứng dụng của mình. Cho dù bạn tận dụng các tiện ích mở rộng của bên thứ ba hay tự mình tùy chỉnh mã, thì Flask vẫn tránh được việc này. Nó linh hoạt hơn nhiều so với Django. Ngoài ra còn có ít diện tích bề mặt hơn để tấn công và ít mã hơn để xem lại nếu bạn cần bẻ khóa mở mui và xem mã nguồn.
Tôi rất khuyến khích bạn đọc và xem lại mã nguồn của Flask. Sạch sẽ, rõ ràng và ngắn gọn - đó là một ví dụ tuyệt vời về mã Python có cấu trúc tốt.
Các tính năng
Tiếp theo, hãy so sánh Flask và Django dựa trên các tính năng đi kèm với core framework.
Cơ sở dữ liệu
Django bao gồm ORM (Cơ chế lập trình ánh xạ CSDL sang các đối tượng) đơn giản nhưng mạnh mẽ hỗ trợ một số cơ sở dữ liệu quan hệ khác với bình thường như: SQLite, PostgreSQL, MySQL, MariaDB và Oracle. ORM hỗ trợ để tạo và quản lý việc di chuyển cơ sở dữ liệu. Cũng khá dễ dàng để tạo các biểu mẫu, dạng xem và mẫu dựa trên các mô hình dữ liệu, điều này hoàn hảo cho ứng dụng web CRUD điển hình của bạn. Mặc dù nó có một số thiếu sót, nhưng nó đủ tốt cho phần lớn các ứng dụng web.
Flask không đưa ra giả định nào về cách lưu trữ dữ liệu, nhưng có rất nhiều thư viện và tiện ích mở rộng có sẵn để trợ giúp việc đó:
Tóm lại, nếu bạn đang sử dụng cơ sở dữ liệu quan hệ, với Django, bạn sẽ bạn đầu dễ dàng hơn nhiều vì nó tích hợp sẵn ORM và công cụ quản lý di chuyển. Tuy nhiên, nếu bạn đang sử dụng cơ sở dữ liệu không quan hệ hoặc muốn sử dụng ORM khác như SQLAlchemy, từng bước bạn làm sẽ khó khăn hơn với Django. Thêm vào đó, rất có thể bạn sẽ không thể tận dụng quyền quản trị Django, biểu mẫu mô hình hoặc trình tuần tự mô hình DRF.
Flask nằm ngoài khuôn khổ bạn có, cho phép bạn tự do lựa chọn ORM (hoặc ODM) phù hợp nhất với ứng dụng của bạn. Tuy nhiên, tự do đi kèm với cái giá phải trả: bạn phải lĩnh hội ở mức cao hơn và gặp nhiều chỗ cho sai sót hơn vì bạn đang tự quản lý những phần này.
Bạn càng làm thủ công nhiều bước thì càng mắc nhiều sai lầm, đặc biệt là khi mọi thứ ngày càng mở rộng.
Xác thực
Vì hầu hết các ứng dụng web yêu cầu xác thực (bạn là ai?) và ủy quyền (bạn được phép làm gì?) nên Django cung cấp chức năng này cùng với quản lý tài khoản và hỗ trợ cho các phiên làm việc ngay lập tức (thông qua mô hình Người dùng). Flask hỗ trợ cho các phiên làm việc dựa trên cookie, nhưng bạn sẽ phải chuyển sang mạng mở rộng để quản lý tài khoản, xác thực và ủy quyền.
Quản trị chức năng
Django đi kèm với một bảng quản trị chức năng, nó là một ứng dụng web cung cấp giao diện người dùng để quản lý dữ liệu dựa trên các mô hình của bạn. Đây là một lĩnh vực khác mà Django chiếm ưu thế vượt trội. Nó cho phép bạn nhanh chóng thực hiện các thao tác CRUD đối với các mô hình trong khi bạn xây dựng một ứng dụng mà không cần viết thêm bất kỳ mã nào. Tuy nhiên, Flask không có những chức năng như vậy, nhưng tiện ích mở rộng Flask-Admin cung cấp tất cả các chức năng tương tự và nhiều hơn thế nữa:
Django làm mọi thứ tự động
Triết lý của Flask hơi khác một chút - rõ ràng tốt hơn là ngầm hiểu. Nếu một cái gì đó cần được khởi tạo, nó phải được khởi tạo bởi lập trình viên.
Flask-Admin tuân theo quy ước này. Với tư cách là một lập trình viên, bạn có thể chọn những gì nên được hiển thị và cách thức hoạt động dựa vào Flask admin.
Đôi khi điều này sẽ yêu cầu bạn viết một ít mã lặp lại (boilerplate code), nhưng nó sẽ mang lại hiệu quả trong tương lai, đặc biệt nếu bạn phải triển khai một số logic tùy chỉnh.
Flask-Admin hỗ trợ một số phần mềm phụ trợ cơ sở dữ liệu (database backends) như SQLAlchemy, Peewee, MongoEngine. Bạn cũng có thể thêm backend của riêng mình. Nó cũng có thể được sử dụng với (hoặc không cần) các tiện ích mở rộng xác thực Flask phổ biến:
Định tuyến và Chế độ xem
Cả hai framework đều cho phép bạn ánh xạ URL tới các chế độ xem và hỗ trợ các chế độ xem chức năng và cơ bản.
Django
Khi một yêu cầu khớp với một mẫu URL, đối tượng yêu cầu, chứa thông tin yêu cầu HTTP, được chuyển đến một chế độ xem và sau đó chế độ xem đó được gọi hiển thị. Bất cứ khi nào bạn cần quyền truy cập vào đối tượng yêu cầu, bạn phải chuyển nó một cách rõ ràng.
URL và chế độ xem được xác định trong các tệp riêng biệt - urls.py và views.py, tương ứng.
-
Routing: Định tuyến
-
Views: Chế độ xem
-
Class-based views: Chế độ xem cơ bản
-
Request context:
-
Cách Django xử lý một yêu cầu
Flask
Về cốt lõi, Flask sử dụng Werkzeug, cung cấp định tuyến URL và xử lý/ phản hồi yêu cầu.
Trong Flask đối tượng yêu cầu là toàn cầu, vì vậy bạn có thể truy cập nó dễ dàng hơn nhiều (miễn là bạn nhập nó). Các URL thường được xác định cùng với chế độ xem (thông qua hàm trang trí decorator), nhưng chúng có thể được tách ra thành một vị trí tập trung tương tự như mẫu Django.
-
Routing
-
Views
-
Class-based views
-
Request context
Bạn có lưu ý sự khác biệt trong cách mà cả Django và Flask xử lý đối tượng yêu cầu không? Nói chung, Flask có xu hướng rõ ràng hơn với mọi thứ, nhưng trong trường hợp này thì ngược lại: Django buộc bạn phải chuyển đối tượng yêu cầu một cách rõ ràng trong khi đối tượng yêu cầu của Flask khả dụng sẵn có một cách kỳ diệu. Đây là một trong những phần khó với Flask, đặc biệt là đối với những người mới làm quen với framework từ một framework có phong cách tương tự như Express.js.
Các biểu mẫu
Đi kèm với Django là biểu mẫu, một phần thiết yếu khác của hầu hết các ứng dụng web. Điều này bao gồm xử lý đầu vào và xác thực phía máy khách và máy chủ, xử lý các mối quan tâm bảo mật khác nhau như giả mạo yêu cầu trên trang web (CSRF), tập lệnh trang web chéo (XSS) và chèn SQL. Chúng có thể được tạo từ các mô hình dữ liệu (thông qua ModelForms) và tích hợp tốt với bảng điều khiển quản trị.
Flask không hỗ trợ các biểu mẫu mặc định, nhưng tiện ích mở rộng Flask-WTF tích hợp Flask với WTForms. WTForms-Alchemy được sử dụng để tự động tạo các biểu mẫu dựa trên các mô hình SQLAlchemy, thu hẹp khoảng cách giữa các biểu mẫu và ORM giống như ModelForm của Django.
Các thành phần có thể tái sử dụng
Về cấu trúc dự án, vì ứng dụng của bạn ngày càng phức tạp, cả hai framework đều giúp bạn dễ dàng chia nhỏ công việc bằng cách nhóm các tệp liên quan có chức năng tương tự lại với nhau. Ví dụ, bạn có thể nhóm tất cả chức năng liên quan đến người dùng lại với nhau, có thể bao gồm định tuyến, chế độ xem, biểu mẫu, template và nội dung tĩnh.
Django có concept về ứng dụng trong khi Flask có blueprint.
Ứng dụng Django phức tạp hơn so với Flask blueprint, nhưng chúng có xu hướng dễ sử dụng và tái sử dụng sau khi thiết lập. Ngoài ra, do quy ước urls.py, models.py và views.py - cấu trúc dự án nhất quán! - bạn có thể thêm các lập trình viên mới vào dự án Django một cách khá dễ dàng. Trong khi đó, thiết lập và chạy Blueprint dễ dang và đơn giản hơn.
Template và tệp tĩnh
Các công cụ template cho phép bạn đưa thông tin động vào một trang HTML từ chương trình phụ trợ backend. Flask sử dụng mặc địng Jinja2 trong khi Django có công cụ tạo khuôn mẫu riêng. Chúng khá giống nhau về cú pháp và bộ tính năng. Bạn cũng có thể sử dụng Jinja2 với Django.
Cả hai framework đều có hỗ trợ xử lý tệp tĩnh:
-
Django
-
Flask
Django đi kèm với một lệnh quản lý tiện dụng để thu thập tất cả các tệp tĩnh và đặt chúng ở vị trí trung tâm để triển khai lên production.
Chế độ xem không đồng bộ
Django hỗ trợ các trình xử lý không đồng bộ với sự ra đời của Django 3.1. Một chế độ xem có thể được tạo không đồng bộ bằng cách sử dụng từ khóa không đồng bộ async. Hỗ trợ không đồng bộ cũng có sẵn cho phần mềm trung gian. Nếu bạn cần thực hiện cuộc gọi đồng bộ bên trong chế độ xem không đồng bộ, bạn có thể sử dụng hàm sync_to_async / decorator. Điều này có thể được sử dụng để tương tác với các phần khác của Django chưa hỗ trợ async, như ORM và lớp bộ nhớ cache.
Máy chủ web không đồng bộ, bao gồm, nhưng không giới hạn, Daphne, Hypercorn, Uvicorn, nên được sử dụng với Django để tận dụng toàn bộ sức mạnh của chế độ xem không đồng bộ.
Flask 2.0 đã thêm hỗ trợ tích hợp cho các tuyến / chế độ xem không đồng bộ, trình xử lý lỗi, các hàm yêu cầu trước và sau và hàm teardown callback!
Để biết thêm về các chế độ xem không đồng bộ trong Django và Flask, hãy xem lần lượt các bài viết về Chế độ xem không đồng bộ trong Django 3.1 và Không đồng bộ trong Flask 2.0.
Thử nghiệm
Cả hai framework đều có hỗ trợ cài đặt sẵn để thử nghiệm.
Đối với thử nghiệm đơn vị, cả hai đều tận dụng framework độc nhất của Python. Django và Flask đều hỗ trợ kiểm thử client cho phép bạn có thể gửi yêu cầu đến, sau đó kiểm tra và xác nhận các phần của phản hồi.
Hãy xem các ứng dụng Testing Flask và Testing Django tương ứng để biết thêm thông tin.
Về phần tiện tích mở rộng, nếu bạn thích cách hoạt động của framework độc nhất, hãy xem Flask-Testing. Mặt khác, tiện ích mở rộng pytest-flask bổ sung hỗ trợ pytest cho Flask. Đối với Django, hãy xem pytest-django.
Các tính năng khác
Có một số tính năng khác chưa được đề cập cho Django và Flask:
Bảo mật
Như đã đề cập, Django được tích hợp tính năng bảo vệ chống lại một số vectơ tấn công phổ biến như CSRF, XSS và SQL injection. Các biện pháp bảo mật này giúp bảo vệ tránh khỏi các lỗ hổng trong mã của bạn. Nhóm phát triển Django cũng chủ động tiết lộ và nhanh chóng sửa chữa các lỗ hổng bảo mật đã được xác định. Mặt khác, Flask có cơ sở mã nhỏ hơn nhiều nên có ít khu vực bề mặt hơn bị tấn công. Tuy nhiên, bạn sẽ cần giải quyết và sửa các lỗ hổng bảo mật trong mã ứng dụng được làm thủ công của mình khi chúng xuất hiện.
Vào cuối ngày, bạn chỉ an toàn như liên kết yếu nhất của bạn. Vì Flask phụ thuộc nhiều hơn vào các tiện ích mở rộng của bên thứ ba, nên các ứng dụng sẽ chỉ an toàn bằng tiện ích mở rộng kém an toàn nhất. Điều này gây áp lực nhiều hơn lên nhóm lập trình của bạn trong việc duy trì bảo mật bằng cách đánh giá và giám sát các thư viện và tiện ích mở rộng của bên thứ ba. Luôn cập nhật là điều quan trọng nhất (và thường là khó nhất) vì mỗi tiện ích mở rộng đều có nhóm lập trình, tài liệu và chu kỳ phát hành riêng. Trong một số trường hợp, có thể chỉ có một hoặc hai lập trình viên duy trì một tiện ích mở rộng cụ thể. Khi đánh giá một tiện ích mở rộng này hơn so với một tiện ích mở rộng khác, hãy xem xét các vấn đề của GitHub để xem người bảo trì thường mất bao lâu cho phản hồi các vấn đề quan trọng.
Điều này không có nghĩa là Django vốn đã an toàn hơn Flask; nó chỉ dễ dàng hơn để bảo mật trước và duy trì trong suốt vòng đời ứng dụng của bạn.
Các nguồn tham khảo:
-
Cân nhắn bảo mật Flask
-
Bảo mật trong Django
-
Ứng dụng web bảo mật Flask
-
Bảo vệ Ứng dụng web Django khỏi các mối đe dọa bảo mật
Sự linh hoạt
Theo thiết kế, Flask linh hoạt hơn nhiều so với Django và nó có nghĩa là được mở rộng. Do đó, Flask thường mất nhiều thời gian hơn để thiết lập vì bạn sẽ phải thêm các tiện ích mở rộng thích hợp dựa trên nhu cầu kinh doanh - ví dụ: ORM, quyền, xác thực, v.v. Chi phí trả trước này mang lại sự linh hoạt hơn cho các ứng dụng không phù hợp với mô hình Django tiêu chuẩn.
Mặc dù vậy, hãy cẩn thận với điều này. Tính linh hoạt mang lại cho các nhà phát triển nhiều quyền tự do và quyền kiểm soát hơn, nhưng điều này có thể làm chậm quá trình phát triển, đặc biệt là đối với các nhóm lập trình lớn hơn vì cần phải đưa ra nhiều quyết định hơn.
Các nhà lập trình thích có quyền tự do làm bất cứ điều gì họ muốn để giải quyết vấn đề. Vì Flask không có nhiều ràng buộc hoặc quan điểm về cách một ứng dụng được phát triển nên lập trình viên có quyền giới thiệu ứng dụng của riêng họ. Kết quả là hai ứng dụng Flask có thể hoán đổi chức năng cho nhau được so sánh song song với nhau sẽ có cấu trúc khác nhau. Do đó, bạn cần một nhóm lập trình lão luyện hơn để hiểu các mẫu thiết kế, khả năng mở rộng và tầm quan trọng của thử nghiệm để xử lý sự linh hoạt đó.
Học tập
Học các mẫu thiết kế chứ không phải ngôn ngữ lập trình hoặc framework.
Bất kể mục tiêu cuối cùng của bạn là học Flask hay Django, hãy bắt đầu với Flask. Đó là một công cụ tuyệt vời để học các nguyên tắc cơ bản về phát triển web và các phương pháp hay nhất cùng với các phần cốt lõi của một web framework phổ biến cho hầu hết các framework.
1. Flask nhẹ hơn và rõ ràng hơn nhiều so với Django. Vì vậy, nếu bạn là lập trình viên web mới nhưng không sử dụng Python, bạn sẽ thấy việc phát lập trình trong Flask dễ dàng hơn nhiều vì bạn sẽ cảm thấy giống như đang làm việc với vanilla Python để xác định các trình xử lý yêu cầu và chế độ xem và những thứ tương tự khác.
2. Django có rất nhiều thứ phức tạp. Từ cấu trúc dự án đến cài đặt các chi tiết cơ bản mà bạn không biết gì về nó, bạn sẽ bị lạc và kết thúc bằng việc tìm hiểu về Django hơn là các nguyên tắc cơ bản thực tế.
Trong hầu hết mọi trường hợp, bạn nên học Flask trước Django. Thời điểm duy nhất bạn nên đi chệch hướng đó là khi bạn chỉ cần tải ứng dụng lên nhanh chóng để làm hài lòng một số bên liên quan. Hãy đảm bảo bạn sẽ quay lại Flask để tìm hiểu những kiến thức cơ bản tại một thời điểm nào đó.
Mã nguồn mở
Django và Flask đều có cộng đồng mã nguồn mở mạnh mẽ.
Thống kê của GitHub kể từ ngày 24/02/2022:
Đối tượng
|
Django
|
Flask
|
First commit
|
2005
|
2010
|
Người đóng góp
|
2,188
|
646
|
Người dùng*
|
849,772
|
959,728
|
Người xem
|
2,293
|
2,191
|
Stars
|
62,554
|
58,086
|
*Số lần phần phụ thuộc được sử dụng bởi các respiratory khác
Để biết thêm, hãy xem lại so sánh mã nguồn mở của Open Hub về Django và Flask.
Các câu hỏi bổ sung kể từ ngày 24 tháng 2 năm 2022:
--
Chúng ta có thể kết luận điều gì ở đây?
-
1. Cả hai cộng đồng đều rất năng động
-
2. Django cũ hơn và có nhiều cộng tác viên hơn
-
3. Flask được nhiều dự án sử dụng hơn
-
4. Django có nhiều nội dung hơn
Để thực sự so sánh các framework (hoặc hệ sinh thái) này từ góc độ mã nguồn mở, bạn phải tính đến Jinja2 và Werkzeug cùng với một số thư viện và tiện ích mở rộng cốt lõi của Flask như SQLAlchemy / Flask-SQLAlchemy, Alembic / Flask-Alembic và WTForms / Bình-WTF.
Vì chức năng cốt lõi của Flask được trải rộng trên nhiều dự án, nên khó tạo cộng đồng và phát triển sức mạnh tổng hợp cần thiết giữa các dự án để duy trì động lực. Ví dụ: Flask không có tiện ích mở rộng thực tế duy nhất để tạo các API RESTful; có (được cho là) bốn phần mở rộng phổ biến kể từ tháng 2 năm 2022:
Hơn nữa, để tìm thấy những tiện ích mở rộng này, bạn cần phải có một số kỹ năng truy xuất thông tin khá vững chắc. Bạn sẽ phải lọc qua tất cả các tiện ích mở rộng không được duy trì và các bài viết tham chiếu đến chúng. Trên thực tế, có rất nhiều dự án mở rộng khác nhau dành cho các API RESTful nên thường dễ dàng hơn nếu chỉ sử dụng mã nguồn mở của riêng bạn. Tại thời điểm đó, bạn có thể sẽ duy trì nó một chút nhưng cuối cùng, nó sẽ trở thành vấn đề hơn là một giải pháp.
Chú ý:
-
Đây không phải là lên tiếng chống lại cộng đồng Flask. Đó là một vấn đề trong toàn bộ mã nguồn mở, đặc biệt là với các khuôn khổ web vi mô, nơi bạn thường phải tập hợp một số dự án do các nhà phát triển khác nhau duy trì trên các chu kỳ phát hành khác nhau với các mức chất lượng tài liệu khác nhau. Hãy đến với cộng đồng JavaScript nếu bạn muốn tận hưởng điều này.
-
Cộng đồng Django không nằm ngoài với điều này bằng bất kỳ phương tiện nào. Chỉ là với Django, đây là một vấn đề nhỏ hơn vì nó xử lý hầu hết mọi thứ cần thiết để xây dựng và bảo mật một ứng dụng web tiêu chuẩn ngay từ đầu.
Để biết thêm về bài đánh giá này, phần "Động lực mã nguồn mở" từ Django vs Flask: Quan điểm của một người hành nghề:
Bởi không có một mặt trận thống nhất nên cơ hội cho những nỗ lực hiệp lực để liên kết các tiện ích mở rộng sẽ không thành hiện thực, việc tạo ra các tiện ích mở rộng sẽ trở nên vô nghĩa. Nếu các lập trình viên chọn công cụ khác thì họ sẽ phải tìm ra chức năng bao gồm tất cả.
Tuyển dụng
Bất chấp sự phổ biến của cả Python và Django, thật khó để tuyển dụng các lập trình viên Django. Họ rất khó tìm và giữ lại vì các công ty đều có nhu cầu tìm kiếm họ mà họ thường ở mức độ năng lực cao hơn và được trả lương cũng rất cao. Cũng không có nhiều lập trình viên mới và đầy tham vọng học Django vì ngành này tập trung nhiều hơn vào các framework nhỏ hơn và bản thân framework này rất khó học.
-
Xu hướng của ngành: Do sự gia tăng của các microservices, các lập trình viên web đầy tham vọng thường học các framework nhỏ hơn, nhẹ hơn. Thêm vào đó, ngày càng nhiều lập trình viên web chọn JavaScript, thay vì Python hoặc Ruby, làm ngôn ngữ đầu tiên của họ do sự phổ biến của các framework JavaScript phía máy khách - Angular, React và Vue.
-
Khó học: Thiếu nhiều các hướng dẫn Django thân thiện với người mới bắt đầu. Ngay cả tài liệu Django, vô cùng dễ hiểu và hướng dẫn học tập cũng không được thiết kế cho người mới bắt đầu.
Cũng khó có thể tuyển dụng lập trình viên Flask, nhưng nó có xu hướng dễ dàng hơn Django vì đây là một framework nhẹ nhàng với ít lớp trừu tượng hơn. Một lập trình viên giỏi và có kinh nghiệm về framework tương tự bằng một ngôn ngữ khác, như Express.js hoặc Sinatra, có thể bắt kịp tốc độ với ứng dụng Flask khá nhanh chóng. Khi tuyển dụng những lập trình viên như vậy, hãy tập trung tìm kiếm vào những người hiểu các mẫu thiết kế và nguyên tắc cơ bản của phần mềm hơn là ngôn ngữ hoặc framework mà họ biết.
Các trường hợp sử dụng
Hãy để ý đến nhu cầu cá nhân của dự án khi bạn quyết định chọn một framework. Vì Django cung cấp tiện ích phụ ưa thích nên bạn có thể tận dụng chúng. Nếu bạn có bất đồng mạnh mẽ với cách Django xử lý điều gì đó, bạn có thể muốn sử dụng Flask. Điều này cũng tương tự nếu bạn không tận dụng được cấu trúc và công cụ mà Django cung cấp.
Hãy xem một số ví dụ.
Cơ sở dữ liệu
Nếu ứng dụng của bạn sử dụng SQLite, PostgreSQL, MySQL, MariaDB hoặc Oracle, bạn nên xem xét kỹ Django. Mặt khác, nếu bạn đang sử dụng NoSQL hoặc không có cơ sở dữ liệu nào, thì Flask là một lựa chọn chắc chắn.
Quy mô dự án và tuổi thọ mong đợi
Flask tốt hơn cho các dự án nhỏ, ít phức tạp và có phạm vi được xác định rõ, tuổi thọ mong đợi ngắn hơn.
Vì Django buộc cấu trúc ứng dụng nhất quán bất kể quy mô của dự án như thế nào nên gần như tất cả các dự án Django đều có cấu trúc tương tự. Do đó, Django xử lý tốt hơn các dự án lớn (với các nhóm lập trình lớn hơn), có tuổi thọ lâu hơn và tiềm năng tăng trưởng cao vì thỉnh thoảng ,rất có thể bạn sẽ phải liên hệ với các lập trình viên mới cho dự án.
Loại ứng dụng
Bạn đang xây dựng loại ứng dụng nào?
Django xuất sắc trong việc tạo các ứng dụng web đầy đủ tính năng với tạo mẫu phía máy chủ. Nếu bạn chỉ đang phát triển một trang web tĩnh hoặc dịch vụ web RESTful cung cấp nguồn cấp dữ liệu cho SPA hoặc ứng dụng di động, thì Flask là một lựa chọn phù hợp. Django cùng với Django REST Framework cũng hoạt động tốt trong trường hợp thứ hai.
RESTful APIs
Thiết kế một RESTful API?
Django REST Framework (DRF) là một trong những gói Django của bên thứ ba phổ biến nhất và là framework được sử dụng để hiển thị các mô hình Django thông qua giao diện RESTful. Nó đi kèm với mọi thứ bạn cần (lượt xem, trình tuần tự hóa, xác thực, ủy quyền) và hơn thế nữa (API có thể duyệt, lập phiên bản, có bộ nhớ đệm) để xây dựng API nhanh chóng và dễ dàng. Và hãy nhớ rằng giống như Django ORM, nó được thiết kế để kết hợp với một cơ sở dữ liệu quan hệ.
Flask cũng có một số tiện ích mở rộng tuyệt vời:
Hiệu quả hoạt động
Flask hoạt động tốt hơn một chút vì nó nhỏ hơn và có ít lớp hơn. Tuy nhiên, sự khác biệt ở đây là không đáng kể, đặc biệt là khi bạn chú ý đến I / O.
Kết luận
Framework nào bạn nên sử dụng? Câu trả lời là sử dụng một framework hoặc ngôn ngữ hoặc công cụ phụ thuộc gần như hoàn toàn vào bối cảnh và vấn đề hiện tại.
Django có đầy đủ tính năng nên bạn hoặc nhóm của bạn ít phải đưa ra quyết định hơn. Bạn có thể phát triển nhanh hơn theo cách đó. Tuy nhiên, nếu bạn không đồng ý với một trong những lựa chọn mà Django đưa ra hoặc bạn có các yêu cầu ứng dụng duy nhất giới hạn số lượng tính năng có thể tận dụng, bạn có thể muốn tìm đến Flask.
Luôn luôn có sự đánh đổi và thỏa hiệp.
Hãy nghĩ về những ràng buộc của dự án, như thời gian, kiến thức và ngân sách. Một số tính năng chính của ứng dụng là gì? Bạn không thể thỏa hiệp với điều gì? Bạn cần phát triển nhanh? Ứng dụng của bạn có đòi hỏi nhiều tính linh hoạt không? Cố gắng đừng để ý kiến chủ quan ảnh hưởng khi bạn trả lời những câu hỏi này.
Cuối cùng, cả hai framework đã giảm bớt rào cản gia nhập để xây dựng các ứng dụng web, giúp chúng phát triển dễ dàng và nhanh chóng hơn nhiều.
> Tham khảo: khóa học lập trình python tại NIIT hà nội