Hygraph (GraphCMS) 開發

為什麼 Hygraph 是不同類型的 Headless CMS

Hygraph — 前身為 GraphCMS — 是唯一從一開始就圍繞 GraphQL 構建的 headless CMS。這不是市場營銷噱頭。這意味著您的內容 API 具有原生類型、可以用精確的方式查詢，並且能夠將來自多個來源的內容聯合到單一統一 API 中。

自 GraphCMS 時代起，我們就在 Hygraph 上構建生產應用程式。我們了解它的優勢所在、哪些地方有粗糙邊界，以及如何架構能夠擴展且不會成為維護噩夢的內容模型。

Hygraph 值得選擇的原因

原生 GraphQL，而不是後加功能

大多數 headless CMS 平台優先提供 REST API，GraphQL 是後來才加上的功能。Hygraph 則相反。每個內容類型、每個關係、每個資產都會自動生成完全類型化的 GraphQL 架構。您可以精確查詢需要的欄位 — 沒有過度提取、沒有不足提取、沒有需要鏈接多個 API 呼叫。

這對效能很重要。單個 Hygraph 查詢可以在一次往返中解析嵌套內容、本地化變體和相關條目。嘗試用基於 REST 的 CMS 做到這一點，頁面載入前您就會耗盡速率限制。

內容聯合

Hygraph 的 Remote Sources 功能讓您能夠從外部 REST 和 GraphQL API 中提取資料，並將其視為原生內容。來自 Shopify 的產品資料、來自您後端的用戶檔案、來自 Stripe 的定價 — 所有內容都可以通過一個統一的 GraphQL 端點存取。

我們大量使用此功能來構建應用程式，其中內容編輯者在 Hygraph 中工作，而前端從多個資料來源提取，無需了解或關心資料來自何處。

細粒度權限和工作流程

Hygraph 配備了基於階段的內容工作流程（草稿 → 審核 → 已發佈）和實際適用於企業團隊的基於角色的存取控制。內容編輯者看到他們需要的東西。開發者可以鎖定架構變更。審核者可以批准而不影響生產環境。

我們的 Hygraph 開發方法

不會損壞的內容建模

任何 CMS 專案中最關鍵的決定發生在編寫第一行前端程式碼之前：內容模型。如果這個地方出錯，六個月後您就會進行重構。

我們使用以下原則設計 Hygraph 架構：

• 元件驅動模型 — 內容類型直接映射到前端元件。編輯者從模組化區塊組裝頁面，而不是整體頁面類型。
• 關係架構 — 我們提前計劃一對多、多對多和多態關係。Hygraph 的聯合類型讓我們可以創建靈活的內容結構，無需求助於通用的「包羅萬象」欄位。
• 從一開始就支持本地化 — Hygraph 支持欄位級本地化。我們在初始架構設計期間配置此功能，而不是作為事後補救。
• 列舉欄位而非自由文本 — 在可能的情況下，我們將輸入限制為列舉。這可以防止資料品質問題，並使篩選更可預測。

前端整合

我們主要使用 Next.js 和 Astro 構建由 Hygraph 驅動的前端。以下是典型的情況：

Next.js + Hygraph： 我們使用 Next.js App Router 搭配伺服器元件在構建時或請求時查詢 Hygraph。GraphQL 查詢在伺服器端執行，因此您的 API 令牌永遠不會到達瀏覽器。我們使用 Hygraph webhooks 實現 ISR（增量靜態再生成）以在內容更改時重新驗證特定頁面 — 無需完整重建。

Astro + Hygraph： 對於互動性最少的內容豐富網站，Astro 的靜態優先方法與 Hygraph 結合可提供卓越效能。我們在 .astro 文件中編寫 GraphQL 查詢，預設不提供 JavaScript，並且僅在需要時為互動式島嶼進行水合。

在兩種情況下，我們使用 GraphQL Code Generator 從 Hygraph 的 GraphQL 架構生成 TypeScript 類型。每個查詢都是類型安全的。每個元件都准確了解預期的資料形狀。

Webhook 驅動的工作流程

Hygraph webhook 在內容生命週期事件時觸發 — 建立、更新、發佈、取消發佈、刪除。我們將這些集成到：

• Next.js 中的隨需 ISR，可在無需完整部署的情況下立即更新內容
• 內容更改時 Algolia 或 Meilisearch 中的搜索索引更新
• 通過 Slack 或電子郵件進行編輯工作流程的通知管道
• 全球分佈網站 CDN 層的快取失效

預覽和草稿模式

編輯者需要在發佈前看到未發佈的內容。我們使用 Hygraph 的草稿階段實現 Next.js 草稿模式或 Astro 的伺服器渲染預覽路由。內容編輯者在 Hygraph 中點擊預覽連結，看到他們的變更在實際前端上呈現，並有可見的「預覽」橫幅，以便確實了解什麼是實時的。

與我們合作您將獲得的內容

探索和架構設計

我們審查您的內容需求、繪製內容類型和關係的地圖，並設計一個針對編輯功能性和查詢效能進行最佳化的 Hygraph 架構。在開發開始前，您將獲得一份記錄完善的內容模型。

前端構建

Next.js 或 Astro 中的生產就緒前端，與 Hygraph 完全整合。類型安全的 GraphQL 查詢、通過 Hygraph 的資產管道進行最佳化的影像處理，以及使用您的設計系統構建的響應式佈局。

編輯體驗設定

自訂側邊欄小工具、配置的階段和權限、預覽環境和記錄的編輯工作流程。您的內容團隊獲得一個按他們的想法工作的 CMS，而不是按開發人員的想法。

效能最佳化

我們實現查詢批處理、支援的持久化查詢、CDN 快取策略，以及通過 Hygraph 的內置轉換和 next/image 或 Astro 的影像元件進行的影像最佳化。Core Web Vitals 不是事後想法 — 這是我們圍繞設計的約束。

部署和基礎結構

我們部署到 Vercel、Netlify 或 Cloudflare Pages，具有執行類型檢查的 CI/CD 管道、針對 Hygraph 架構的 GraphQL 查詢 Lint，並防止破壞性變更到達生產環境。

何時 Hygraph 是正確選擇

Hygraph 最適用於以下情況：

• 您的團隊已經用 GraphQL 思考或想要如此
• 您需要從多個外部來源聯合內容
• 多語言內容是核心需求，而不是錦上添花
• 您想要具有基於階段發佈的細粒度編輯工作流程
• 您的前端是使用能夠有效使用 GraphQL 的現代框架構建的

它對簡單部落格或偏好 REST 簡單性的網站不太理想。我們會提前告訴您這一點，如果替代方案更適合，我們會建議替代方案。

我們 Hygraph 構建背後的技術

每個專案都不同，但我們的 Hygraph 堆棧通常在前端包含 Next.js 或 Astro、用於類型安全的 GraphQL Code Generator、用於託管的 Vercel 或 Netlify，以及當專案需要時用於單個儲存庫管理的 Turborepo 等工具。我們使用 urql 或 graphql-request 作為輕量級 GraphQL 客戶端 — Apollo 對大多數 CMS 驅動前端來說太過度了。

我們已交付 Hygraph 專案用於行銷網站、文件平台、多品牌內容中樞和電商店面。這些模式已被證實。工具已成熟。而且編輯體驗始終是我們從客戶獲得的最佳回饋。