TUS 架構的缺點:
- 最後的 GraphQL Mutation 無法被納入進度顯示:雖然這是 GraphQL 造成的,實際上也不算是太大的缺陷,但使用 TUS 上傳時的最後一步看起來會像是上傳卡住了。
- 要多一組 tusd 很不方便:若非使用 containerize 或類似的部署方式,tusd 本身的位置對雲端環境是稍微有點麻煩的,也需要擔心 network throttle 的問題。
@leemiyinghao: **TUS 架構的顯著優勢:** * **徹底解決斷點續傳問題:** TUS 從協定層面支援斷點續傳,即使面對不穩定的網路或大型檔案,也能提供無縫、可靠的上傳體驗,讓使用者可以從上次中斷的地方繼續上傳。 * **提升 Proxy 效能與可擴充性:** 當客戶端直接與 TUS 伺服器互動時,大型檔案的上傳流量不再經過主 GraphQL API 的代理,這能大幅減輕反向代理 (Reverse Proxy) 和 API Gateway 的負擔,避免因緩衝大型檔案而承受壓力。同時,TUS 伺服器可以獨立於 GraphQL 服務進行擴充,若檔案上傳需求大增,可專門擴充 TUS 服務叢集而不影響 GraphQL 服務效能。此外,TUS 服務可部署在更靠近使用者端點的地區,或利用專門為檔案上傳優化的基礎設施,從而提供更快的上傳速度。 * **降低 GraphQL 服務壓力與職責分離:** GraphQL 服務能專注於其核心職責——處理資料的查詢與變更。繁重的檔案 I/O 操作則交由專門的 TUS 服務高效處理,這種職責的分離使得 GraphQL 服務更加輕量、高效且更容易維護。 * **精細的進度回報:** 由於 TUS 採用分塊上傳機制,TUS 客戶端函式庫能提供精確的即時上傳進度資訊,大幅改善了大型檔案上傳過程中的使用者體驗。
TUS 架構的缺點:
用過 Go + gqlgen 和 Node.js + TypeORM,反而覺得 GraphQL 被捧的太高了。沒有解決問題,反而製造問題,例如:N+1 需要 Dataloader 處理、無法傳遞二進制…
Facebook 當初設計 GraphQL,是為了讓 Resolver 能從不同微服務整合資料,統一回傳給前端。但很多人把它當成 HTTP API 的替代方案使用,就像 JWT 被誤用為取代 Session 一樣。
開發速度遠不如一個 POST /upload_video API。但前端生態彷彿不用上新技術就會被淘汰。似乎懂得什麼該捨棄,比學會技術還難。
但我現在用 Go + HTMX 超快樂… 🫠