GraphQLをWordPressに導入するWordExpressプロジェクトの実験

公開: 2016-10-07

GraphQLロゴ

2012年、FacebookがHTML5駆動のモバイルアプリケーションをネイティブiOSまたはAndroidアプリに再構築し始めたとき、同社はGraphQLを発明しました。この新しいオープンソースクエリ言語は、RESTの直接の代替として知られています。 GraphQLは、Facebookのアプリ全体で毎日行われる対話の量をサポートするためのより効率的な方法を提供しますが、データベースに依存せず、Facebook以外でも使用できるように構築されています。

GraphQLはまだ比較的新しいものですが、Intuit、Coursera、Pinterest、Shopifyなどの大企業が本番環境で使用しています。先月、GitHubはGitHub APIのGraphQLサポートを発表し、RESTアーキテクチャのいくつかの欠点に答えました。

GraphQLは、クライアントからサーバーへの通信を構造化する新しい方法を提供し、データのフェッチをより効率的にします。彼の記事「RESTAPIの時代のGraphQL」で、PetrBelaは2つのタイプのアーキテクチャーの違いを要約しています。

GraphQLの力は、サーバー上の応答の構造を定義する代わりに、クライアントに柔軟性を与えるという単純なアイデアから生まれます。各リクエストは、取得したいフィールドと関係を指定し、GraphQLはこの特定のリクエストに合わせたレスポンスを構築します。利点：複数のRESTエンドポイントにまたがる可能性のあるすべての複雑なデータをフェッチするために必要なラウンドトリップは1回だけであり、同時に実際に必要なデータのみを返し、それ以上は返しません。

Facebookは先月、GraphQLが「テクニカルプレビュー」段階を終了し、現在本番環境に対応していることを発表しました。これは多くの異なるプログラミング言語で実装されており、データにアクセスするためのより効率的な方法を望んでいる企業によってすでに採用されています。

WordExpressはGraphQLをWordPressにもたらします

ワシントンDCのncludで働くJavaScriptフロントエンド開発者のRamsayLanierは、WordExpressと呼ばれるGraphQLを利用したWordPress実装を作成しました。 LanierはPHPのファンではなく、WordPressフロントエンド開発の大部分を歴史的に構成してきたすべてのものであるループやテンプレートを操作するのが好きではありません。彼は、WordPressのプレゼンテーション側でPHPをJavaScriptに置き換えることを目的として、Node.jsアプリケーションとしてWordExpressを作成しました。バックエンドでExpressを使用し、フロントエンドでReactコンポーネントを使用します。 GraphQLは、WordPressデータベースからデータを取得するために2つの間に位置します。

「最初にWordExpressのアイデアを始めたとき、REST APIを使用したかったのですが、既存のエンドポイントが私が望んでいたものではないことがわかりました」とLanier氏は述べています。「結局、一連のカスタムエンドポイントとチェーン呼び出しを一緒に作成する必要がありました。だから、GraphQLを試してみようと思いました。」

彼は、GraphQLがRESTよりも効率的であることを発見しました。これは、サーバーへのラウンドトリップを減らし、開発者がクライアントが実際に必要とするデータに集中できるようにするためです。 Lanierは、WordPressサイトに関連するメリットを強調しました。

GraphQLを使用すると、クライアントはGraphQLクエリを介して必要な正確なデータを決定します。 GraphQLクエリには、そのデータの取得方法を決定するカスタム解決関数があります。その機能では、複数のデータベースにアクセスすることもできます。たとえば、WordPressにはMySQLデータベースがありますが、リレーショナルである必要のない他のデータを格納するアプリケーション用のMongoデータベースもある場合があります。 GraphQL解決関数では、呼び出しを行って両方のデータベースからデータを取得し、1回のサーバーラウンドトリップでクライアントに送り返すことができます。

現在の形式のWordExpressは、管理にWordPressを使用するJavaScriptを利用したアプリケーションを構築するための良い出発点です。 Lanier氏は、この開発セットアップにより、PHPテンプレートよりもはるかに簡単にWebページとアプリケーションのコンポーネントを作成できると述べました。

「Reactを使用すると、各コンポーネントには、表示するマークアップだけでなく、そのコンポーネントのスタイル、動作に必要なデータ、およびインタラクションロジックもすべて1つまたは2つのファイルに含まれます」と彼は言いました。

WordExpressの現在の課題：プラグインの互換性とサーバー側のレンダリング

より効率的なクエリのすべてのエキサイティングな利点とJavaScriptを利用したフロントエンドの可能性にもかかわらず、WordExpressプロジェクトには、単純なブログのインストール以外の本番環境での使用を面倒にする多くの深刻な課題があります。ほとんどがPHPで書かれているため、WordPressプラグインの大部分とは互換性がありません。

「基本的に、フロントエンド全体を交換しました。つまり、フロントエンドに影響を与えるプラグインは何もしません」とLanier氏は述べています。「ただし、管理者側に影響を与える既存のプラグイン（Advanced CustomFieldsやAWSS3プラグインなど）を確実に活用できます。 WordPressデータがMySQLに保存される方法を操作するものはすべて引き続き使用できます。必要なのは、GraphQLスキーマとクエリを変更してそれらを操作することだけです。」

もう1つの大きな課題は、サーバー側のレンダリングを機能させることです。これは、SEOやメタタグなどの処理に必要です。 WordExpressがデータをフェッチしてReactコンポーネントに配信するために使用するApollostackは、サーバー側の自動レンダリングの初期サポートを最近追加したばかりです。

「FacebookのRelayからApolloStackに切り替えました」とLanier氏は述べています。「どちらもかなり新しいテクノロジーであり、どちらかがサーバーサイドレンダリングをうまく処理する方法を本当に理解しているかどうかはわかりません。私は数か月間それを調べていませんでした、そして物事はApolloStackでかなり速く動いていました、それで彼らは今までにそれを理解したかもしれません。」

今のところ、WordExpressは概念実証に過ぎず、Lanierは、既存のプラグインをサポートする予定はないと述べました。 WordExpressは現在、WordPressエコシステムの最良の部分であるテーマとプラグインを活用できないことを考えると、このスタックを使用する開発者は、おそらくWordPressの管理者側の力を維持することに関心があるとLanier氏は述べています。

「私はWordPress管理者が大好きです」と彼は言いました。「コンテンツの管理には非常に強力で使いやすいです。 WordExpressは、JavaScriptだけを使用してWordPressアプリケーションを構築したいJavaScript開発者にとっての出発点になるでしょう。」

LanierのWordExpressの目標は、WordExpressをさまざまな異なるReactプロジェクトで再利用できるnpmパッケージに変換することです。彼はすでに、連携して動作する2つのWordExpress npmパッケージを公開しています。wordexpress-schema（GraphQLスキーマと接続設定を処理します）とwordexpress-components（現在最初の2つのコンポーネント、WordExpressPageとWordExpressMenuを収容しています）。プロジェクトはNode.jsに基づいて構築されているため、開発者は任意のnpmパッケージを利用できます。これは、プラグインの互換性を制限するための慰めです。

GraphQLとWPREST API

GraphQLがRESTの直接の代替になると予測している人の多くは、この2つが共存できるという意見もあります。実際、Facebookは最近、RESTAPIをGraphQLでラップするためのガイドを作成しました。

「GraphQLが効果的であることが証明されれば、RESTAPIと共存する可能性があります」とPetrBela氏は述べています。「一部のAPIはRESTを使用し、一部はGraphQLを使用します。両方をサポートするものもあります。」彼は、RESTからGraphQLに完全に切り替えるには、業界で数年、おそらく10年かかると予測しています。

最近GitHubで1,000スターを通過した、LanierのWordExpressは、現在、GraphQLを利用したWordPressの実装を公に調査している唯一のオープンソースプロジェクトです。 GitHubをざっと検索すると、他の多くの人が同様の設定を試していることがわかります。幸い、GraphQLでは、サイトがデータベースのクエリにAPIを使用できるようにするためにWordPressコアを変更する必要はありません。

Lanier氏は、WP REST APIをコアにマージしようとしている人々の仕事に感謝し、GraphQLの実装をそれに対する脅威とは見なしていないと述べました。

「彼らがRESTAPIで行っている作業は良いことだと思います」と彼は言いました。「彼らは間違いなくその一歩を踏み出す必要がありました。 RESTは長い間存在してきました– GraphQLはまだかなり新しいので、RESTルートを使用するのは理にかなっています。また、より多くの人々がそれを使用する方法を知っています。 GraphQLの良いところは、REST APIをラップするために使用できるため、両方が共存できることです。」

WordExpressが単純な概念実証を超える可能性は、コミュニティからのフィードバックに依存します。 Lanier氏は、開発者はWordExpressをフォークして質問することで、WordExpressへの関心を示していると語った。

「人々はそれを使って遊んでいて、（願わくば）それを自分のものにしている」と彼は言った。「興味はそこにあると思います。ただし、それを実際に実現可能にするには、開発者のチーム全体が一流のオプションにする必要があります。」

Lanierは最近、Reactを100％使用していて、しばらくの間WordPressを使用する機会がなかったという新しい仕事に就きましたが、WordExpressの制作を準備するためのコラボレーションを模索することにオープンであると述べました。

「人々が本当に興味を持っていて、それを実現可能な解決策に成長させるために集まってみたいと思ったら、私はそれに100％関与するでしょう」と彼は言いました。

それをテストしてWordExpressで開発を開始したい開発者は、Reactがどのように機能するかについての基本的な理解が必要になります。 Lanierは、GraphQL実装がどのように設定され、GraphQLクエリとデータベースモデルを拡張する方法についての詳細なドキュメントを作成しました。 WordExpress.ioサイトは、GitHubにあるコードのライブデモです。