ヘッドレス CMS: WordPress を使用した Gatsby JS

公開: 2020-05-04

WordPress は、世界のトップ 100 万の Web サイトの約 3 分の 1 をカバーし、コンテンツ管理システムで 50% 以上の市場シェアを占めているという一般的な知識があります。 2016 年に、WordPress は REST API を導入して、他のアプリケーションが WordPress データベース内のコンテンツへのアクセスを改善することを決定しました。 その結果、開発者は WordPress をヘッドレス CMS として活用できるようになります。

興味深いワードプレス統計

これは必然的に、エンジニアが WordPress の従来のプレゼンテーション レイヤー (フロントエンド) を使用することに制限されなくなり、データを配信するために任意のフロントエンド アプリケーションを利用できるようになることを意味していました。 これを踏まえて、このブログの大部分では、ヘッドレス CMS の効果に関する WordPress と Gatsby.js の関係について説明します。

CMS の簡単な歴史

ヘッドレス CMS 革命を理解するために一歩後退するとき、コンテンツ管理システム (CMS) の歴史を要約することは注目に値すると思います。 伝統的に、90 年代初頭には、ウェブマスターが HTML ファイルを直接編集し、FTP 経由でサーバーにアップロードするウェブサイトを実行する主な方法は、静的なウェブページでした。 最終的に、90 年代半ばに、Web テクノロジーが進化し始め、コンテンツがより動的になり、最初のモノリシックなコンテンツ管理システムが出現しました。

cmsシステムの歴史

基本的に、モノリシック CMS は、Web 上でコンテンツを編集および公開するために必要なすべてを含むソフトウェア アプリケーションです。 このようなシステムの最初のものは、EpiServer などのエンタープライズに限定されていましたが、その後、WordPress、Drupal、Joomla などのオープンソースのバリエーションが登場しました。 WordPressが時間の経過とともに最大の市場シェアを獲得したため、残りは歴史です.

しかし、その後のスマートフォン革命では、モバイル デバイスが Web コンテンツの消費方法と配信方法に影響を与え始めました。 これは、ラップトップやデスクトップ向けの Web コンテンツを配信するように設計された従来のモノリシック CMS に対する課題でした。

これを軽減するために、レスポンシブ デザインが生まれ、画面サイズに適応する Web サイト レイアウトが生まれました。 その結果、これはコンテンツ管理を表示層から切り離す機会にもなりました。 これが、ヘッドレス CMS の出番です。

ヘッドレス CMS

前述のように、ヘッドレス CMS はプレゼンテーション層のないものです。 その結果、コンテンツは API (RESTful または GraphQL) を介して配信され、それを表示する別のフロントエンド アプリケーションに配信されます。 API は、さまざまなツールとプログラミング言語を使用して、より高いレベルのセキュリティとスケーラビリティを備えたあらゆるチャネルとデバイスでコンテンツを利用できるようにします。

基本的に、CMS はフロントエンドの問題から切り離されているため、開発者は利用可能な最高のテクノロジを使用して、エンド ユーザー向けのリッチなエクスペリエンスを自由に構築できます。 「ヘッドレス」または「分離」モードは現在、ほとんどの CMS でサポートされており、Gatsby サイトへの道が開かれました。

したがって、ヘッドレス CMS を活用するには、まずサイトまたはアプリケーションを構築し、次に CMS の API を使用してコンテンツをプラグインする必要があります。

WordPress ヘッドレス CMS の実行

上記で共有されたイベントの年表に関して、WordPress がヘッドレス CMS にどのように影響を与えるかを見てきました。 WordPress には、プラグイン (本質的に「アプリケーション フレームワーク」として) で拡張できる API (アプリケーション プログラミング インターフェイス) が含まれています。 特に、これは後で説明するように REST API を介して実現されます。

ただし、WordPress API の重要な概念の 1 つはフックです。 基本的に、フックはプラグインが WordPress のコア機能を変更できるようにします。 実際には、フックは、WordPress で特定のイベント (ページの読み込みやポストエディットなど) が発生すると、WordPress が特定のフックを呼び出して関数を実行するように機能します。

具体的には、フックは「アクション」と「フィルター」に分割されます。 アクションを利用して、特定のイベントで特定の PHP 関数を実行できますが、関数は何も返す必要はありません。 フィルターを使用して、WordPress が特定のイベント中にデータを渡す関数を実行できます。これらの関数は、データをパラメーターとして受け取り、変更されたバージョンのデータを返します。

WordPress と REST API

Representational State Transfer (REST) は HTTP プロトコルに基づいており、データ (CRUD) を作成、読み取り、更新、および削除するための統一されたインターフェイス セマンティクスを提供します。

通常、WordPress で REST API を実行すると、開発者は JSON (JavaScript Object Notation) オブジェクトを送受信することで、WordPress データベースのデータにリモートでアクセスできます。 その結果、開発者は、WordPress で設計されていない他のアプリケーションから WordPress データを作成、読み取り、更新、および削除する機会が得られます。 たとえば、JavaScript Web アプリケーションやネイティブ モバイル アプリなどです。

ただし、ヘッドレス WordPress CMS と REST API および Gatsby との関係をより深く理解するにつれて、WordPress API のいくつかの基本的な概念に注意する必要があります。

wordpress-apiの基本概念
  • ルートとエンドポイント:ルートは HTTP 呼び出しを介してアクセスできるパスであり、エンドポイントはそのルートにマップされた HTTP メソッド (get、post、put、delete など) です。
  • リクエスト:登録済みの REST ルートに対して HTTP リクエストを開始すると、WordPress は自動的にリクエスト オブジェクトを作成します。 リクエストで指定されたデータによって、返される回答が決まります。
  • Response: Response オブジェクトは、リクエストを行ったときに返されるデータです。 要求されたデータまたはエラー メッセージで構成できます。
  • スキーマ:スキーマは、エンドポイントのデータ構造を参照します。 各エンドポイントは、返すことができるデータの構造がわずかまたは大幅に異なる場合があります。 したがって、スキーマは、エンドポイントが返すことができるすべての可能なプロパティと、それが受け取ることができるすべての可能なパラメーターを決定します。
  • コントローラ クラス:コントローラ クラスを使用すると、開発者はエンドポイントとルートを管理および登録できるだけでなく、リクエストを処理したり、スキーマを利用したり、レスポンスを生成したりできます。

React の「フレームワーク」

Gatsby.js と WordPress の関係の要点に迫ると、より多くのコンテキストを得るために、この技術的展望をより歴史的な基礎から解読する必要があります。 React は、最も急速に成長している JavaScript フロントエンド ライブラリ/フレームワークであるため、この話の鍵となります。 Facebook (そのコア開発者) によって有名になった他の大規模な Web サイトでは、Airbnb、Netflix、Dropbox、BBC、PayPal、Reddit、Salesforce、Squarespace、Tesla などのフロントエンドに React が使用されています。

その結果、React は実際にはライブラリであるため (本格的なフレームワークの注目すべき機能がまだ不足しているため)、これは、他の「フレームワーク」をその上に設計できることを意味します。 その結果、これらの 1 つが Gatsby.js です。

ギャツビーの紹介

その親 Web サイトによると、Gatsby.js は、開発者が高速な Web サイトやアプリを構築するのに役立つ、React ベースの無料でオープンソースの JavaScript フレームワークです。 原則として、Gatsby.js はアプリケーションから静的な HTML ページを生成して初期ロードし、その後単一ページの React アプリケーション (SPA) として処理を進めます。

Gatsby.js の属性

このような状況では、Gatsby はプログレッシブ Web アプリ (PWA) の原則を利用して、最初に必要な要素のみを取得し、後でアプリケーションの残りをバックグラウンドで読み込みます。 さらに、必要なデータのみが読み込まれるようにするために、Gatsby は GraphQL クエリ言語 (これも Facebook による) を利用して、ソースからデータを読み込みます。 また、優れた画像最適化を維持します。

これらすべての機能が統合されたことで、開発者は重要な HTML、CSS、データ、および JavaScript のみをロードするため、最速の Web サイトおよび Web アプリを作成するために必要なツールが提供されます。 そのため、ページが読み込まれると、Gatsby はリンクされたページのリソースをプリフェッチするため、サイトのナビゲーションは非常に高速に感じられます。

また、ページはオンライン配置の前にコンパイル時に生成されるため、強力な PHP サーバーはもう必要なく、静的ファイル (HTML、JS、CSS、バケット ストレージから直接) を提供できます。 さらに、Gatsby は React を利用しているため、コンポーネントを使用してすべてをうまく構成できます。 このモジュラーの側面により、開発者はコンポーネントを簡単に再利用できます。

gatsbyjs-features

すぐに使用できるその他の重要な Gatsby 機能には、次のものがあります。

  • 静的サイト ジェネレーター
  • オフライン アクセス
  • リンクされたページのプリフェッチ
  • ページのキャッシュ
  • 不要なコードのフェッチなし
  • コードとしてエクスポート
  • ホットリロード コンテンツ
  • ホット リロード コード
  • コンポーネント化
  • 一方向のデータバインディング
  • 宣言型 API データ クエリ (GraphQL)
  • 宣言型 UI
  • プログレッシブ画像読み込み
  • レスポンシブ画像の読み込み
  • 重要な CSS のインライン化
  • フォントのセルフホスティング
  • サーバーレス
  • アセット パイプライン
  • CSS 拡張 (SaSS)
  • 高度な JavaScript 構文
  • React コンポーネント エコシステム

Gatsby プラグイン

基本的に、Gatsby プラグインは基本的に、Gatsby API を使用する Node.js パッケージです。 これらのプラグインは、データ ソースを追加したり、データを他の形式に変換したり、サード パーティのサービスを追加したりできます。 ただし、Gatsby.org は、コア Gatsby チームまたはサード パーティによって作成された多くの既製のプラグインを含むプラグイン ライブラリを維持しています。 理想的には、Gatsby プロジェクトのプラグインをインストールするには、開発者は UNIX ターミナルでノード パッケージ マネージャー (NPM) を使用し、コマンド npm install を実行します。

GraphQL がどのように Gatsby に関連するか。

GraphQL は、正確に必要なデータを正確に API に記述でき、正確にそれを受け取ることができるという考えを中心に展開しています。 その結果、REST よりも効率的です。 この目的のために、Gatsby は Webpack と GraphQL を採用しています。 さらに重要なことは、GraphQL をクエリ言語として使用すると、クエリを実行するクライアント側ですべてが定義され、クライアントはアプリケーションの内部動作を意識しなくなります。

この独自の実装により、開発者はあらゆるデータ ソースを Gatsby に接続できます。 たとえば、ブログ投稿は、Markdown ファイル、Google シート、または別の WordPress Web サイトから取得できます。 したがって、コンテンツ配信の柔軟性が向上します。

Gatsby-WordPress の仕組み (ソースプラグイン)

この関係をさらに解き明かすには、ソース プラグインを理解する必要があります。 ソース プラグインは、Gatsby のデータ システム内で動作する特別なプラグインです。 名前がすでに示しているように、ローカルまたはリモートのさまざまな場所からデータを調達します。 その結果、データは Gatsby がノードおよびノー​​ド フィールドと呼ぶものに変換されます。 基本的に、ノード フィールドは 1 つのノード内の単一のデータを表し、最終的に、これらのノードには GraphQL クエリを介してアクセスできます。

同じ範囲で、ソース プラグインを通じて、Gatsby は数十のヘッドレス CMS オプションをサポートし、エンジニアリング チームとコンテンツ チームが、Gatsby、GraphQL、および React を使用してフロントエンド。

「Gatsby-source-WordPress」プラグインは、Gatsby コア チームによって構築および維持され、自己ホスト型の WordPress サイトまたは WordPress.com からデータを取得します。 また、Word-Press.com API への OAuth 認証も必要であり、開発者はレスポンシブ イメージをクエリすることもできます。

基本的に、このプラグインは、投稿、ページ、タグ、カテゴリ、メディア、タイプ、ユーザー、ステータス、タクソノミー、サイト メタデータ、カスタム投稿タイプなど、WordPress REST API のすべてのエンティティをサポートします。 さらに、REST API に登録された他の投稿メタに加えて、Advanced Custom Fields (ACF) エンティティと Polylang および WPML 言語情報もサポートされています。

したがって、このプラグインを使用すると、デフォルトで wpjson のすべてのエンドポイントを取得しますが、開発者は取得するルートを選択できます。 したがって、開発者は上記のメカニズムを採用した GraphQL を使用して WordPress からデータを取得できます。

実際には、「Gatsby-source-WordPress」ツールは、すべての投稿とその他のエンティティにスラッグを提供します。 したがって、エンジニアは「createPage」関数を呼び出してページを作成するだけです。 これは Gatsby-node.js ファイルで実行されます。通常、最初にデータ ソースのクエリを実行し、次に見つかったノードごとに「createPage」を呼び出し、コンポーネントとして使用するテンプレート ファイルを設定します。

CI/CD およびアプリケーション リリースの自動化。

Gatsby でヘッドレス WordPress CMS を実装する場合、デプロイの実行方法は非常に重要です。 通常、このような実行では、Application Release Automation (ARA) を使用して自動化されるアプリケーションの展開が必要です。

アプリケーション リリースの自動化

一般に、ARA には主な機能が伴います。

  • データ、アプリケーション コード、およびアーティファクトのデプロイ。
  • 各環境に固有の構成の展開
  • タスクと展開手順を自動化するためのプロセス ワークフローの設計。
  • 最後に、環境モデリングおよび/またはプロビジョニング バイナリ

Gatsby は静的サイトを作成するため、コンテンツが WordPress で更新されたときに、それに応じて Gatsby サイトでも更新できるように、ARA パイプラインを設定することが不可欠です。 通常、継続的デプロイはコードが変更されたときにのみトリガーされますが、この例では、データが変更されたときにトリガーすることが望ましいです。 そのため、Netlify を使用することをお勧めします。 組み込みの優れた継続的展開機能を備えており、セットアップがユーザーフレンドリーであるためです。

GraphQL と gatsby-source-WordPress を使用した WordPress からのクエリ

例として、gatsby-source-WordPress は、最初に REST を使用してエンドポイントのすべてを取得するように動作します。 次に、そのデータに基づいて内部 GraphQl API を生成します。 その後、クエリを実行し、その内部 GraphQL API からデータを収集します。 したがって、基本的に、ビルドは要求したデータのみで終了し、他には何もありません。

headless-wordpress-development-with-gatsby-js の利点

Gatsby.js を使用したヘッドレス WordPress 開発の利点

Gatsby を使用したヘッドレス WordPress 開発に触れたので、この種の技術的アプローチの利点を分析できるようになりました。 これは本質的に、Gatsby を採用するかどうかの決定の指針となるはずです。

  • 1 つ目の利点は、事前にレンダリングされた静的なサイトを持つことができることです。 これは、Web ページをレンダリングする最も効率的な方法です。Gatsby は GraphQL を使用して必要最小限のデータを実行するため、初期ロード後の時間の効率が向上します。
  • SEO の可視性の向上:静的ページは、すべてが事前にレンダリングされ、インデックス可能であるため、検索エンジンが簡単に読み取ることができます。 JavaScript を使用したページのレンダリングが検索エンジン最適化 (SEO) に関する問題である他のヘッドレス メカニズムとは対照的に、これは良いことです。
  • 比較的速い開発速度:他のヘッドレス アプローチと比較して、Gatsby には、ソースに関係なくデータを取得するための統一された理解しやすい方法があります。 これにより、実際のサイトに集中して Gatsby に面倒な作業の大部分を任せることができるため、開発がかなり簡素化されます。
  • より安価なホスティング: Gatsby アプリケーションは静的ファイルを提供するだけなので、どこでもホストでき、ホスティング費用を削減できます。 さらに、WordPress はビルド プロセス中にのみ呼び出され、ユーザー セッション中には呼び出されないため、手頃なホスティング ソリューションでもホストできます。
  • 強化されたセキュリティ:一般的に言えば、静的サイト ジェネレーターは、データベース、依存関係、ユーザー データ、またはその他の機密情報への直接接続がないため、非常に安全です。
  • プラグイン不要:開発者以外の視点から見ると、WordPress は利用可能なプラグインのおかげで操作が非常に簡単です。 ただし、これによりカスタム機能の実装が制限されます。 残念ながら、プラグインが多すぎると、サイトが重くなり、レンダリングが難しくなるため、サイトの速度が低下する可能性があります. ギャツビーの実行は、本質的にこれらすべてのボトルネックを回避します。

WordPress で Gatsby を検討する動機となるその他の側面:

  • WordPress の管理パネルを簡単に管理できます。
  • ユーザーログインシステムと承認をすぐに使用できます。
  • Gatsby および Gutenberg エディターを使用すると、ドラッグ アンド ドロップの Gatsby サイト ビルダーを構築できます。

Gatsby.js を使用したヘッドレス WordPress 開発のデメリット

  • 更新の制限:コンテンツが最初から変更されると、サイトの更新頻度に制限が設定されます。 さらに、サイトに大量のデータが含まれている場合、Gatsby ビルドの実行に最大 10 分かかることがあります。これは、頻繁に更新されるサイトでは問題になる可能性があります。
  • 定期的な更新の手間:また、Gatsby は静的サイト ジェネレーターであるため、単に「編集」することはできません。小さなテキストの変更でも新しい展開が必要になるからです。 そのため、動的な毎日のコンテンツの変更を多数必要とするページがある場合、これは時間のかかる面倒な作業になる可能性があります。
  • 遅延:通常、コンテンツが公開されて変更が反映されるまで数分待つ必要があります。
  • プレビューの欠如:従来の WordPress アプリケーションとは異なり、Gatsby にはプレビューがありません。 悲しいことに、これはコンテンツ クリエイターが Gatsby で見つけた最大の問題です。 おそらく、Web サイトをコンパイルしてすべてをオンラインにする Gitlab CI/CD パイプラインを使用して、すべてをコンパイルする必要があります。
  • 急な学習曲線:一般に、Gatsby と WordPress を同時に使用したい場合は、PHP と JavaScript の両方の言語に比較的精通している必要があります。 Gatsby は React と GraphQL を統合するため、これは多くの人にとって急な学習曲線になる可能性があります。

最終的な考え。

結論として、そのパフォーマンスとビジネス上の利点のおかげで、より多くの企業が技術スタックの一部として Gatsby を実装しています。 ただし、Gatsby を WordPress と統合すると、WP はバックエンドのみになることを覚えておくことが重要です。つまり、WP の機能と能力の一部が失われることになります。

さらに、WordPress 開発の経験がある開発者は、最新のパフォーマンス、スケーラビリティ、セキュリティ、および開発速度の利点を備えた優れたツールとして Gatsby を見つけるでしょう. これらすべては、WordPress が提供する使い慣れたコンテンツ作成ユーザー インターフェイスを保持しながら行うことができます。

ただし、このテクノロジーを開始する前に、プロジェクトの仕様と目的を常に考慮する必要があります。 たとえば、スケーラビリティ、パフォーマンス、開発速度、長いライフサイクルが重視される場合は、Gatsby が適しています。 ただし、プログラマー以外のコンテンツ作成者向けの柔軟性とツールを強化し、コンテンツを秒単位または分単位で更新することに重点が置かれている場合は、別のアプローチを検討できます。