WordExpress 項目實驗將 GraphQL 引入 WordPress

2012 年，當 Facebook 開始將其 HTML5 驅動的移動應用程序重新架構為原生 iOS 或 Android 應用程序時，該公司發明了 GraphQL。 這種新的開源查詢語言被譽為 REST 的直接替代品。 GraphQL 提供了一種更有效的方式來支持每天在 Facebook 應用程序之間發生的大量交互，但它與數據庫無關，並且可以在 Facebook 之外使用。

儘管 GraphQL 仍然相對較新，但 Intuit、Coursera、Pinterest 和 Shopify 等大公司正在生產中使用它。 上個月 GitHub 宣布 GraphQL 支持其 GitHub API，以解決其 REST 架構的一些缺點。

GraphQL 提供了一種新的方式來構建從客戶端到服務器的通信，從而更高效地獲取數據。 Petr Bela 在他的文章 REST API 時代的 GraphQL 中總結了這兩種架構之間的區別：

GraphQL 的強大來自一個簡單的想法——不是在服務器上定義響應的結構，而是為客戶端提供了靈活性。 每個請求都指定了它想要返回的字段和關係，GraphQL 將為這個特定的請求構建一個定制的響應。 好處：只需要一次往返即可獲取所有可能跨越多個 REST 端點的複雜數據，同時只返回實際需要的數據，僅此而已。

上個月 Facebook 宣布 GraphQL 正在退出“技術預覽”階段，現在已經準備好生產。 它已經在許多不同的編程語言中實現，並且已經被希望以更有效的方式訪問數據的公司所採用。

WordExpress 將 GraphQL 引入 WordPress

Ramsay Lanier 是一名 JavaScript 前端開發人員，在華盛頓特區的 nclud 工作，他創建了一個基於 GraphQL 的 WordPress 實現，稱為 WordExpress。 Lanier 不喜歡 PHP，也不喜歡使用循環或模板，所有這些東西在歷史上都構成了 WordPress 前端開發的大部分內容。 他將 WordExpress 創建為一個 Node.js 應用程序，目的是用 JavaScript 替換 PHP，以實現 WordPress 的表現方面。 它在後端使用 Express，在前端使用 React 組件。 GraphQL 位於兩者之間，用於從 WordPress 數據庫中檢索數據。

“當我最初提出 WordExpress 的想法時，我想使用 REST API，但我發現現有的端點不是我想要的，”拉尼爾說。 “我最終不得不編寫一堆自定義端點並將調用鏈接在一起。 所以我想我應該試試 GraphQL。”

他發現 GraphQL 比 REST 更高效，因為它減少了到服務器的往返次數，讓開發人員可以專注於客戶端真正需要的數據。 Lanier 強調了與 WordPress 網站相關的好處：

使用 GraphQL，客戶端通過 GraphQL 查詢確定它需要的確切數據。 GraphQL 查詢有一個自定義解析函數，用於確定如何檢索數據。 在該功能中，您甚至可以訪問多個數據庫。 例如，對於 WordPress，您有一個 MySQL 數據庫，但您可能還有一個 Mongo 數據庫，用於存儲其他不需要的關係數據的應​​用程序。 在 GraphQL 解析功能中，您可以調用以從兩個數據庫中檢索數據，並在一次服務器往返中將其發送回客戶端。

當前形式的 WordExpress 是構建使用 WordPress 進行管理的 JavaScript 驅動的應用程序的良好起點。 Lanier 說，這種開發設置使他能夠比使用 PHP 模板更容易地創建網頁和應用程序的組件。

“使用 React，每個組件不僅包含顯示內容的標記，還包含該組件的樣式、它工作所需的數據以及任何交互邏輯——所有這些都在一個或兩個文件中，”他說。

WordExpress 的當前挑戰：插件兼容性和服務器端渲染

儘管更高效的查詢具有所有令人興奮的好處，並且可以使用 JavaScript 驅動的前端，但 WordExpress 項目仍面臨許多嚴峻的挑戰，除了簡單的博客安裝之外，它在生產環境中使用起來很麻煩。 它與絕大多數 WordPress 插件不兼容，因為大多數插件都是用 PHP 編寫的。

“基本上，我已經更換了整個前端，這意味著任何影響前端的插件都不會做任何事情，”拉尼爾說。 “但是，您當然可以利用影響管理方面的現有插件（例如高級自定義字段或 AWS S3 插件）。 任何操縱 WordPress 數據如何存儲在 MySQL 中的東西仍然可以使用——您只需要修改 GraphQL 模式和查詢即可使用它們。”

另一個主要挑戰是讓服務器端渲染工作，這是處理 SEO 和元標記等事情所必需的。 WordExpress 使用 Apollostack 來獲取數據並將其傳遞給 React 組件，它最近才添加了對自動服務器端渲染的早期支持。

“我已經從使用 Facebook 的 Relay 轉為使用 ApolloStack，”Lanier 說。 “兩者都是相當新的技術，我不確定是否真的想出瞭如何很好地處理服務器端渲染。 我已經有幾個月沒有研究過了，ApolloStack 的進展很快，所以他們現在可能已經想通了。”

目前，WordExpress 只是一個概念驗證，Lanier 表示他沒有計劃嘗試支持現有插件。 鑑於 WordExpress 目前無法利用主題和插件，這是 WordPress 生態系統中一些最好的部分，Lanier 說使用這個堆棧的開發人員可能更感興趣的是保留 WordPress 管理方面的力量。

“我喜歡 WordPress 管理員，”他說。 “它非常強大且易於使用來管理內容。 WordExpress 將成為任何想要僅使用 JavaScript 構建 WordPress 應用程序的 JavaScript 開發人員的起點。”

Lanier 使用 WordExpress 的目標是把它變成一個 npm 包，可以在各種不同的 React 項目中重用。 他已經發布了兩個協同工作的 WordExpress npm 包：wordexpress-schema（處理 GraphQL 模式和連接設置）和 wordexpress-components（目前包含前兩個組件，WordExpressPage 和 WordExpressMenu）。 由於該項目是基於 Node.js 構建的，因此開發人員可以使用他們想要的任何 npm 包，這是對有限插件兼容性的一種安慰。

GraphQL 和 WP REST API

許多預測 GraphQL 將直接替代 REST 的人也認為兩者可以共存。 事實上，Facebook 最近編寫了一個在 GraphQL 中包裝 REST API 的指南。

“如果 GraphQL 被證明是有效的，它很可能會與 REST API 共存，”Petr Bela 說。 “有些 API 將使用 REST，有些將使用 GraphQL。 有些人可能同時支持兩者。” 他預測，整個行業從 REST 完全切換到 GraphQL 需要數年，甚至可能需要十年時間。

Lanier 的 WordExpress 最近在 GitHub 上獲得了 1000 顆星，是目前唯一公開探索 GraphQL 驅動的 WordPress 實現的開源項目。 在 GitHub 上粗略搜索一下，發現許多其他人正在嘗試類似的設置。 幸運的是，GraphQL 不需要對 WordPress 核心進行任何更改，以使站點能夠使用 API 來查詢數據庫。

Lanier 表示，他感謝那些試圖將 WP REST API 合併到核心中的人所做的工作，並且不認為 GraphQL 的實現會對此構成威脅。

“我認為他們使用 REST API 所做的工作是件好事，”他說。 “他們絕對需要邁出這一步。 REST 已經存在很長時間了——GraphQL 仍然很新，所以走 REST 路線是有意義的。 此外，更多的人知道如何使用它。 GraphQL 的好處在於您可以使用它來包裝 REST API，因此它們可以共存。”

WordExpress 超越簡單概念驗證的可能性取決於社區的反饋。 拉尼爾說，開發人員通過分叉和提問來表現出對 WordExpress 的興趣。

“人們正在使用它，玩弄它並（希望）把它變成自己的，”他說。 “我認為興趣就在那裡。 但是，要使其真正可行，您需要整個開發團隊使其成為一流的選擇。”

Lanier 最近接受了一份新工作，他正在使用 100% 的 React，並且有一段時間沒有機會使用 WordPress，但他表示他願意探索合作以使 WordExpress 生產做好準備。

“如果人們真的很感興趣並想聚在一起將其發展成一個可行的解決方案，我會 100% 參與其中，”他說。

想要測試它並開始使用 WordExpress 進行開發的開發人員需要對 React 的工作原理有基本的了解。 Lanier 編寫了有關如何設置 GraphQL 實現以及如何擴展 GraphQL 查詢和數據庫模型的詳細文檔。 WordExpress.io 站點是代碼的實時演示，您可以在 GitHub 上找到該代碼。