系列最終章，我們的「Django Ninja 探險」將暫時告一段落。

這當然不是結束，畢竟 Django Ninja 還只是一個相對新的專案——我對它的未來充滿期待。

本文將分為兩個部分：

1. 回顧整個系列，檢視我們在各章中學到的概念與技術——盡可能只提重點。
2. 分享我在寫作過程中的最大挑戰、對 Django Ninja 的期待，最後則是我的鐵人賽完賽心得。

受限於篇幅，更多的幕後花絮、創作細節及個人心得，我將在與正賽無關的第 31、32 篇中，再行分享。

此外，我還會不定期更新「Django Ninja 番外篇」，補充正篇中未能詳述的內容。有興趣的讀者，歡迎訂閱本系列唷！

話不多說，我們直接開始。

一、系列目標與主要學習成果

回到第 1 篇的開頭，整個系列的目標是：

在這個 30 天的系列文章中，我們將詳細探討 Django Ninja 的基礎實作，透過文字教學與範例專案的程式碼，帶你一步一步熟悉這個強大而靈活的 Django API 開發框架。

沒錯，而我們具體做了哪些事呢？

主要學習成果

透過本系列，讀者掌握了以下 Django Ninja 核心技能：

1. 設定 Django Ninja 路由。（卷 7-8）
2. 處理各種 HTTP 請求及參數——路徑參數、查詢參數、body。（卷 9-12）
3. 使用 Schema 設計和定義 API 回應的資料結構。（卷 13-16）
4. 從專案程式碼自動產生 API 文件、透過 Pydantic 驗證資料、有效處理系統拋出的錯誤。（卷 17-22）
5. 靈活運用進階功能，包括檔案上傳、分頁和資料過濾。（卷 23-27）

還有最後的身分認證與單元測試。可說是一段相當完整的旅程。

其中的精妙與困難，這裡不再贅述。

讓我們一起回顧，我認為學習 Django Ninja 的一些重點，以及它帶來的滿足感——這很重要！

二、各章節重點回顧

我們只挑各章節中特別值得一提的部分。有我個人的觀點。

第二章：範例專案與環境設定

本章最重要的，莫過於對「Python 現代開發工具」的介紹。再次推薦「Python Table Manners」系列。

從 Poetry 到 Mypy，我認為這些工具都是現代專案中的必備要素。它們各有替代品，你可以選擇自己偏好的工具，只要確保這些要素都已整合到開發流程中。

我相信，無論 AI 如何發展，專案的「基礎建設」總是不可少的。

第三章第一節：路由

Django Ninja 的路由設定與傳統的 Django、Django REST framework 有很大的不同。

這部分，後起之秀基本上都向 Flask 首創的「路由裝飾器」看齊——優秀的設計，值得相互借鑑、學習🫡

新寫法不僅更直覺、簡單，還減少了路由設定分散在不同檔案的窘境。

不過，路由也因此成了一開始學習 Django Ninja 的小小門檻。所以我花了足足兩篇，比較兩者的差異，讓你能更清楚其中的思路與考慮。

第三章第三節：HTTP 回應

表面上是講 HTTP 回應，其實重點在介紹 Django Ninja Schema——也就是 Pydantic BaseModel。

說本節是「Pydantic 入門」，一點也不為過。

而且，對 Pydantic 的了解，其重要性還延伸至 API 文件、資料驗證等後續章節。可說是一切的基礎。

Django Ninja 用 Schema 來組織與序列化 HTTP 回應，這與 Django REST framework 使用的序列化器，本質上並無區別。

但兩者在使用思維上的差異，卻帶給我截然不同的體驗。主要見解我已寫在〈卷 15：回應（三）為何不用 ModelSchema？——相比 DRF，我更偏愛 Django Ninja 的理由〉，值得你再三回味。

第四章：API 文件

這還有什麼好說的呢？太關鍵了！

如果沒有「依程式碼、type hints 自動產生 API 文件」這個殺手級功能，習慣 Django REST framework 的開發者如我，怎麼會有動力再學習一個定位類似的新框架？

懶就是一切的動力！

第五章：資料驗證與錯誤處理

這一章是我的血與淚😂

Django Ninja 的資料驗證與錯誤處理方式，和 Django REST framework 很不一樣。更讓我頭痛的是，之前工作中我並非以「最正規」的方式實踐——仍受到 Django REST framework 開發習慣的影響。

那時還想說：「這也太難用了吧！」——原來是我自己誤解了。為了寫好這 4 篇，我幾乎是重新學習。不得不說，有一種豁然開朗的感覺。

因此，你在本系列看到的實作方式，應該是相當合理、道地的用法。結合經驗，那些坑我都幫你踩過了，請勿擔心。

接下來是個人心得部分。

三、寫作上的最大挑戰

我覺得，整個系列在創作上的最大挑戰，就是要盡可能搭配 GitHub 專案中的程式碼，來為文章提供稱職且連貫的範例。

（不用說，這個專案非常歡迎「來自你的星星」唷🌟）

這比單純的舉例要麻煩許多，我必須事先規劃整個系列的內容進度，思考 API 實作如何跟每一篇的主題契合，讓人有「帶入感」。

此外，還得考慮到敘事上的連貫性——程式碼要循序漸進，從簡單到複雜，而不能反過來。這樣讀者才能夠順暢地跟著專案一起學習。

這樣的規劃不僅需要技術知識，更多的是教學思維與讀者意識——知道讀者可能會在哪裡「卡關」。

整體而言，是個極具挑戰但也非常有趣的過程。

四、我對 Django Ninja 的評價與期待

Django Ninja 是烏克蘭開發者 Vitaliy Kucheryaviy 一人維護的開源專案，更新的頻率不高，通常無法立刻回應用戶們的期待。

但我想說：「如果可以，我真的不願再回去寫 Django REST framework 了。」

原因只有一個，就是第 15 篇提到的——「明確優於隱晦」（Explicit is better than implicit）。

Django Ninja 也許沒讓開發更「快」，但絕對更透明、更可控。

我相信，從長遠來看，這種透明與可控，能為我們省下的 debug 時間，遠不是簡單的「快」可以比擬的。

未來期待

隨著 Django 本身對非同步（async）的支援日益增加，我相信 Django Ninja 的潛力正被逐步釋放。

我期待，在不久的將來，當人們談到「用 Django 寫 API」時，不再只有想到 Django REST framework，還會提及這個強而有力的新選擇——Django Ninja。

五、完賽心得

呼！終於寫完了，這個過程比我想像的更加漫長。

從 9 月初到雙十節，整整 40 天（含開賽前的備稿），我每天早上醒來就是寫作，全心全意投入到這場盛宴當中。最終，我交出了一份自己也覺得滿意的作品。

在我看來，寫作的滿足感在於「提供價值、發揮影響力」。這份價值不僅是對讀者，也包括對作者自己——透過這 30 篇文章創作，我對 Django Ninja 的理解又增進許多。

希望這個系列能為你帶來些許價值，讓你在接下來的開發旅程中更加得心應手。

每一次的寫作都是一次學習，而每一次的學習都是一次成長。這個系列或許已經結束，但我們的軟體工程師之路，還遠遠沒有。

而且，如果可以，我希望這能成為一生的追求。

本文同步發表於我的部落格——Code and Me