これを押してください: WPGraphQL と Faust.js

公開: 2023-01-13

WMR の WordPress コミュニティポッドキャスト、Press This へようこそ。 各エピソードでは、コミュニティ全体からゲストが登場し、WordPress 開発者が直面している最大の問題について議論します。 以下は、元の録音の転写です。

レッドサークルが提供

Doc Pop : あなたは WMR の WordPress コミュニティポッドキャスト、Press This を聞いています。毎週、WordPress コミュニティのメンバーにスポットライトを当てています。私はあなたのホスト、Doc Popです。私は WP Engine での役割を通じて WordPress コミュニティをサポートし、TorqueMag.Io でポッドキャストを作成したり、漫画やチュートリアルビデオを描いたりしています。それをチェックしてください。

Red Circle、iTunes、Spotify で Press This を購読するか、wmr.fm でエピソードを直接ダウンロードできます。

Press This のこのエピソードでは、ヘッドレス WordPress、GraphQL、Faust.js について話しています。これらのツールを一緒に使用する方法と、ヘッドレス WordPress に関連するコストの種類。私たちはこれについて深く掘り下げようとしています。今日は 2 人の素晴らしいゲストが参加してくれます。コロラド州デンバーに拠点を置く WP Engine のプリンシパルソフトウェアエンジニアで、WPGraphQL を管理している Jason Bahl がいます。 . また、Faust.js に取り組んでいるエンジニアリングマネージャーの Chris Weigman もいます。私は通常、これらのショーをゲストに WordPress のオリジンストーリーについて尋ねることから始めるのが好きですが、ここでは少し話を変えてみようと思いました.

ジェイソン、WPgraphQL とは何か、そして wordPress の起源について教えてください。

Jason Bahl:そうそう、WPGraphQL は無料のオープンソース WordPress プラグインで、GraphQL API を WordPress サイトにもたらします。GraphQL はグラフクエリ言語です。そのため、開発者はグラフクエリ言語を使用して WordPress の内外にコンテンツを取得できます。

プラグインが生まれたのは、私が数年前に新聞社で働いていて、多くのコンテンツシンジケートを行っていたときです。全米に 54 か所ほどのサイトのネットワークがあり、コンテンツをある場所から別の場所に移動する必要がありました。ご存知のように、ニュース記事が公開されると、さまざまな新聞が他の新聞のコンテンツを購読できます。

そのため、さまざまなイベントが発生したときに、このネットワーク上でデータを移動する必要があり、WordPress REST API を使用してそのデータ移動の多くを行っていました。そして、技術的に、そして技術的に実際のパフォーマンスのように、いくつかの問題を抱えていましたが、開発者の経験もありました. 2015 年に Facebook によってオープンソース化された、実際のグラフクエリ言語である GraphQL について知りました。

そこで私はこのテクノロジーを見つけ、プロトタイピングを行い、同僚に売り込み、連絡先シンジケートを REST から GraphQL に移行しました。そして、JavaScript フレームワークがホットなものになりつつあり、それがおそらく GraphQL を使用する主なユースケースになることを知って、コミュニティプロジェクトとしてプロジェクトに取り組み続けました。サーバー間の通信は主なユースケースではありません。これで私たちのニーズは解決しましたが、より大きなビジョンが見えたので、コミュニティ向けのオープンソースプロジェクトとして取り組み続けました。

DP:そうですね。クリス、ファウストとは何か、またどのようにして生まれたのかについて、似たような話を教えてもらえますか?

Chris Weigman:確かに、Faust は最近、本当に今週の時点で公式にリリースされ、GraphQL を使用してヘッドレス WordPress サイトを構築するためのパブリックフレームワークに再リリースされました。 2020 年に開発が開始されましたが、これは WP Engine の非公式プロジェクトのようなもので、これが 3 番目の主要なピボットです。

彼らはそれを DevRel の拡張として開始し、GQty と非常に JavaScript である開発者優先のメンタリティを使用してもう少し正式なものにし始め、ピボットしました。そして、昨年の 12 月 1 日にチームを引き継いだとき、それが私たちのターゲット市場ではないことに気付きました。

WordPress 開発者向けに開発するべきでした。それで再構築を始めて、最近ようやく再リリースできるようになりました。

DP:最近、Faust.js で新しい wpgraphql.com を立ち上げたとツイートしたジェイソン。以前のサイトは、ヘッドレスの WordPress だったと思います。あなたが行ったこの変更について教えていただけますか?

JB:ええ。つまり、wpgraphql.com は長年にわたってヘッドレスサイトでした。そのため、複数のデータソースを使用しています。ブログの投稿がすべて WordPress にあるように、私は WordPress に多くのコンテンツを持っています。

一部のドキュメントは WordPress にも存在します。そして、いくつかのドキュメントが GitHub リポジトリのマークダウンファイルに存在します。 Gatsby を使用していた期間は最も長く、おそらく 3 年間ほどでした。Gatsby は、複数のソースからデータを取り込むことができるデータ層をコアに持つ JavaScript フレームワークです。

GitHub からデータを取得し、WordPress からも WPGraphQL を使用してデータを取得し、そのデータを使用してテンプレートを作成できるようにしました。それで数年使っていました。私が何とかしたかったデータレイヤーには多くの問題点があります。

そこで、Faust が構築されている Next を使用したいと思いました。これは別の JavaScript フレームワークですが、欠けている部分がたくさんあったと思います。次に、これらの JavaScript フレームワークの多くは、フロントエンドフレームワークがすべてのルーティングを定義する必要があるという考えを持っていますよね? ただし、CMS を使用している場合は、CMS がルーティングを定義します。

そのため、フロントエンドが何かについて意見を持ち、バックエンドが異なる意見を持っているなど、それらをうまく機能させるには技術的な問題がたくさんあります。私が解決しようとしていた問題の 1 つは、特定の URL が特定の種類のものであることをフロントエンドに認識させ、それを表すテンプレートをレンダリングさせることです。

ブログ投稿には、ドキュメントやユーザーアーカイブなどとは異なるテンプレートがあるように。そのため、フロントエンドに CMS に URL を送信し、データを取得し、返すテンプレートを理解できる機能を持たせたいと考えました。 WordPress では、テンプレート階層と呼ばれます。それで、ファウストチームがその問題を解決できたとき、私はファウストに移行しようと思いました。

そうです、PHP のテーマ設定など、WordPress のコアに存在するいくつかの概念を取り入れてヘッドレスで使用できるので、React の利点と、フロントエンドで使用したい JavaScript をテンプレート化するために使用できます。サイトですが、WordPress の世界ではおなじみの概念です。

DP:クリス、あなたはファウストに何らかの変更が加えられたと言いましたね。それらの変更は何でしたか？ご存知のように、ジェイソンはそれらについて言及していました。この改善を可能にした変更にはどのようなものがありますか?

CW:常に WPGraphQL に焦点を当てています。本当に問題だったのは他のすべてでした。たとえば、Faust の最新のメジャーバージョンでは、GQty と呼ばれる GraphQL とやり取りするためにその下にあるライブラリを使用していましたが、紙の上では非常にクールに聞こえました。当時のファウストチームからのアイデアは、抽象的なことにしましょう。人々はこれらの複雑なクエリを作成する方法を知る必要はありません。

このフレームワークはそれを抽象化する必要があります。 WordPress データのすべての複雑さのために、実際には非常に良さそうに見えました。 1 つの投稿タイプでさえ、非常に多くのバリエーションを持つことができます。たぶん、それをカテゴリと混ぜているのかもしれません。 GQtyはそれを通すことができませんでした.

その上、GQty バージョンでビルドされたとき、Jason が話したルーティングの問題はまったく注目されませんでした。誰がルーティングを処理しますか? WordPress は、コンテンツが何であるかによってルーティングを処理したいと考えています。これはコンテンツ管理システムであるため、すべてのルーティングと WordPress は主にコンテンツに基づいています。

Next.js はフロントエンドフレームワークであるため、すべてのルーティングはこれに基づいており、ルーティングがどのように基づいているかについてはまったく異なるパラダイムです。 /Blog on Next は、ブログのコンテンツとは関係がない可能性があります。テンプレートのセットになります。ブログを構築できるアプリの一部になります。

WordPress の /Blog は非常によく意味するものですが、これらはすべてブログ投稿です。 WordPress を非常に堅固なフロントエンドまたはヘッドレス対応の CMS にしたい場合、構築時のそのパラダイムは、そのルーティングに対処する必要がありました。これを行ったときのもう 1 つの変化は、GQty バージョンで述べたように、私たちの目標は WordPress を使用しなければならなかった JavaScript 開発者でした。

私たちは何年にもわたって WordPress を構築してきたエージェンシーを扱っていますが、彼らは現在、さまざまな理由でヘッドレスに移行しています。彼らは WordPress 開発のやり方を知っています。彼らは、WordPress のテンプレートルーティングがどのように機能し、テンプレートがどのように機能するかなどを理解しています。

WordPress 開発者が GraphQL をより簡単に使用できるように、これらの機能を前進させる必要があります。そして、それがここでのファウストの目標です。テンプレート階層は、WordPress が行ったことを単純に再構築するだけです。 Next のルーティングを使用したい場合は、アプリでそれをオーバーライドする方法があるので、何も失うことはありません。

しかし、コンテンツ管理によってコンテンツをルーティングできる真のコンテンツ管理システムとして WordPress を使用している人々にとって、ファウストはそれをはるかにうまく処理してくれるでしょうか? それは理にかなっていますか？

DP : ええ。絶対。ここでちょっと休憩するにはいい場所だと思います。 Chris Weigman と Jason Bahl による WordPress コミュニティポッドキャスト、Press This を聴いています。 WordPress とヘッドレスの話に戻ります。乞うご期待。

DP: Press This で戻ってきました。そして、ご存知のように、クリス、その休憩の直前にあなたは何かについて言及しました。あなたは、ますます多くの企業がヘッドレスに移行していることに言及しました.WP Engineが多くの研究を行って、それが事実であることを示していることを私は知っています. ちょっと疑問に思っているのですが、ヘッドレスは間違いなく企業としての評判があると思います。ヘッドレスと考えるとき、私は正しく考えているのでしょうか。ヘッドレスとはそういうものですか？企業向けのツールですか、それともより多くのサイトで使用されるツールですか?

CW:はい、いいえ。大部分がヘッドレスであり、特に現在の WordPress では複雑さが伴うため、必要なものを構築する完全なチームが必要になる可能性があります。

これは、箱から出してすぐに WordPress を使用している人ではなく、自分の個人的なブログが欲しいだけの人です。それは可能ですが、それを可能にするためには、これまでのところはるかに重いリフトです。 Contentful と同じです。他のすべての CMS と同じです。シンプルなもの、つまり何年もの間ウェブ上にあったタイプのコンテンツが必要な場合、ヘッドレスはおそらくこれまでに対処したいよりも多くの作業を必要とします.

厳密にはエンタープライズですか？ほら、いいえ。ギャツビーはこの問題に何年も取り組んできました。後で別のポッドキャスト、Doc with Mastodon があります。数年前から参加しているコミュニティです。ほとんどの人はヘッドレス CMS のバリエーション、特に Gatsby を使用していますが、Hugo もあります。非常に草の根レベルで、さまざまな種類の技術があります。

そのため、草の根ユーザーと大規模なサイトのエンタープライズユーザーに行き着く一方、WordPress は伝統的に他のすべてのユーザーとの間で分類されるようです。それは、Gatsby ユーザーのようにマークダウンファイルやコードを扱いたくない人です。

しかし、個人のブランディングや個人のブログを構築する 10 人のチーム全体を持っている人でもありません。これにより、WordPress はその中間から抜け出し、非常に簡単に両端に拡張できます。 GraphQL 間で簡単に構築できるようになりました。すべてのデータがあり、そのデータを処理する方法が増え続けています。

そしてファウストは、それを利用することをはるかに簡単にし、1 か月ではなく 1 日で構築できるものを実現します。

DP:ジェイソン、クリスがあなたの考えを聞きたいと言いました。これは私のような小さなチームや小さなブロガーにとってはあまり良くないと聞いています。これは明らかに理にかなっています。ヘッドレスの WordPress は必要ありませんが、私が疑問に思っているのは、iOS開発者とWordPress開発者が必要になるため、ヘッドレスWordPressはより多くの費用がかかるのでしょうか? それはより高価ですか、それともどういうわけか費用対効果が高いですか？

JB:おそらく、何を制作しているかにもよると思います。あなたがiOSについて言及したように、ネイティブモバイルアプリを実行している場合、それに関係なくコストがかかることは明らかであり、WordPressからのデータを使用している場合、それを行う良い方法はありません.ネイティブアプリは php をレンダリングしないため、ヘッドレスで行う必要があります。

しかし、従来の WordPress で現在 Web 用に構築している場合は、テーマを見つけに行くことができます。無料のテーマを知っているか、マーケットプレイスでテーマを見つけてダウンロードし、インストールすれば、レースに出ます。ほとんどの人は、何らかの方法でそれをカスタマイズしようとしています。

したがって、通常、開発者のコストは、自分で行うか他の誰かが行うかに関係なく発生します。ヘッドレス WordPress で従来の PHP テーマと異なる点の 1 つは、たとえば、新しい wpgraphql.com を立ち上げたときに、Gatsby サイトを動かしている WordPress と同じインスタンスを使用できたことです。

私はデータを取得しています。データは Gatsby サイトに出入りしており、CMS でコンテンツを公開し続けると同時に、次のフロントエンドを開発することができました。従来の WordPress 開発では、通常、サイトをステージング環境のようなものに移行する必要があります。

その環境で新しいテーマをアクティブ化し、そこにテーマを構築し、コンテンツ作成者に次のように伝えるコンテンツ凍結期間のようなものに対処します。新しい WordPress インスタンス、ライブインスタンスを設定します。」そして、そこにログインして、コンテンツを正しく処理し始める必要があります.

ヘッドレス WordPress、実際の WordPress インスタンスを中断することなく、完全に異なるフロントエンドスタックでサイトを再構築できました。これは、データとプレゼンテーションの分離ですよね? 明日、次のホットなテクノロジーを探求したい場合は、次の代わりに Svelte に目を向けることができ、WordPress を変更する必要はありません。

したがって、場合によっては、別のサーバーをスピンアップし、チームがコンテンツの作成を停止し、WordPress の別のインスタンスに移動してから、そこで公開を開始し、デルタ移行を行うなどのプロセス全体が実際に安くなる可能性があります。それにもコストがかかります。

もう 1 つ興味深いのは、JavaScript エコシステムが実際に出荷されていることです。私の意見では、ヘッドレスに移行するための一般的な動機の 1 つは、コンポーネントベースのアーキテクチャです。 React と VUE のエコシステムにはあらゆる種類のコンポーネントライブラリがあり、プロジェクト間でコンポーネントを再利用できます。

そのため、政府機関は、プロジェクトで使用する共通のコンポーネントを構築し、それらを中央の場所で更新してから、複数のプロジェクトにインストールできます。 WordPress では、PHP テンプレートパーツと WordPress は通常、それらが属するプロジェクトと非常に緊密に結合されているため、これはそれほど簡単ではありません。

ヘッドレスでは、これらのコンポーネントを含む MPM パッケージを使用でき、複数のプロジェクトがそのパッケージを更新して、少ない労力で同時に利益を得ることができます。したがって、現時点では、おそらくよりコストがかかり、より多くの作業が必要になると思いますが、最近まで存在しなかったファウストのようなツールは、ヘッドレスを構築するために必要な全体的な労力を削減していると思います.

そしてそう遠くない将来、ヘッドレスではないよりもヘッドレスで構築する方が安上がりになるかもしれません。

DP:クリス、ヘッドレス WordPress のコストに関してエージェンシーが考える必要があるかもしれないものに追加したいことはありましたか?

CW:ジェイソンは本当に頭に釘を打ったと思います。

WPGraphQL について私が気に入っている点の 1 つは、私のチームが次に WordPress を拡張して、私たちが呼ぶものでその方向性を拡張しようとしていることです。これらのコンポーネントをどのように再利用しますか? JavaScript 側と同じように WordPress 側には適用されないため、単なるコンポーネントという言葉は使いたくありません。

しかし、プロジェクト間でコードを再利用するにはどうすればよいでしょうか。ヘッドレスであろうとなかろうと、WordPress ではヘッドレスがそれを可能にします。しかし、平均的なブロガーは、食通のブログを書こうとしているだけで、おそらく自分では対処していないと言っても過言ではありません。それは非常に代理店の問題です。その分コストが高くなる？

たぶん、そうではないかもしれませんが、これのどこにコストがかかるかについて話すとき、それが複雑になるところです? データをどのように使用するかは、さまざまな種類があるためです。

DP:ええ、もちろんです。ご存知のように、ツインシティーズとジェイソンのナッシュビルでウィークリーに取り組んでいる新聞のバックグラウンドから来て、56の新聞に1日発行しないように言ったらどうなるか想像できます。

サイトを更新しているため、今日はニュースはありません。

JB:ええ。つまり、私たちはそれらの期間を経験しましたよね？私がそこに雇われたときのように、彼らは WordPress を使っていなかったので、私の仕事の一部は別のシステムから WordPress に移すことでした。ですから、WordPress の日に公開するという日も確かにありました。あなたがしていることをやめなさい。右。

ですから、そのような期間があったことは間違いありません。または、昨夜の深夜まで古いシステムで公開していたという問題にも対処する必要がありましたが、WordPress はその 2 日前に準備ができていました。そのため、デルタ移行のようにして、すべてのデータがまだ同期されていることを確認して、これらのプロセスに技術的および人的コストが確実にかかるようにする必要があります。

DP:ええ。また、まだ WordPress を使用している場合でも、このコスト削減を実現できるエコシステムを利用できることはたくさんあると思います。 SEO ツールを構築する必要はありません。

Yoast SEO プラグインなどを使用できます。あなたがヘッドレスサイトであっても、ほとんどのプラグインは正面向きでない限り機能すると思います。

JB:ええ。それは実際には興味深いことです。そのため、新しい Faust はプラグインアーキテクチャ自体で構築されています。すぐに使用できるように、クライアントが付属しています。Apollo クライアントを使用しているため、WPGraphQL からデータを取得できます。WordPress データを取得できますが、プラグインを作成できるため、あなたのように前述のとおり、WordPress サイトに Yoast SEO をインストールします。

Yoast プラグインを追加できます。まだ存在しませんが、すぐに存在する可能性があります。そのデータをどう処理するかを知っているフロントエンドに Faust 用の Yoast プラグインを追加できますよね? したがって、私たちが作成してサポートするものもありますが、コミュニティがファウスト側のプラグインを作成してサポートすることもできるので、たった1行のコードでこのプラグインを追加できますヘッドレスフロントエンド用の Yoast などの機能を取得します。

これは、Faust が取り組んでいるのと同じように、他のヘッドレスフロントエンドが実際にその概念を持っているとは思えないものです。プラグインは、WordPress 開発者にとってなじみ深いものだと思います。 WordPress からおなじみの概念を取り入れていますが、最新の JavaScript フロントエンドスタックとの橋渡しをしています。

DP:それは、Press This の最後の休憩に適した場所です。戻ってきたら、Chris Weigman と Jason Bahl との会話を締めくくります。乞うご期待。

DP:あなたは、WordPress コミュニティのポッドキャストである Press This を聞いています。私はあなたのホスト、Doc Popです。今日は、WPGraphQL、Faust、およびヘッドレス WordPress サイトを強化する方法についてお話します。休憩の直前、ファウストとプラグインについて話していたので、皆さんにランダムな質問を投げかけて、ここに何か良い答えがあるかどうかを確認します.

しかし、クリス、ファウストには何か可能性があるのではないかと思っています。それがヘッドレスプラットフォームであることは知っていますが、WordPress のファウストテーマのようなもので、少なくともセットアップできる可能性はありますか?ここに必要なプラグインと、すぐに使えるすべてのものがあります。

CW:もちろんです。実際、私たちはすでにそれを持っています。 Local と非常によく連携するため、ブループリントと呼んでいます。ほとんどの人は、WP Engine のようなプラットフォームで起動する前に、何らかの調整を行う予定です。そこで、Local の Blueprints の名前を借りました。

新しいファウストには、ポートフォリオと呼ばれるものがあります。これは基本的に完全なポートフォリオテーマであり、エージェンシーが使用できる非常に空白の足場に取り組んでいます。コツをつかめば、すべてを自分でカスタマイズしたくなるでしょう。したがって、足場はプロジェクトのベストプラクティスであり、それをスピンアップすると、それを使用してすべての独自の作業を行うことができます.

長い間、私たちはヘッドレステーマストア、ala Blueprints について非常に多く話し合ってきました。人手が足りないので、それは少し先のことですが、それは絶対に私たちが考えていることであり、実現したいと考えています.

DP:ええ、考えるのはクールです。それは、まったく異なる種類のエコシステムに入ることです。

ジェイソン、以前にインタビューしたことがありますが、この質問は常に出てくると思いますが、WPGraphQL について聞くたびに、REST API の機能によく似ていると思います。実際、それは REST API が行うことよりもはるかに強力に思えます。REST API はコアの一部です。ちょっと疑問に思っているのですが、WPGraphQL は WordPress コアの一部であるべきだと思いますか?

JB:たぶんいつか。私たちはまだそこにいないと思います。おそらくグーテンベルクを除いて、物事がWordPressコアにマージされると、イノベーションは停止します. たとえば、REST APIには、2016年からまだ存在していると私が指摘するバグがまだあります.そのため、変更を加えるペースはずっと遅くする必要があります。プラグインの場合は、人々がオプトインしたいバージョンをオプトインできるようにし、プロジェクトに最適なバージョンを選択できるため、はるかに迅速に反復できます。

コアのどこで、コアを更新し、それに重大な変更が含まれている場合、Web の 40% が壊れている可能性があります。つまり、GraphQL は仕様であり、WordPress とは何の関係もありません。

右。そのため、GraphQL 仕様はまだ進化しています。そして、それが進化し続けるにつれて、最新かつ最高の GraphQL 仕様に追いつきたいと考えています。今日、たとえば WPGraphQL を Core にマージし、GraphQL が進化し続けると、WordPress は GraphQL の 2022 年版で立ち往生し、残りの世界は 2030 年版か何かになります。私にとっては、WPCLI が X を行うための公式の方法のように認識されるようにすることは、ある時点で理にかなっていると思います。

WordPress 用の独自の CLI クライアントを構築することもできますが、コミュニティでは WPCLI が公式のものであると認識されています。これは WordPress Core の一部ではありませんが、WordPress Foundation およびほとんどの 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 でフォローしてください。 Press This は Red Circle、iTunes、Spotify で購読できます。また、毎週 wmr.fm から直接ダウンロードすることもできます。私はあなたのホスト Doctor Popular です。WP Engine での役割を通じて WordPress コミュニティをサポートしています。また、Press This で毎週コミュニティのメンバーにスポットライトを当てるのが大好きです。