按此：WPGraphQL 和 Faust.js

歡迎來到 Press This，WMR 的 WordPress 社區播客。 每集都有來自社區各地的嘉賓和 WordPress 開發人員面臨的最大問題的討論。 以下是原始錄音的轉錄。

由 RedCircle 提供技術支持

Doc Pop ：您正在收聽 Press This，WMR 上的 WordPress 社區播客。 每週我們都會聚焦 WordPress 社區的成員。 我是你的主人，Doc Pop。 我通過我在 WP Engine 的角色以及我在 TorqueMag.Io 上的貢獻來支持 WordPress 社區，在那裡我可以做播客、畫卡通和教程視頻。 檢查出。

您可以在 Red Circle、iTunes、Spotify 上訂閱 Press This，也可以直接從 wmr.fm 下載劇集。

在 Press This 的這一集中，我們談論的是 Headless WordPress、GraphQL 和 Faust.js。 如何將這些工具一起使用以及與 Headless WordPress 相關的成本類型。 我們將嘗試深入研究這個問題，今天有兩位偉大的客人加入我的行列，我有 Jason Bahl，他是位於科羅拉多州丹佛市的 WP Engine 的首席軟件工程師，他在那里維護 WPGraphQL . 我們有 Chris Weigman，他是 Faust.js 的工程經理。 我通常喜歡在開始這些節目時向客人詢問他們的 WordPress 起源故事，但我想我會在這裡稍微改變一下。

Jason，你能告訴我們什麼是 WPgraphQL 以及它的 wordPress 起源故事嗎？

Jason Bahl：哦，是的，WPGraphQL 是一個免費的開源 WordPress 插件，它將 GraphQL API 帶到您的 WordPress 站點，而 GraphQL 是圖形查詢語言。 因此，它允許開發人員使用圖形查詢語言從 WordPress 中獲取內容。

這個插件起源於幾年前我在一家報紙工作，我們做了很多內容聯合。 我們有一個大約由 54 個站點組成的網絡，遍布美國各地，我們需要將內容從一側移動到另一側。 你知道，當一篇新聞報導發表時，不同的報紙可以訂閱其他報紙的內容。

因此，當各種事件發生時，我們需要在該網絡中移動數據，我們使用 WordPress REST API 來完成大量數據移動。 並且在技術上遇到了一些問題，比如技術上的實際性能，還有開發人員的體驗。 我發現了 GraphQL，這是真正的圖形查詢語言，它於 2015 年由 Facebook 開源。

所以我找到了這項技術，做了一些原型設計，將它推銷給我的同事，然後我們將我們的聯繫人聯合組織從 REST 遷移到 GraphQL。 然後我繼續將這個項目作為一個社區項目進行工作，我知道 JavaScript 框架正在成為熱門事物，並且這可能是使用 GraphQL 的主要用例，就像服務器到服務器通信不是主要用例一樣。 它解決了我們的需求，但我看到了更大的願景，所以我一直致力於將其作為社區的開源項目。

DP：嗯，很酷。 克里斯，你能告訴我們一個類似的故事嗎，關於浮士德是什麼以及它是如何產生的？

Chris Weigman： Sure Faust，最近，實際上是本週，正式向公眾發布，重新發佈到使用 GraphQL 構建 Headless WordPress 網站的公共框架。 2020 年就開始開發了，算是 WP Engine 的一個非官方項目，這是第三個主要支點。

他們把它作為 DevRel 的擴展開始，開始使它更正式一點，並轉向一種叫做 GQty 的東西和一種非常 JavaScript，開發人員第一的心態。 然後當我在去年 12 月 1 日接管團隊時，我們意識到那不是我們的目標市場。

我們應該一直在為 WordPress 開發人員開發。 所以我們又開始重建它，最近才終於能夠重新發布。

DP：傑森，你最近在推特上說你已經在 Faust.js 上推出了新的 wpgraphql.com。 以前的站點，我相信是無頭的 WordPress。 你能告訴我們你所做的這個改變嗎？你知道，你說的是什麼改進？

JB：是的。 所以 wpgraphql.com，它多年來一直是一個無頭網站。 所以我正在使用多個數據源。 所以我有很多內容在 WordPress 中，像博客文章都在 WordPress 中。

一些文檔也存在於 WordPress 中。 然後一些文檔存在於 GitHub 存儲庫的降價文件中。 在我使用 Gatsby 的最長時間裡，大概三年，我一直在使用 Gatsby，它是一個 JavaScript 框架，其核心具有數據層，您可以在其中從多個來源提取數據。

所以我正在使用它，它會從 GitHub 中提取數據，也使用 WPGraphQL 從 WordPress 中提取數據，並允許我使用該數據來構建我的模板。 所以我用了幾年。 我想擺脫的數據層有很多痛點。

所以我想使用 Faust 構建的 Next。 它是另一個 JavaScript 框架，但我猜有很多遺漏的部分。 接下來，許多 JavaScript 框架都認為您的前端框架應該定義所有路由，對嗎？ 但如果您使用的是 CMS，則您的 CMS 會定義路由。

所以有很多技術問題讓這些東西發揮得很好，就像你的前端對某事有意見而你的後端有不同的意見。 所以就像我試圖解決的一個問題是讓我的前端識別一個特定的 URL 是一個特定類型的東西，然後呈現一個代表那個東西的模板。

就像博客文章與文檔或用戶檔案或其他任何東西具有不同的模板一樣。 所以我希望我的前端能夠將 URL 發送到 CMS，取回數據，但了解要返回的模板。 在 WordPress 中，它稱為模板層次結構。 所以當 Faust 團隊能夠解決這個問題時，我想，哎呀，我要轉向 Faust。

所以，是的，我能夠採用核心 WordPress 中存在的一些概念，例如 PHP 主題並在無頭中使用它們，這樣我就可以利用 React 的好處以及我想在前端使用的任何 JavaScript 來模板化我的網站，但仍然是 WordPress 世界中熟悉的概念。

DP：克里斯，你提到浮士德經歷了一些變化。 這些變化是什麼？ 你知道，傑森提到了他們。 使這種改進成為可能的改變有哪些？

CW：它始終專注於 WPGraphQL。 真正的問題是其他一切。 例如，Faust 的最後一個主要版本在底層使用了一個名為 GQty 的庫與 GraphQL 進行交互，這在紙面上聽起來非常酷。 當時 Faust 團隊的想法是，讓我們抽像一下，人們不需要知道如何構建這些複雜的查詢。

這個框架應該為你抽像出來。 在紙面上看起來非常好，實際上是因為 WordPress 數據的所有復雜性。 即使是單一的帖子類型也可以有如此多的變化。 也許您將其與類別混合在一起，也許是所有不同的東西。 GQty 只是無法通過它。

最重要的是，當它使用 GQty 版本構建時，確實沒有註意到 Jason 所說的路由問題。 誰處理路由？ WordPress 希望根據內容來處理其路由，它是一個內容管理系統，因此所有路由和 WordPress 主要基於內容。

Next.js 是一個前端框架，所以所有的路由都是基於它的，這是一個完全不同的路由如何基於的範例。 Next 上的 /Blog 可能與博客內容無關。 它將轉到一組模板。 它將成為可以構建博客的應用程序的一部分。

而 WordPress 上的 /Blog 很可能意味著這些都是博客文章。 在構建時的範例，如果你想讓 WordPress 成為一個非常可靠的前端或無頭的 CMS，我們必須處理該路由。 我們做這個的另一個轉變，就像我在 GQty 版本中所說的那樣，我們的目標是必須使用 WordPress 的 JavaScript 開發人員，這看起來很崇高，直到你意識到這是 WP Engine。

我們正在與多年來建立在 WordPress 上的機構打交道，他們現在出於我們稍後可以討論的各種原因，正在轉向無頭的事情。 他們知道如何進行 WordPress 開發。 他們了解 WordPress 模板路由的工作原理和模板的工作原理，諸如此類。

我們需要推進這些功能，以便 WordPress 開發人員可以更輕鬆地使用 GraphQL。 這就是浮士德的目標。 模板層次結構，只是簡單地重建了 WordPress 所做的。 現在，如果您想使用 Next 的路由，可以通過多種方法在應用程序中覆蓋它，這樣您就不會丟失任何東西。

但是對於那些將 WordPress 用作真正的內容管理系統，能夠通過內容管理來路由內容的人來說，Faust 會為您處理得更好嗎？ 那有意義嗎？

DP ：是的。 絕對地。 你知道的，我認為這是一個快速休息的好地方。 您正在收聽 Press This，這是一個由 Chris Weigman 和 Jason Bahl 主持的 WordPress 社區播客。 我們會回來談論 WordPress 和 headless。 敬請關注。

DP：我們帶著 Press This 回來了。 你知道，克里斯，就在那次休息之前你提到了一些事情，你提到越來越多的公司陷入無頭狀態，我知道 WP Engine 已經做了很多研究表明情況確實如此。 我有點想知道，headless 肯定有某種聲譽，我認為是企業，當我認為 headless 時，我的想法是否正確。 那是無頭的嗎？ 它只是企業的工具還是更多站點將要使用的工具？

CW：是的，也不是。 基本上是無頭的，尤其是現在使用 WordPress，其中涉及的複雜性意味著您可能有一個完整的團隊來構建您需要的東西。

這不是開箱即用的 WordPress，您只是想要您的個人博客。 它可以做到這一點，但到目前為止，為了能夠做到這一點，它需要更重的提升。 與 Contentful 相同，與所有這些其他 CMS 相同。 如果你只是想要一些簡單的東西，一些你知道的，已經在網絡上出現多年的內容類型，headless 可能比你想處理的要多得多。

是嚴格意義上的企業嗎？ 看，不。 蓋茨比多年來一直致力於解決這個問題。 稍後您還有另一個播客，Doc with Mastodon。 這是一個我已經參與多年的社區。 大多數人都在使用無頭 CMS 的變體，尤其是 Gatsby，但還有 Hugo。 在非常基層的層面上有各種不同的技術。

因此，您最終會遇到基層用戶，而最終會遇到大型網站的企業用戶，而 WordPress 傳統上似乎屬於介於兩者之間的其他人。 它是那些不想像 Gatsby 用戶那樣處理 markdown 文件和代碼的人，或者你知道，無論如何只是開箱即用的 Gatsby。

但它也不是一個擁有整個 10 人團隊來建立個人品牌或個人博客的人。 這將 WordPress 從中間地帶出來，很容易將其擴展到兩端。 現在你可以輕鬆地在 GraphQL 之間構建，你擁有所有數據，並且你有一套不斷增長的方法來處理這些數據。

Faust 使利用它變得更加容易，並且您可以在一天而不是一個月內構建一些東西。

DP： Jason，Chris 提到了一些我想听聽你的想法，我聽說這對小團隊、像我這樣的小博主來說可能不太好，這顯然是有道理的，我不需要無頭的 WordPress，但是喜歡，我想我想知道的是，無頭 WordPress 是否會花費我更多的錢，因為我將不得不擁有一個 iOS 開發人員和一個 WordPress 開發人員？ 是更貴還是更具成本效益？

JB：我想可能取決於你製作的是什麼。 如果你正在做，就像你提到的 iOS，如果你正在做一個本地移動應用程序，我的意思是顯然無論如何都會有相關的成本，如果你使用來自 WordPress 的數據，那麼這並不是一個好的方法，其他而不是無頭地做，因為你知道，本機應用程序不呈現 php，所以你必須無頭地做。

但就目前而言，如果您正在使用傳統 WordPress 構建網絡，您可以找到一個主題，您知道一個免費主題或在市場上找到一個主題，下載並安裝它，然後您去比賽。 大多數人都會以某種方式對其進行自定義。

所以你通常會有開發成本，無論是你自己還是其他人。 無頭 WordPress 與傳統 PHP 主題的不同之處之一是，例如，當我啟動新的 wpgraphql.com 時，我能夠使用為我的 Gatsby 網站提供支持的同一 WordPress 實例。

我正在獲取數據，數據正在輸出並進入 Gatsby 站點，我能夠繼續在 CMS 中發佈內容，同時為其開發我的下一個前端。 在傳統的 WordPress 開發中，您通常必須將您的網站遷移到類似暫存環境中。

在該環境中激活一個新主題，在那裡構建您的主題，處理某種內容凍結期，您告訴您的內容創建者，“嘿，今天您不能發佈內容，因為我們要遷移，然後我們”我們將設置新的 WordPress 實例，實時實例。” 然後你必須在那裡登錄並開始正確處理你的內容。

無頭 WordPress，我能夠在完全不同的前端堆棧上重建我的站點，而不會破壞我實際 WordPress 實例中的任何內容，這是數據和表示的分離，對嗎？ 所以我可以去，如果我明天想探索下一個熱門技術，就像我可以把目光放在 Svelte 而不是 Next 上一樣，我就不必改變 WordPress 中的任何東西。

所以在某些情況下，它實際上可能更便宜，因為啟動另一台服務器的整個過程，讓您的團隊停止編寫內容，然後轉移到另一個 WordPress 實例，然後開始在那裡發布，進行增量遷移，諸如此類，這也是有代價的。

另一件也很有趣的事情是 JavaScript 生態系統確實正在交付。 在我看來，無頭技術的共同驅動力之一是基於組件的架構。 還有，React 和 VUE 生態系統中的各種組件庫，它們允許您跨項目重用組件。

因此，機構可以構建他們在項目中使用的通用組件，他們可以在一個中心位置更新這些組件，然後將它們安裝到多個項目中。 使用 WordPress，這並不那麼容易，因為您的 PHP 模板部分和 WordPress 通常與它們所屬的項目緊密結合。

在無外設的情況下，您可以擁有一個包含這些組件的 MPM 包，並且多個項目可以更新該包並以更少的努力同時受益。 所以我認為目前，我想說可能成本更高，工作量更大，但我認為像 Faust 這樣直到最近才出現的工具正在降低構建無頭所需的總體工作量。

而且我認為在不久的將來，構建無頭系統可能比不構建無頭系統更便宜。

DP： Chris，關於無頭 WordPress 的成本，您有什麼想補充的嗎？

CW：我認為傑森真的一語中的。

這是我喜歡 WPGraphQL 的一件事是我的團隊接下來正在用我們所說的擴展 WordPress 的方向，我們的工作名稱是 React Gutenberg Bridge，但這在 WordPress 中也是一個問題。 你如何重用這些組件？ 我不想使用“只是組件”這個詞，因為它在 WordPress 端的應用與在 JavaScript 端的應用不同，對吧？

但是我們如何跨項目重用代碼，無頭或 WordPress 的其他方式，而無頭確實可以做到這一點。 但我認為可以肯定地說，普通博主只是想發布他們的美食博客，他們自己可能不會處理這個問題。 這在很大程度上是一個代理問題。 是不是成本更高？

也許，也許不是，但這就是當我們談論成本在哪裡時變得複雜的地方？ 因為它是您想要使用數據的不同類型。

DP：是的，絕對。 你知道，來自報紙背景，在雙子城和納什維爾的周刊工作，傑森，我可以想像告訴你的 56 家報紙一天不出版會是什麼感覺。

今天沒有消息，因為我們正在更新網站。

JB：是的。 我的意思是，我們確實經歷過那些時期，對吧？ 就像我在那裡受僱時一樣，他們不在 WordPress 上，所以我工作的一部分是將他們從另一個系統轉移到 WordPress。 所以肯定有幾天，好吧，它會在 WordPress 日上線。 停止你正在做的事。 正確的。

所以肯定有這樣的時期，或者我們也必須處理這樣的問題，好吧，他們在舊系統上發佈到昨晚午夜，但我們在兩天前準備好了 WordPress。 所以現在我們必須像 Delta 遷移那樣做，並確保所有數據仍然同步，這樣，你知道，這些過程肯定會產生技術和人力成本。

DP：是的。 而且我認為還有很多，當您仍在使用 WordPress 時，您仍然可以獲得可以節省成本的生態系統。 您不必構建 SEO 工具。

您可以使用 Yoast SEO 插件或其他任何東西。 即使你是一個 Headless 站點，我假設大多數插件仍然可以工作，只要它們不是前置的。

JB：是的。 這其實是一件很有趣的事情。 所以新的浮士德本身就是用插件架構構建的。 所以開箱即用，它會附帶一個客戶端，它使用 Apollo 客戶端，這樣你就可以從 WPGraphQL 獲取數據，你可以獲取你的 WordPress 數據，但是你可以創建插件，這樣，假設你做了，就像你一樣提到，在您的 WordPress 網站上安裝 Yoast SEO。

您可以添加 Yoast 插件。 它還不存在，但很快就會存在。 您可以在前端為 Faust 添加一個 Yoast 插件，它知道如何處理該數據，對吧？ 所以會有人的能力，有些我們可能會生產和支持，但有些，社區也可以生產和支持 Faust 方面的插件，這樣你只需要一行代碼，就可以添加這個插件為您的無頭前端獲取 Yoast 等功能。

這是我不認為任何其他無頭前端真正具有 Faust 正在接近它的相同概念的東西。 所以我認為插件，我認為它是 WordPress 開發人員熟悉的另一件事。 它從 WordPress 中引入了熟悉的概念，但將其與現代 JavaScript 前端堆棧聯繫起來。

DP：那是 Press This 最後休息的好地方，當我們回來時，我們將結束與 Chris Weigman 和 Jason Bahl 的談話。 敬請關注。

DP：您正在收聽 Press This，一個 WordPress 社區播客。 我是你的主人，Doc Pop。 今天我們談論的是 WPGraphQL、Faust，以及如何為您的無頭 WordPress 網站提供動力。 就在休息之前，我們正在談論 Faust 和插件，我只是想向大家拋出一些隨機問題，看看這裡是否有好的答案。

但是克里斯，我有點想知道 Faust 是否有任何潛力，我知道它是一個無頭平台，但是否有任何潛力，比如 WordPress Faust 主題，至少讓你設置類似，這是您需要的插件，這裡是開箱即用的所有插件。

CW：當然。 事實上，我們已經擁有了。 我們將其稱為藍圖，因為它與 Local 密切相關。 在像 WP Engine 這樣的平台上發布之前，大多數人都會對這些東西進行一些調整。 所以我們藉用了Local的名字Blueprints。

對於新的浮士德，我們有一個叫做 Portfolio 的，它基本上是一個完整的投資組合主題，我們正在研究一個非常空白的腳手架，供機構使用。 一旦你掌握了竅門，你可能會想自己定制一切。 因此，腳手架將是項目最佳實踐，將其旋轉起來，然後您就可以用它來做您自己的所有事情。

長期以來，我們一直在大量討論無頭主題商店，ala Blueprints。 我們沒有人力，所以這還有一段路要走，但這絕對是我們正在考慮的事情，我們希望看到發生。

DP：是的，想想這很酷。 這是一個完全不同的生態系統。

你知道的，Jason，我之前採訪過你，我確信這個問題一直出現，但每次我聽到 WPGraphQL，我都在想這聽起來很像 REST API 所做的。 實際上，這聽起來比 REST API 的功能強大得多，而且 REST API 是核心的一部分，我只是想知道，您認為 WPGraphQL 應該成為 WordPress 核心的一部分嗎？

JB：也許有一天。 我認為我們還沒有。 當東西在 WordPress 核心中合併時，可能除了 Gutenberg 之外，創新就會停止。 例如，REST API 仍然有一個我向人們指出的錯誤，我認為從 2016 年起它仍然存在。所以我的意思是，當內容進入核心時，您將添加一個功能集到 40% 的網絡和所以必須以更慢的速度進行更改，如果它是一個插件，你可以讓人們選擇他們想要選擇的版本，你可以更快地迭代，因為他們可以選擇最適合他們項目的版本。

在 core 中，如果您更新 core 並且它包含重大更改，您可能剛剛破壞了 40% 的網絡。 所以 GraphQL 是一個規範，它也與 WordPress 無關。

正確的。 因此 GraphQL 規範仍在不斷發展。 隨著它的不斷發展，我們希望跟上最新最好的 GraphQL 規範。 如果我們今天將 WPGraphQL 合併到 Core 中，並且 GraphQL 不斷發展，WordPress 將停留在 GraphQL 的 2022 版本，而世界其他地區則使用 2030 版本或其他版本。 對我來說，我認為在某些時候讓它像 WPCLI 一樣被認可是做 X 事情的官方方式可能是有意義的。

就像您可以為 WordPress 構建您自己的 CLI 客戶端一樣，但社區承認 WPCLI 是官方的東西。 它不是 WordPress 核心的一部分，但它被 WordPress 基金會和大多數 WordPress 社區認可為官方的東西。 因此，在某些時候，像這樣識別 WPGraphQL 可能會很好，就像如果你打算做無頭 WordPress，就這樣做。

它仍然是一個插件。 這就是我的想法。 可能有一段時間 GraphQL 感覺很完美，它並沒有真正被迭代，也許那個時候我們會考慮它。 但此時 GraphQL 規範出現了一些問題，這將導致 API 發生重大變化。

所以把它作為一個插件對我來說仍然有意義。

DP：馬上。 是的，你提到過 WPCLI，但我一直忘記，就像他們只是覺得它是核心的一部分。 無論感覺如何，都像官方一樣。 所以是的，就像，哦，是的，這就像這個獨立的東西，就像 WPGraphQL 目前一樣。

這是一個很好的類比。 所以我要，我要在這裡結束。 和你們兩個聊天真的很棒。 如果聽眾有興趣關注你們中的任何一個，您可以關注@JasonBahl 和@ChrisWeigman。 如果可以的話，我們會將 Twitter 句柄放在節目描述中。 您一直在收聽 WMR 上的 WordPress 社區播客 Press This。

在下週的節目中，Automatic 的產品聯絡人 Anne McCarthy 將討論網站編輯和 6.1 的變化以及 6.2 的新內容。 再次感謝收聽 Press This。

你可以在 Twitter @thetorquemag 上關注我在 Torque 雜誌上的冒險經歷，或者你可以去 torquemag.io，我們每天都會在這裡提供教程、視頻和採訪。 因此，請查看 torquemag.io 或在 Twitter 上關注我們。 您可以在 Red Circle、iTunes、Spotify 上訂閱 Press This，也可以每週直接在 wmr.fm 上下載。 我是你的主持人 Doctor Popular 我通過我在 WP Engine 的角色支持 WordPress 社區。 我喜歡每週都在 Press This 上關注社區成員。