- Django 6.0 đánh dấu cột mốc 20 năm là một bản phát hành lớn với những cải tiến đáng kể ở các lĩnh vực cốt lõi như template, tác vụ nền, bảo mật và email
- Tính năng Template partials giúp việc tái sử dụng mã trong template trở nên dễ dàng hơn, đồng thời tăng cường khả năng tích hợp với các công cụ như htmx
- Framework Tasks mới được bổ sung, cho phép chạy các tác vụ nền bên ngoài chu kỳ yêu cầu-phản hồi HTTP
- Content Security Policy(CSP) được tích hợp sẵn, giúp đơn giản hóa việc phòng vệ trước các cuộc tấn công chèn nội dung như XSS
- Hiện đại hóa API email, cải tiến ORM, mở rộng khóa chính mặc định và nhiều thay đổi khác đã cải thiện mạnh mẽ trải nghiệm phát triển và khả năng mở rộng
Tổng quan về Django 6.0
- Django 6.0 là bản phát hành mới của framework web Python, tiếp nối hành trình phát triển suốt 20 năm
- Các thay đổi chính tập trung quanh bốn nhóm tính năng cốt lõi: template, tác vụ nền, bảo mật và xử lý email
- Nhiều thành viên trong cộng đồng phát triển đã tham gia đóng góp, và các cải tiến chính được tổng hợp dựa trên ghi chú phát hành chính thức
Công cụ django-upgrade
- Khi nâng cấp dự án hiện có từ Django 5.2 trở xuống, có thể dùng công cụ django-upgrade để tự động chuyển đổi mã
- Công cụ này bao gồm 5 fixer tự động liên quan đến Django 6.0 và có thể xử lý tự động một số cảnh báo
Template partials
- Tính năng định nghĩa phần template (
{% partialdef %}) được bổ sung, giúp giảm trùng lặp mã và tăng khả năng tái sử dụng trong template
- Có thể gọi nhiều lần một partial được định nghĩa trong cùng template
- Dùng tùy chọn
inline để vừa định nghĩa vừa render ngay lập tức
- Tính năng render từng phần cho phép chỉ render độc lập một partial cụ thể
- Trong ví dụ, htmx được dùng để cập nhật định kỳ phần
view_count
- Có thể gắn
#partial_name vào URL để chỉ render phần cụ thể đó
- Tính năng này được tích hợp vào Django thông qua dự án Google Summer of Code, phát triển từ gói
django-template-partials trước đó
Framework Tasks
- Django mới bổ sung framework Tasks để chạy tác vụ nền
- Có thể thực thi mã bên ngoài chu kỳ yêu cầu-phản hồi HTTP
- Hữu ích cho các tác vụ bất đồng bộ như gửi email, xử lý dữ liệu và tạo báo cáo
- Có thể định nghĩa tác vụ bằng decorator
@task và đưa vào hàng đợi bằng Task.enqueue()
- Backend mặc định đi kèm gồm
ImmediateBackend và DummyBackend dành cho phát triển,
còn có thể dùng DatabaseBackend của gói django-tasks để chạy trên cơ sở dữ liệu SQL
- Chạy worker tác vụ bằng lệnh
db_worker và theo dõi trạng thái qua log
- Tính năng này bắt nguồn từ ý tưởng trong Wagtail và được tích hợp vào Django sau đề xuất DEP 0014
Hỗ trợ Content Security Policy(CSP)
- Django 6.0 hỗ trợ chuẩn CSP ngay trong lõi, tăng cường phòng vệ trước các cuộc tấn công chèn nội dung như XSS
- Kích hoạt bằng cách thêm
ContentSecurityPolicyMiddleware vào MIDDLEWARE
- Có thể cấu hình chính sách bằng
SECURE_CSP và SECURE_CSP_REPORT_ONLY
- Bảo mật dựa trên nonce được tích hợp sẵn, cho phép thêm thuộc tính
nonce="{{ csp_nonce }}" vào thẻ <script> và <style>
- Một nonce ngẫu nhiên được tạo cho mỗi request để chỉ cho phép thực thi tài nguyên đáng tin cậy
- CSP đã từng được triển khai qua gói
django-csp kể từ sau đề xuất năm 2004, và nay trở thành tính năng chính thức tích hợp sẵn
Cập nhật API email
- Logic xử lý email của Django được chuyển sang API email hiện đại của Python 3.6
- Nội bộ sử dụng lớp
email.message.EmailMessage
- Giao diện
send_mail() và EmailMessage hiện có vẫn được giữ nguyên
- API mới mang lại các lợi ích như giảm lỗi, tăng cường bảo mật và cải thiện xử lý tệp đính kèm inline
- Có thể dùng đối tượng
MIMEPart để dễ dàng thêm tệp đính kèm inline như hình ảnh trong phần thân HTML
- Thay đổi này được đề xuất vào năm 2024 và được hợp nhất sau 8 tháng phát triển
Giới hạn đối số vị trí trong API email
- Trong API
django.core.mail, một số tham số nay được đổi thành chỉ cho phép đối số từ khóa
- Nếu truyền các đối số tùy chọn như
fail_silently theo dạng đối số vị trí thì sẽ có cảnh báo
- Mục tiêu là cải thiện tính dễ đọc và khả năng bảo trì
- Có thể tự động sửa bằng fixer
mail_api_kwargs của django-upgrade
Mở rộng auto import trong Shell
- Tính năng tự động import model từ Django 5.2 đã được mở rộng để tự động import thêm
settings, connection, models, functions, timezone
- Có thể kiểm tra danh sách tự động import bằng
./manage.py shell -v 2
- Điều này giúp tăng tiện lợi khi phát triển và giảm mã lặp lại
Cải tiến ORM: cập nhật trường động khi save()
GeneratedField hoặc các trường dựa trên biểu thức sẽ được tự động cập nhật sau save()
- Được phản ánh ngay trên các cơ sở dữ liệu hỗ trợ mệnh đề
RETURNING như SQLite, PostgreSQL và Oracle
- Trên MySQL và MariaDB, việc cập nhật diễn ra tự động thông qua lazy loading
- Nhờ đó có thể dùng ngay giá trị mới nhất mà không cần truy vấn bổ sung, giúp tăng hiệu quả
Hàm tổng hợp StringAgg phổ quát
- Hàm tổng hợp
StringAgg nay có thể dùng trên mọi backend cơ sở dữ liệu
- Trả về chuỗi được nối từ các giá trị đầu vào bằng dấu phân tách (delimiter)
- Trước đây là tính năng riêng của PostgreSQL, nay có thể dùng trực tiếp từ
django.db.models
- Có thể chỉ định delimiter bằng biểu thức
Value()
BigAutoField trở thành mặc định
- Giá trị mặc định của
DEFAULT_AUTO_FIELD được đổi thành BigAutoField
- Sử dụng khóa chính số nguyên 64-bit để ngăn nguy cơ cạn kiệt Primary Key
- Trong các dự án mới, thay đổi này được áp dụng tự động mà không cần cấu hình riêng
- Đây là bước đơn giản hóa cấu hình được giới thiệu từ Django 3.2, giúp giảm boilerplate
Cải tiến Template
- Biến
forloop.length được bổ sung để có thể tham chiếu tổng độ dài ngay trong vòng lặp
- Có thể dùng theo dạng
{{ forloop.counter }}/{{ forloop.length }}
- Thẻ template
querystring cũng được cải thiện
- Tự động thêm
? khi mapping rỗng để đảm bảo hành vi liên kết nhất quán
- Hỗ trợ gộp nhiều đối số mapping, giúp kết hợp tham số truy vấn dễ dàng hơn
Kết luận
- Django 6.0 có sự tham gia đóng góp của 174 người,
đồng thời bao gồm rất nhiều tối ưu hóa và sửa lỗi
- Việc nâng cấp giúp cải thiện toàn diện bảo mật, khả năng bảo trì và trải nghiệm lập trình viên (DX)
- Có thể xem thêm các thay đổi khác trong ghi chú phát hành chính thức
1 bình luận
Ý kiến trên Hacker News
Tôi đã dùng Django không thường xuyên ở công ty suốt vài năm nay. Nhìn chung tôi thích nó, nhưng ORM vẫn cảm thấy khó dùng
Django là một framework có tính định hướng rất mạnh, và giờ tôi mới thực sự hiểu rằng phải đi theo “cách của Django”.
Vấn đề là tôi phải xử lý nhiều cơ sở dữ liệu của các bộ phận kinh doanh khác nhau, nên lần nào cũng rất vất vả để thích ứng với những điểm đặc thù đó.
Cuối cùng tôi xử lý bằng cách tắt
managed, lấy schema bằnginspectdb, rồi xóa thủ công những bảng không muốn lộ ra trên web.Với các ứng dụng web mới làm, Django vẫn là lựa chọn tốt nhất
Django không lưu trạng thái schema cùng với code, nên mỗi lần chạy lệnh DB lại phải suy luận trạng thái hiện tại.
Việc định nghĩa trạng thái DB bằng code model về bản chất có giới hạn.
Tôi thích cách của Rails hơn: cấu thành migration bằng các lệnh DB tường minh, rồi đặt model lên trên đó
Giao diện Manager lúc đầu hơi khó hiểu, nhưng công cụ migration thì thật sự rất tuyệt
Bạn có thể vừa có được sự linh hoạt của việc tinh chỉnh SQL, vừa giữ được sự tiện lợi của Django.
Chỉ cần nhớ tạo chúng bên trong script migration
Tôi rất thích việc Django được cải tiến đều đặn qua từng bản phát hành.
Đặc biệt bản 6.0 có nhiều tính năng hữu ích nên rất đáng quan tâm.
Nói công nghệ đáng tin cậy là nhàm chán là sai. Phát triển như thế này mới đúng
Hiện tôi đang sống gần nơi Django ra đời.
Nhân tiện, tôi đang tìm việc từ hôm qua, nên nếu ai đang tìm lập trình viên Django giàu kinh nghiệm thì hãy liên hệ (oldspiceap@gmail.com)
Code hay blog Adam viết lúc nào cũng đáng đọc.
Tôi rất mong chờ xem framework tasks sẽ phát triển thế nào về sau.
Tuy vậy, hơi tiếc khi Django-Q2 rất tuyệt lại bị nhắc cùng với Celery
Nó có nhiều lỗi, nhưng lượng người dùng quá lớn nên hiếm khi bạn là người đầu tiên gặp vấn đề.
Tôi đã xử lý ổn định hàng chục triệu tin nhắn mỗi ngày với tổ hợp Celery + RabbitMQ.
Nó vẫn là giải pháp đáng cân nhắc đầu tiên
Ở các stack khác tôi cũng dùng Kafka, nhưng đó là use case ở một cấp độ hoàn toàn khác
Tôi đã dùng Django khoảng 5~6 năm, và dù ưu điểm ‘kèm sẵn đủ thứ’ là rõ ràng, tổng thể nó vẫn có cảm giác nặng nề
Tính năng template partial trông rất hay.
Một trong những lý do React trở nên phổ biến là khả năng tái sử dụng code, và có vẻ Django cũng đang đi theo hướng đó
Ví dụ có ở đây trong code
Tôi chủ yếu dùng Odoo, nhưng cũng từng làm một chút với Django và Celery.
Với tư cách là người dùng nhiều module OCA queue của Odoo,
tôi luôn thắc mắc vì sao Django không tận dụng tính năng LISTEN/NOTIFY của Postgres.
Có lẽ là do tôi chưa quen với hệ sinh thái Django
Template Partials và HTMX cho tôi cảm giác giống phiên bản Django của Rails View Components + Stimulus.
Tôi cũng vui vì tính năng Tasks được hỗ trợ chính thức
Tôi đã dùng Django từ thời 1.x, từ cả thời chưa có ORM.
Thật sự ngạc nhiên là đến bây giờ mới có thêm chức năng chạy task.
Không phải để chê bai, chỉ là một quá trình tiến hóa thú vị thôi
Mỗi tính năng chỉ được đưa vào sau khi đã được kiểm chứng đủ nhiều, và họ tập trung vào LTS cũng như tính ổn định của API.
Nhờ vậy mà ngay cả khi có phiên bản mới, bạn hầu như không phải viết lại cả ứng dụng
Hồi đó nó còn đơn giản, nhưng trong một thời gian khá dài tôi không cần phải dùng raw SQL
Thảo luận thêm đang tiếp tục ở thread này
Khi dùng Django với HTMX, tôi thấy template theo đơn vị component quá bất tiện,
nên đã tự làm một thư viện component dựa trên Python là Compone.
Nó không chỉ dùng được với Django mà còn với mọi web framework Python, và mang lại trải nghiệm phát triển dễ chịu hơn nhiều