GraphQL - 漸進式導入的架構
GraphQL 出來幾年熱度依然不減，從今年數場演講與文章中，看得出越來越成熟的趨勢，筆者有在 Side Project 先試用看看覺得挺不錯的，直到近期公司新專案總算開始準備導入 GraphQL，這篇文章主要整理了置底 Reference 段落列出的內容，來看看 GraphQL 可能有哪些架構方法，建議有時間可以自行詳讀一遍。 雖然說是新專案，仍然是建立在 Legacy System 之上，會使用到舊有的 REST API，因此需要分別從 Client Side 與 Server Side 的角度來探討，怎麼樣的架構適合漸進式的導入 GraphQL。 Client Side REST vs. GraphQL moves data requirements to the client side. ( Image credit , Image credit ) 不免俗套先從 REST 的缺點來探討，現階段我們維運三年前開發的 MCS ( MediaTek Cloud Sandbox ) 中是全面採用 REST 的架構，要瀏覽 Detail 頁面至少打 7 支 Resource API，可以想像頁面的負擔相當大，在上圖 GraphQL 的設計理念中，透過將 Data Requirements 往前端搬移，讓頁面所需的資訊盡量能在一個 Request 內完成，來優化網路的傳輸問題。 Apollo Client 2.0 前端今年最熱門的狀態管理肯定非 Redux 莫屬，一旦要轉換為 GraphQL 的架構，可以挑選由 GraphQL 為出發點設計的 Relay 或 Apollo 框架，筆者比較偏好社群活躍度高的 Apollo Client 2.0，社群導向也相較有趣很多，另外 Apollo 背後用 Observable 實作相當不錯。 a. REST + GraphQL Hybrid 如果我們直接建立一個新的 GraphQL Server，會造成前端維護的困難，因為要同時處理 REST 與 GraphQL 的結構。為了提供彈性的調整空間，Apollo Client 2.0 抽象出的 Apollo Link 可以解決此類問題，其中 Apo...