整體示意圖#
前端#
前端以漸進式網頁應用程式 (PWA) 形式開發，採用以 React 為基礎的 Ionic Framework，本質上就是一個網頁，不過引入了 Service Worker 技術，使整個網頁的使用體驗接近一個 Native App。
雖然 Ionic Framework 提供模仿 iOS 介面設計的 Cupertino 樣式和 Android 上的 Material Design 2，但為了確保在不同平台上的使用體驗一致，「文言貍」一律採用 Material Design 作為基底，並經過高度自定化的設計，使介面設計更清新、更現代化。
Ionic Framework 絕對是我最喜愛且最常用的 React 程式庫，它提供視覺統一的介面組件，大大減輕開發的難度和所需時間（唔係廣告，我都想佢哋搵我賣廣告 ）。此外，Ionic 團隊更開發了一套名為「Capacitor」的系統跨平台 native runtime，將已經寫好的 PWA 不費吹灰之力地封裝為 native 的 Android、iOS 甚至 Desktop 應用程式，倘若未來「文言貍」有意於 Google Play Store 和 Apple App Store 上架便無須額外費時開發各個平台的 Native 版本或轉換為 React Native 程式碼。
後端#
Google Firebase#
本來我打算 self-hosted 一個 Supabase 作為後端，但最後為了穩定性選擇了 Google Firebase 服務。
在「文言貍」中，Google Firebase 最主要負責處理使用者的部份，包括註冊、登入和登出，這部份由 Google Firebase 的 Authentication 提供技術支援，無可否認在接入「Signin with Google」的過程中，使用 Google Firebase Authentication 比 Supabase 和 Clerk 方便得多， 無須手動前往 Google Cloud Platform 註冊應用程式和 OAuth 然後獲取 credential。
此外，「文言貍」亦採用了 Google Firebase 的 Firestore 來處理需要嚴格保護的資料，例如學生的個人資料，因為 Firestore 提供嚴格的規則功能，可以限制哪些使用者能夠讀取哪些資料，能夠在哪些欄位寫入資料等。
題庫系統#
在 MVP 階段，題庫是以 JSON 形式硬編碼在前端程式碼當中，但當正式推出之時肯定不能採用這個方式，此舉不但會令 PWA 變得非常臃腫，降低學生進入「文言貍」網站的速度，而且非常容易被人直接複製整個題庫另起爐灶，不符合知識產權保護的原則。
於是，我開發了一個應用程式介面（API）作為前端 PWA 和後端題目資料庫之間的橋樑，這個 API 擔當了使用者身份驗證、隨機選取、課題過濾和嚴格執行用量限制規則的角色，防止題庫被爬蟲或有心人士一次性批量盜取。
學生練習進度追蹤系統#
此系統專門為學校統一採購而設，方便學校老師持續了解學生的學習動向，由於學校老師習慣使用試算表，因此整套系統皆基於 Google Sheets 打造，方便老師們後續進行資料分析。
當學校統一採購文言貍系統後，學生便能透過學校電郵（@example.edu.hk）於「文言貍」註冊帳戶，如果學校於採購時有啟用「學生練習進度追蹤」，系統便會在學生每次完成練習後將該此練習的記錄透過 Google Sheets API 寫入每間學校的專屬工作表之中。
當日後有更多訂戶學校之後，我會為此系統添加佇列機制和後備資料庫，確保在超過 Google Sheets API 併發和用量限制後系統仍能繼續如常運作。
總結#
終於寫完兩篇文章，後續有其他想分享嘅內容我再繼續寫 :)