Travel

Github：https://github.com/mohdjami/Travel

部署連結：https://travelplanai.vercel.app/

YouTube 影片：https://youtu.be/oeioDsKQ4cQ?si=U35aBhen3L3zJApq

---

應用架構和流程

---

---

上圖給出了應用程式、服務和解決方案的高級概述。

我利用了 Next.js、Supabase、Gemini-1.5-flash Model、Shadcn、Typescript 和 Tailwind CSS。

1. 在 https://travel- Three-lovat.vercel.app/signup 上註冊您的帳戶
2. 您將被記錄並重新導向至 /Itinerary 頁面。
3. 每個用戶都會收到 5 個積分，因為我也有來自 Gemini API 的限量代幣。
4. 填寫旅行行程表並點擊產生按鈕。
5. 需要幾秒鐘的時間，請求才會被傳送到後端，其中包含使用者首選項資料。
6. 路線處理程序建立使用者首選項 dB，建立個人化提示。
7. 提示被傳送到 Gemini 模型，並收到回應。
8. 收到回應後，它會被細化、清理並解析為 JSON。
9. 然後響應被儲存在資料庫中並發送回客戶端。
10. Fronted 使用 Leaflet Maps API 來顯示每個 Activity 的位置。
11. 賓果！旅行行程可供 PDF 或 TXT 格式下載。
12. 您可以前往儀表板進行管理並查看最近的行程。

模式 ERD 圖

---

實施細節

---

我已將應用程式分為這些模組。

認證與授權

---

• 使用 Supabase 對使用者進行身份驗證和授權

  為什麼要使用 Supabase 進行身份驗證和資料儲存？

  1. 身份驗證、儲存、資料庫全部集中在一處。
  2. Supabase 建構在 PostgreSQL 之上，提供強大且功能豐富的資料庫系統，支援編寫原始 SQL 查詢來建立表格、RLS 策略和授予權限。
  3. 很棒的開發者經驗。

• 吉圖布

  1. 在 Github 中建立 OAuth 應用程式並將其整合到資料庫中。
  2. 在 auth/callback/route.ts 中交換程式碼以進行身份驗證，並在資料庫中建立一個新使用者。

• 證書

  1. 使用者建立一個帳戶。
  2. 在身份驗證服務中建立使用者。
  3. 新用戶將新增到 Supabase 的用戶表中。

行程生成

---

這裡我們使用了 Google gemini-1.5-flash 模型。

Next.js 用於建立全端應用程式。

由於伺服器端渲染、靜態網站產生和 SEO，Next.js 是一個絕佳的選擇。

為什麼選擇 Next.js？

---

• API 路由使得為應用程式建立端點變得非常容易。
• 基於檔案的路由增加了開發人員體驗。
• Shadcn 和 Tailwind 等函式庫可以節省大量時間並建立無縫的 UI。
• 一流的 TypeScript 支持，無需額外配置，這是 Node.js 中沒有的
• 快速、輕鬆的部署。
• 對於需要伺服器端渲染、API 路由和可擴展性的項目，Next.js 提供了強大、高效能且對開發人員友善的解決方案。它與 React 的整合、內建優化和強大的社群支援使其成為現代 Web 開發的有吸引力的選擇。

旅遊行程表

---

從行程表中收到使用者首選項後，請求將連同所有資料傳送到後端。

顯示行程

---

然後在組件中使用行程來顯示資料。我還整合了傳單中的地圖。

Gemini-1.5-flash

---

Gemini-1.5-flash 是 Google 開發的先進人工智慧模型，為我們應用程式中的行程生成提供支援。該模型擅長理解複雜的旅行偏好並產生詳細的個人化行程。透過利用 Gemini-1.5-flash，我們能夠創建高度客製化的旅行計劃，並考慮預算限制、個人興趣和旅行持續時間等因素。

為什麼我使用 AI 而不是手動呼叫 API 來獲取位置資料？

---

它為我們的旅行行程應用程式提供了幾個關鍵優勢。首先，人工智慧驅動的行程產生可以比手動方法更快、更有效率地處理大量有關目的地、景點和用戶偏好的數據。其次，它允許高度個人化的推薦，可以適應每個用戶的獨特興趣和限制。最後，人工智慧可以根據用戶回饋和旅行趨勢不斷學習和改進其建議，確保我們的應用程式對旅行者保持相關性和價值。

傳單地圖整合

---

Leaflet 是一個開源 JavaScript 函式庫，用於行動友善的互動式地圖。為了將 Leaflet 地圖整合到我們的旅行行程應用程式中，我們遵循了以下關鍵步驟：

• 安裝了 Leaflet 套件及其 React 包裝器
• 建立一個動態地圖元件來處理客戶端渲染
• 為行程中的每個活動地點實施標記

透過合併傳單地圖，我為生成的行程中的每個目的地和活動提供視覺背景，從而增強了使用者體驗。

我還遇到了傳單的問題，即地圖元件未加載 100%，導致錯誤和頁面無法正確加載。所以我用這個解決方案解決了這個問題。

附加功能：

學分制

---

為了增強使用者體驗並管理 API 使用，我實作了一個基於積分的系統。它的工作原理如下：

• 新用戶註冊後可獲得 5 個免費積分
• 每一代行程消耗 1 個積分
• 用戶可以根據需要購買額外的積分（未來實施）

該系統使我們能夠控制 API 成本，同時為使用者提供使用服務的靈活性。

儀表板

---

儀表板為使用者提供了產生的行程、剩餘積分和帳戶資訊的概覽。主要特點包括：

• 最近的行程清單。
• 信用餘額顯示和購買更多信用的選項

用戶個人資料和設置

---

使用者設定檔和設定部分允許使用者自訂他們的體驗並管理他們的帳戶資訊。本節的主要特點包括：

• 目前用戶只能更新用戶名
• 將來我可以實現電子郵件、密碼和圖像上傳。

Qstash

為了增加產生 Itineray 的回應時間，我實作了一個佇列系統。

使用佇列處理所有非關鍵任務。

出現新問題

雖然產生行程後出現錯誤，但應該有一個回退機制。現在，如果資料庫中輸入資料有任何錯誤，則沒有後備機制，因此行程會遺失，需要修復。

目前我已停用 RLS 策略。將致力於此

未來的改進

---

問題：

旅行產生路線需要花費大量時間來產生行程。

它包含幾個過程：

• 接收使用者首選項並在資料庫中建立表格。
• 取得目前登入的使用者。
• 產生個人化提示並將其發送到 Gemini AI 模型。
• 接收回應，對其進行定制，將回應解析為 JSON，因為我將回應 JSON 直接儲存在資料庫中。
• 更新用戶已離開的積分。
• 發迴響應。

解決方案：

透過仔細分析該路線，我可以看出插入使用者首選項、插入回應和更新積分不是關鍵任務，而將回應傳送給使用者是主要的關鍵任務。

因此，我可以使用佇列非同步執行這些非關鍵任務。

這種非同步方法可以減少很多反應時間。

快取

實施快取機制可以顯著提高我們的旅行行程應用程式的效能和回應時間。透過快取經常存取的資料（例如熱門目的地或常見用戶偏好），我們可以減少伺服器的負載並為用戶提供更快的結果。這對於重複使用者或在產生更個人化的結果時顯示初始推薦特別有益。

我將為儀表板執行此操作，我將快取最近訪問的旅行行程，這將減少對資料庫的請求數量，最終使應用程式更快。

部署

對應用程式進行 Docker 化，以便在 AWS Elastic Container Service 上輕鬆部署，這是自動擴展的最佳方法。

目前它部署在 Vercel 上用於演示使用。