DE{CODE}: WordPress 開発者向けのヘッドレス 101

公開: 2023-02-12

ヘッドレス開発は、従来の WordPress 開発よりもパワフルで楽しいものになる可能性があります。しかし、この新たなスタックには非常に多くの新しい選択肢があるため、どのように始めるのが最善でしょうか? このワークショップでは、WordPress プロジェクトをヘッドレス用にインストールして最適化する方法から、デカップリングされたフロントエンドで最初のページをテンプレート化する方法まで、ビルダーを順を追って説明します。

ビデオ: WordPress 開発者向けのヘッドレス 101

セッションスライド

WP EngineのWordPress Developers.pdf のヘッドレス 101

全文トランスクリプト

GRACE ERIXON : WordPress 開発者向けのヘッドレス 101 へようこそ。私の名前はグレース・エリクソンです。WP Engine のアソシエイトデベロッパーアドボケイトです。 Haus の Steve が参加します。今日は、ヘッドレスWordPressとは何か、そしてそれを使い始める方法を簡単に紹介します.

したがって、ヘッドレス WordPress Web サイトアーキテクチャとは何かを理解するには、従来の WordPress アーキテクチャがどのようなものかについて、全員が同じページにいることを確認することが重要です。従来、WordPress などの CMS は、Web サイトのフロントエンドとバックエンドの両方を処理していました。

従来のアーキテクチャでは、発行者が WordPress 内のブログ投稿やページなどのコンテンツを作成および管理します。開発者は、PHP と WordPress のテーマ API を使用して、サイトの外観と機能を制御するコードを記述します。次に WordPress は、訪問者に送信される HTML ページを生成します。

この結合された CMS アーキテクチャで、WordPress はパブリッシャーにコンテンツ管理機能を提供します。また、Web サイトの訪問者に HTML ページを提供する役割もあります。ヘッドレス CMS は、フロントエンドとバックエンドが別々に管理される分離アーキテクチャを使用します。ヘッドレスアーキテクチャでも、発行者は従来の WordPress アーキテクチャと同様に、WordPress でコンテンツを作成および管理します。

開発者は、JavaScript でサイトの外観と機能を制御するコードを記述し、WPGraphQL または REST API を使用して WordPress からデータを取得します。 Faust.js、Next.js、Nuxt.js、SvelteKit などのフレームワークは、このフロントエンドアプリケーションを強化するためによく使用されます。次に、フロントエンドの JavaScript アプリケーションが、Web サイトの訪問者に送信される HTML ページを生成して提供します。

従来のアーキテクチャとは異なり、WordPress は HTML ページの生成を担当しなくなりました。したがって、WordPress のバックエンドとフロントエンドの JavaScript アプリケーションの間でコンテンツを交換するためのやり取りは、API レイヤーを介して行われます。 API レイヤーの 2 つのオプションは、WordPress REST API または WPGraphQL です。

REST API は WordPress にバンドルされています。ただし、REST では各リソースに独自のエンドポイントが必要なため、必要なデータアクセスパターンが遅くなる可能性があります。たとえば、完全にモデル化された投稿を再構築するには、複数回の往復が必要になります。投稿のコンテンツ、作成者、およびカテゴリを取得する場合は、3 つの個別の API 呼び出しが必要になります。

対照的に、WPGraphQL では、投稿のコンテンツ、作成者、およびカテゴリをすべて 1 つのリクエストで要求できます。このため、WPGraphQL は私たちが推奨する API レイヤーです。 WPGraphQL は、WordPress サイトに拡張可能な GraphQL スキーマと API を提供する無料のプラグインです。 WPGraphQL は、要求された正確なデータを取得するため、REST API よりも高速です。その結果、クエリの最適化によって実行される関数が少なくなり、データのダウンロードが少なくなり、データの読み込みがより効率的になり、単一の要求に複数のリソースが含まれます。

ヘッドレスアーキテクチャにより、開発者は、最も人気のある JavaScript フレームワークを使用して、任意のフロントエンドテクノロジスタックから自由に選択できます。最も人気のあるフロントエンド JavaScript フレームワークには、React、Vue.js、Svelte などがあります。新しいフレームワークは常にリリースされているため、このリストは包括的とは言えません。

これらの JavaScript フレームワークの多くは、ルーティング、サーバー側レンダリングなどのソリューションを追加するメタフレームワークと組み合わせて使用されます。 React は Next.js と組み合わせて使用され、Vue.js は Nuxt.js と組み合わせて使用され、Svelte は SvelteKit と組み合わせて使用されます。 Gatsby は、もう 1 つの人気のあるメタフレームワークです。

WP Engine は、React と Next.js の上に構築された JavaScript フレームワークである Faust.js を開発しました。 Faust は、ヘッドレス WordPress Web アプリケーションをサポートするために特別に作成されました。すぐに使用できる認証と投稿プレビューをサポートし、WordPress データにアクセスするための便利な組み込みの React フックを提供します。

そこで、ヘッドレス WordPress アーキテクチャの意味と、使用するテクノロジーの種類について説明しました。しかし、ヘッドレスを選択する理由について簡単に触れておきましょう。 WordPress 自体は重い CMS であり、高速な言語ではない PHP を使用しています。ヘッドレス WordPress は、JavaScript を介してフォスター言語を使用し、API 呼び出しを介して必要なファイルのみを読み込みます。はるかに軽量であるため、サイトの読み込みが速くなります。

また、ヘッドレス WordPress は、データがフロントエンド配信とは別に存在するため、コンテンツへのリスクを最小限に抑えます。 Web 攻撃にさらされる可能性が低くなります。そして主な利点は、ヘッドレス WordPress アーキテクチャにより、パブリッシャーは WordPress が提供する優れたパブリッシングエクスペリエンスから引き続き利益を得ることができると同時に、開発者や Web サイトの訪問者は最新の JavaScript アプリケーションがもたらす技術的機能を活用できることです。

それでは、実際のヘッドレスサイトのコードを掘り下げてみましょう。新しい Atlas Blueprints ヘッドレス WordPress サイトのウォークスルーを事前に記録しました。 Atlas の新しいブループリント機能は、完全なヘッドレス WordPress サイトを立ち上げて実行するための非常に簡単な方法を提供します。スターターコード、プラグイン、コンテンツモデル、およびページ構造が付属しており、アプリをより早く軌道に乗せることができます。

それでは、新しいブループリントサイトを作成して、コードを詳しく見てみましょう。 WP Engine のダッシュボード内から、Atlas に移動します。 [アプリの作成] をクリックします。 [ブループリントで開始] を選択します。次に、使用するブループリントを選択します。ポートフォリオの設計図を選択します。

次に、WP Engine アカウントを GitHub アカウントに接続し、そのブループリントを新しいリポジトリに複製します。ビルドには数秒かかります。最後に、作成したばかりのリポジトリの名前、最も近いリージョンを選択し、[アプリの作成] をクリックします。

Atlas の URL をクリックすると、ヘッドレス WordPress サイトがどのように見えるかを確認できます。私たちは投稿ページに特に関心があります。ご覧のとおり、サイトは最新の投稿をすべてこの Our Blog ページに取り込みます。また、各投稿には個別のビューページもあります。しかし、このすべてのデータはどこから来ているのでしょうか?

WP Engine ダッシュボードに戻ると、WP Admin のボタンが表示されます。ヘッドレス WordPress サイトのバックエンドがあります。 [投稿] をクリックすると、Web アプリがプルしていたのと同じリストが表示されます。これで、ブループリントがクローンされた GitHub リポジトリを開くことができます。そして、そのレポをローカル環境にクローンしましょう。

次に、お気に入りのコードエディターである Visual Studio Code でこのリポジトリを開きます。プロジェクトディレクトリにドリルダウンすると、ブログページのファイルは SRC、pages、posts、Index.js にあります。このプロジェクトは、React、Next.js、Faust.js、および WPGraphQL を使用して構築されています。 React や JavaScript にさえ慣れていない場合、最初は混乱するかもしれません。

最初のセクションでは、ファイルは内部および外部のソースから必要なものをインポートしているだけです。ポストノードのプリパスフィールドを定義する 2 番目のセクションには、必要なすべてのデータがリストされます。プリパスを介してこれを実行すると、必要なときにデータが存在し、カスケードリクエストが発生しないことが保証されます。

次に、ページ機能があります。最初は、必要なデータをいくつかの異なる変数、つまり一般設定とページ分割された投稿のリストに収集するだけです。 return ステートメント内のタグは、Web ページに視覚的に表示されるコードです。まず、ヘッダーのコンポーネントがあります。次に、このメインコンポーネント内にエントリヘッダーコンポーネントがあり、これがページの上部に最新の投稿という大きなタイトルを表示するものです。

最後に、ページ分割された投稿のリストをパラメーターとして受け入れる投稿コンポーネントに到達します。 post コンポーネントがこの情報を使って何をするか見てみましょう。ここでは、受信した投稿のリストに含まれる各投稿をループしています。投稿ごとに、最新の投稿のページにカードのようなビューが表示されます。これは最初に、個々のブログ投稿のページへのリンクでラップされたアイキャッチ画像コンポーネント、投稿のタイトルの見出し、および投稿の日付と作成者で構成される投稿情報コンポーネントで構成されます。

すべての投稿を表示する Index.js ファイルに戻り、ページの下部に Load More コンポーネントを表示して、要求された場合にさらに投稿を取得することとフッターを表示して、これを終了します。最後の関数 getStaticProps は、Next.js の静的サイト生成関数で、関数によって返された props を使用してビルド時にこのページを事前レンダリングするように指示します。以上です。

ヘッドレスのセットアップを処理してくれた Blueprints に感謝します。 WPGraphQL を使用して WordPress バックエンドからデータを取得し、React コンポーネントを使用して投稿を表示するために、投稿ページに入る内容を分解するのは簡単でした。ご覧いただきありがとうございます。Twitter @graceerixon で私を見つけることができます。

ヘッドレス WordPress に関するその他のコンテンツについては、developers.wpengine.com をご覧ください。 Faust.js を使用してゼロから最初のヘッドレス WordPress サイトを構築する方法に関するチュートリアルがあり、現在、ヘッドレス 101 シリーズのコンテンツに取り組んでいます。無料の Sandbox アカウントにサインアップすると、Atlas が提供するすべてのツールを入手できます。それでは、Haus が leoburnett.com プロジェクトに Headless WordPress を選んだ理由について、Steve に説明してもらいましょう。

STEVE SCAVO: ありがとう、グレース。こんにちは、Haus の CTO、Steve Scavo です。私たちは、カリフォルニア州ロサンゼルスを拠点とするクリエイティブテクノロジースタジオおよびエージェンシーです。この講演のタイトルは、WordPress 開発者向けのヘッドレス 101 です。はっきり言って、私は本業の WordPress 開発者ではありませんが、それはヘッドレスアーキテクチャの美しさの一部だと思います。

したがって、WordPress を活用する必要がある非 WordPress 開発者のために、このヘッドレス 101 を簡単に呼び出すことができたはずです。それはちょうど適切なタイトルだったかもしれません。それがヘッドレスの素晴らしいところです。ご覧のとおり、すべての面でウィンウィンです。

では、なぜヘッドレスなのですか？私たちが話すことができる高レベルの理由はたくさんありますが、実際の生産例とそれが輝くときの実世界の例について話すことは本当に役立つと思います. そして、ヘッドレスアーキテクチャの下でヘッドレスを使用して、Leo Burnett のために行ったプロジェクトを紹介したいと思います。文脈上、Leo Burnett はシカゴの有名な広告代理店ですが、世界中に多くのオフィスを持っています。そのため、彼らには多くのコンテンツ、多くの作業があります。

古いサイトは単一の WordPress テーマで運営されていました。それは本当に断片的で、ちょっと遅く、うまく機能しませんでした。更新が難しく、Leo Burnett が伝えたいと思っていたような評判やブランディングを示すものではありませんでした。それが私たちがデザインの観点から取り組んだことです。そして、スタックを本当にモダナイズするためにヘッドレスを選択しました。

生き生きとして新鮮に感じさせ、素晴らしいユーザーエクスペリエンスと UI を実際にまとめるために必要な機能を持たせたかったのです。私たちは彼らの出版力を高めたかったのです。私たちは、彼らがコンテンツを公開できる頻度を増やしたいと考えていました。私たちはブランドのアイデンティティを再構築し、UI とインタラクションを実現したいと考えていました。Web サイトに Leo Burnett のような雰囲気を感じさせ、これらすべての小さなタッチと、彼らが伝えたかった編集、タイポグラフィ、インタラクションのポイントを取り入れました。

そして、コードベースとウェブサイトを将来に向けて準備したいと考えていました. 私たちは、今後 12 か月間、サイトを関連性のあるものにしたかっただけではありません。おそらく、次の10年間に関連するものにしたいと考えています。そして、このヘッドレスアーキテクチャ、このヘッドレススタックは、まさにそれを実現していると思います。

したがって、ヘッドレスの最初の問題の 1 つは、ホスティング、展開、およびインフラストラクチャに関して常に多くの決定が行われることであり、それは常に大きな問題点でした。したがって、これらのスタックの決定は、常に開発者に委ねられてきました。そして、あなたは探し回り、アイデアを考えます。OK、どのサードパーティ、おそらく CI/CD アプリケーションを使用する必要がありますか? これを AWS でホストしますか? どうやってそれを行うのですか？どんなサービス？そして、そのフローの周りにこれらの潜在的なソリューションを実装します。

Atlas と WordPress Engine Atlas プラットフォームは、これを本当に解決します。ここで出番です。これらすべての理由から Atlas を選択しました。Atlas にはマネージドサービスインフラストラクチャがあります。 CI/CD パイプラインを標準化します。あなたは本当にそれについて考える必要はありません。

環境間のデータ移行は、基本的にワンクリックフローで行われます。これは、歴史的に、QA からステージング、本番環境に移行する際の大きな問題でした。基本的に、WordPress エンジンと Atlas プラットフォームにより、それがワンクリックで完了します。

そして、マイクロサービスと DevOps にまつわるこの疲労があります。開発者としてどれだけのことを考え、サポートし、それを認識し、それを維持し続けなければならないかという、重い認知的負荷があります。これらはすべて、Atlas プラットフォームが実際にあなたの手から解放し、有益な方法で解決するものです.

それでは、ヘッドレスが実際に促進し、強調していると私が考えるいくつかのダイナミクスについて話しましょう。ここの最初の柱は 3 つです。最初の柱は開発者の経験です。仕事に適したツールを選択することができます。そして、私が私たちと言うとき、私は開発者を意味します.

コードを書きたいスタックを選択することができます。私たちにとってそれは Haus にあり、それは Next.js と React です。 Next.js は、ルーティング、パフォーマンス、およびアプリケーションアーキテクチャに関するいくつかの非常に優れた規則に沿った素晴らしいフレームワークです。また、ビジュアルデザインシステムだけでなく、体系化されたデザインシステムも実装したいと考えていました。これは、アプリケーションの一貫性、テスト済み、美しい状態を維持するものです。

相互作用は一貫しています。これにより、今後も新しいページや機能をそのエコシステムに構築し、それを維持して一貫性を維持することができます。また、宣言型の表現力豊かなコードを書くこともでき、React はそれをライブラリとして推奨しています。しかし、私たちはチームとしての執筆スタイルも信じています。フロントエンドでそのスタックを選択することができますが、おそらく従来のテーマベースの WordPress サイトでは、同じような贅沢はありません.

また、多くのクリエイティブなヘッドルームも必要です。 leoburnett.com にアクセスすると、ページ遷移が美しいことがわかります。あります – 物事がどのようにレンダリングされるべきかについて、従来の WordPress スタックに縛られることはありません。 WordPress はフロントエンドのレンダリングを担当しなくなりました。

私たちのヘッドルームは事実上無限です。アニメーションライブラリを選択できます。コンポーネントが互いに相互作用する方法を選択できます。これはDX側にとって大きなメリットです。

管理者のエクスペリエンスが向上しました。以前の慣れ親しんだ環境から離れたことがないため、最適化されたと思います。バックエンドのカットオーバーはありません。 WordPress から WordPress に移行しました。別の専用システムに移動するために、データをエクスポートしたり、スクリプトを作成したりする必要はありませんでした。そのため、親しみやすさは非常に大きいです。 leoburnett.com の現在の管理者のために、そのような流れを維持したかったのです。

採用とドキュメント – Web で 5 分間過ごすとしたら、おそらく WordPress のバックエンドに触れたことになるでしょう。それは誇張することはできません。 Leo Burnett には、非常に具体的なコンテンツポイントとカスタムフィールドも多数あります。 WordPress はそれを提供し、その力を提供しますが、高度なカスタムフィールドプラグインを実装することができました。これは、管理 UI を調整して本当に使いやすく使いやすくするための非常に優れた規則です。これは、管理者エクスペリエンスの勝利でした。

もちろん、3 つ目の柱はユーザーエクスペリエンスです。それは本当に重要なことです。ユーザーの皆さん、Haus の Web アプリケーションはネイティブアプリケーションのように感じられるべきであり、ドロップオフがあってはならないという私たちの考え方と同じように思います。ユーザーもそれを高く評価していると思います。

それらはシームレスです。彼らは敏感です。彼らはただ気分がいいです。そして、Leo Burnett とすべてのアプリケーションがそのように感じられるようにしたかったと思います。フロントエンドで必要なスタックを選択できるため、それが可能になります。

ネイティブアプリは本質的にバックエンドコンテンツインフラストラクチャから分離されており、Web アプリも同様です。そして、これが Atlas が促進するものです。これは、一般的にヘッドレスアーキテクチャが促進するものです。また、パフォーマンスを促進します。 UI を普遍的にレンダリングできます。つまり、初期負荷はサーバー側にあります。その後、クライアントが引き継ぎます。

ここにはたくさんのメリットがあります。 1つは、検索エンジンを喜ばせることです。それらはサーバー側のコンテンツです。これは速い。また、次のページをほぼ瞬時に事前レンダリングし、ビューポートの内容に基づいてそれらのリクエストを 1 回で行うこともできます。

Leo Burnett の場合、使用することを選択したコンテンツ API に関して、GraphQL エンドポイントをセットアップしました。つまり、より無駄のないペイロードが戻ってくるということです。必要なコンテンツを正確に定義しています。サーバー側のレンダリングがクライアント側のレンダリングに移行した後は、ハイドレーションが少なくなります。

これにより、送信されるコードが減り、応答が減り、応答時間が短縮されます。これは間違いなく成功です。Atlas ワークフローまたはヘッドレスワークフローに移行する場合は、GraphQL API と REST API のようなものを比較してよく検討することをお勧めします。

ユーザーの観点から見ると、彼らは新鮮でタイムリーなコンテンツを見ています。これは、コンテンツのプレビュー用に最適化された公開フローです。ステージングおよびプレビュー側でコンテンツをすばやく取得し、それを本番環境に昇格するように最適化されています。 Leo Burnett の管理者は、コンテンツを簡単に更新できることに非常に満足しており、ユーザーも満足しています。

結果は？これは、すべてをロールアップするためのものです。開発者、生産的な管理者、満足しているユーザーにインスピレーションを与えます。これは、すべての Web 開発チームが本当に目指しているトライアドであり、希望です。

開発者が刺激を受けるとき、彼らは最適化されたツールセットを使用しています。ちょうどいい感じです。彼らは幸せです。彼らはより良いコードを書きます。

管理者は、美しいエコシステムにコンテンツを作成していることを知っています。これは速い。迅速に発送します。ユーザーは更新されたコンテンツを目にし、モダンで美しく、適切に機能し、最適化されたフロントエンドを体験しています。

最後に、心に留めておいていただきたいいくつかの考えをまとめます。ブリーフ自体には、常に言葉が欠けていると思います。私たちはあまりにも多くの場合、「ねえ、私に美しいウェブサイトを構築してください」とだけ話していると思います. すばらしいウェブサイトを構築してください。私はそれを見た目と感触にしたいと思っており、これらすべてのレビューをクライアントと一緒に実行しました.

そして、みんなが盛り上がり、V1 が来て、ローンチされます。そして、そのウェブサイトを引き継ぐ必要がある人々は、あなたが私にめちゃくちゃを手渡したようなものです。どうすればこれを処理できますか? これはあなたが思いついたその場しのぎのフローですか？

美しいウェブサイトを構築して負担を引き渡したくありません。ここハウスでは、そうしないことに大きな誇りを持っています。そして、プラットフォームとしての Atlas と Atlas の素晴らしいところは、それが解決されていることだと思います。

これにより、インフラストラクチャの観点とコードの展開の観点から実際に意味のあるエコシステムと Web パブリッシングシステムを出荷しているという自信が得られます。これにより、IT チーム、エンジニアリングチーム、またはマーケティングチームに対して、あなたが何をしているかを理解していること、およびあなたが構築したこの新しい Web サイトを適切に管理していることを文書化して証明できます。

覚えておいてください、私たちはただウェブサイトを構築しているわけではありません. 私たちはコンテンツ公開システムを確立していますが、これは初日から理解し、認めることが重要です。繰り返しますが、ここで Atlas の出番です。

ですから、今後のヘッドレススタックを戦略的に考える上で、ちょっとした情報が役立つことを願っています。それがあなたの望む方向であるなら、Atlas を検討することを強くお勧めします。セッションをお楽しみいただけましたでしょうか。どうもありがとうございました。