GraphQL 不是萬靈丹，但擁抱 GraphQL 還是為 Mosir 帶來不少好處（例如 codegen 完整的 typing system、request batching）
但要快的話絕對不會沒事選 GraphQL 折磨自己，後面的 overhead 太大了（但我大概也不會選 FastAPI 就是了）
然後 HTMX⋯⋯很棒，但我想要的東西他辦不到 XD
@yamiodymel: 用過 Go + gqlgen 和 Node.js + TypeORM，反而覺得 GraphQL 被捧的太高了。沒有解決問題，反而製造問題，例如：N+1 需要 Dataloader 處理、無法傳遞二進制… Facebook 當初設計 GraphQL，是為了讓 Resolver 能從不同微服務整合資料，統一回傳給前端。但很多人把它當成 HTTP API 的替代方案使用，就像 JWT 被誤用為取代 Session 一樣。 開發速度遠不如一個 POST /upload_video API。但前端生態彷彿不用上新技術就會被淘汰。似乎懂得什麼該捨棄，比學會技術還難。 但我現在用 Go + HTMX 超快樂… 🫠
相關留言
噢對了，其實我個人的感受是 GraphQL 不只是 microservice 架構好用，在 modular-mono 也有一定優勢。以 mosir 的文章為例，post 跟 profile 完全是兩個不同的 module、提供不同服務。resolver（實際上是 gqlgen force resolver）依照需求把需要的 profile 放進 post，而不用在 post 跟 profile 本身塞不必要的相依性，也不需要讓 client 分兩次 request 才拿到需要的資料。
這種在大型專案的相依性解耦跟權責分離才是我們選擇 GraphQL 所帶來的好處，在專案越來越龐大的狀況下還是可以維持一定的程式碼整潔跟開發速度。
GraphQL 的核心設計理念圍繞著結構化資料的查詢與變更 (query and mutation)。它的請求和回應都是基於 JSON 這類的文字格式。傳統上，GraphQL 請求透過 HTTP POST 方法，將一個 JSON 物件作為請求主體 (request body) 發送到伺服器。這個 JSON 物件包含了查詢字串 (query string)、變數 (variables) 和操作名稱 (operation name)。
然而，檔案，特別是二進位檔案，本質上並非 JSON 這類結構化的文字資料。直接將二進位檔案嵌入 JSON 中，不僅會造成龐大的效能開銷（舉例來說，將檔案編碼成 Base64 字串會額外增加約 33% 的資料量），而且對伺服器的解析與處理也極為不便。
因此，GraphQL 規範本身並沒有提供直接處理檔案上傳的內建機制。開發者通常需要仰賴現有的 HTTP 機制或其他協定，來補足這方面的功能。