gatsbyjs.com

Gatsbyとは何ですか？

Gatsbyは、コンポーネントと構造化コンテンツからウェブサイトを構築するためのReactフレームワークです。ファイル、コンテンツ管理システム、API、その他のサービスからデータを収集し、そのデータをGraphQLレイヤーで整理して、静的、遅延、サーバーサイド、またはクライアントサイドレンダリングによるページ作成に利用できます。

Gatsbyはフレームワークです。gatsbyjs.comは、その公式ウェブサイト兼ドキュメントハブです。この区別が重要なのは、本ガイドの主題がフレームワークのアーキテクチャ、パッケージ、リポジトリである一方、このドメインはプロジェクトがドキュメントを公開する場所だからです。

Gatsbyプロジェクトでは通常、複数の関心事が1つのワークフローにまとめられます。

• Reactコンポーネントがインターフェースと再利用可能なページ要素を定義します。
• ソースプラグインがローカルまたはリモートのシステムからコンテンツとデータを取り込みます。
• Gatsbyが取得したレコードをデータレイヤー内のノードとして正規化します。
• GraphQLクエリがページとコンポーネントに必要なフィールドを選択します。
• ページAPIとテンプレートがデータをルートに変換します。
• レンダリング設定が各ページをいつ生成するかを決定します。

GatsbyとReactの関係

ReactはGatsbyのコンポーネントモデルを提供します。開発者はReactコンポーネントからレイアウト、ナビゲーション、テンプレート、インタラクティブ機能を構成し、Gatsbyはルーティング、データ取得、ページ作成、アセット処理、本番出力を担う周辺フレームワークを提供します。

したがって、GatsbyはReactの代替でも、単なるコンポーネントライブラリでもありません。Reactを中心に構築された、一定の設計方針を持つウェブサイトフレームワークです。チームは、データとレンダリングにGatsby固有のAPIを使用しながら、使い慣れたJSX、コンポーネント構成、props、state、ブラウザ側のインタラクションを活用できます。

GatsbyがReactに追加するもの

関心事	Reactが提供するもの	Gatsbyが追加するもの
インターフェース	コンポーネントとstate	ページ規約、レイアウト、ビルド統合
データ	アプリケーションレベルの取得方法の選択肢	正規化されたデータレイヤーとGraphQLクエリのワークフロー
ルート	アプリケーションを構築するための基本要素	ファイルベースのページ、プログラムによるページ作成、クライアント専用ルート
出力	ブラウザでレンダリングされるインターフェース	静的、遅延、リクエスト時のページレンダリング
統合	汎用的なJavaScriptエコシステム	Gatsbyプラグイン、テーマ、スターター、フレームワークのライフサイクルAPI

この構造は、コンテンツ量の多い公開ウェブサイトを構築するReactチームに適している場合があります。コンテンツ統合がほとんどない小規模プロジェクトや、要件の中心がクライアントレンダリング型アプリケーションである場合には、不要かもしれません。

データレイヤーとGraphQL

Gatsbyのデータレイヤーは、異なるコンテンツソースに共通のクエリインターフェースを提供するよう設計されています。ソースプラグインがレコードを取得してGatsbyノードを作成します。その後、GatsbyはそれらのノードをGraphQLスキーマ経由で利用可能にし、ページとコンポーネントからクエリできるようにします。

サイトでは、Markdownファイル、画像、ヘッドレスコンテンツシステム、選択したサービスのデータを組み合わせる場合があります。すべてのページに各ソース固有のレスポンス形式を理解させる代わりに、Gatsbyは関連レコードを共有グラフ経由で公開できます。

一般的なコンテンツの流れは次のとおりです。

1. ファイル、サービス、またはコンテンツプラットフォームが元の素材を保持します。
2. Gatsbyのデータ取得処理中に、ソースプラグインがその素材を取り込みます。
3. Gatsbyが取り込んだレコードをノードとして表現し、スキーマを構築します。
4. GraphQLクエリがページまたはコンポーネントに必要なフィールドを要求します。
5. テンプレートがクエリ結果を使用してページを生成します。
6. Gatsbyが選択されたレンダリングモードに従ってページをレンダリングします。

GraphQLはGatsbyのソースデータワークフローの中心ですが、通常のReactの値をすべて置き換えるものではありません。コンポーネントのprops、ローカルstate、ブラウザイベント、クライアントサイドリクエストは、ビルド時のグラフの外側にも存在できます。検討すべき点は、ページに組み込む必要があるコンテンツをGatsbyの共有スキーマによって簡素化できるかどうかです。

データレイヤーによって作業も増えます。チームは、ソースの動作、ノード間の関係、スキーマの変更、クエリの依存関係を理解する必要があります。複数のシステムを統合するグラフには価値がありますが、そのビルドコストと保守負担は、スターターサイトから推測するのではなく、実際を代表するコンテンツを用いてテストすべきです。

ソースプラグインと広範な拡張モデル

ソースプラグインはGatsbyをデータに接続します。ローカルファイルを読み取ったり、コンテンツシステムやサービスと統合したりして、GraphQLレイヤーに参加するノードを作成できます。この点で、処理、分析、スタイリング、画像対応、その他のライフサイクル動作を追加するプラグインとは異なります。

Gatsbyは再利用可能な機能を、関連する3つの形式でパッケージ化しています。

• プラグインは、ソース、変換、統合、またはフレームワーク機能を追加します。
• テーマは、サイトから拡張できる再利用可能なGatsbyの設定と機能をパッケージ化します。
• スターターは、開発者がコピーして調整する初期プロジェクトを提供します。

スターターはセットアップを短縮できますが、その依存関係と規約は採用するチームの責任になります。テーマは複数サイト間で機能の一貫性を保てますが、チームはテーマが何を制御するかを理解すべきです。プラグインを使えば独自の統合コードを避けられる場合がありますが、互換性と保守状況は個別に評価する必要があります。

大規模なプラグインカテゴリーが存在するからといって、特定のパッケージがチームのGatsbyバージョン、データソース、デプロイモデルに対応しているとは限りません。実践的な評価では、必要なパッケージを正確に特定し、そのドキュメントとリポジトリの活動状況を確認したうえで、提案されたアーキテクチャ内でテストすべきです。

Gatsbyのレンダリングオプション

Gatsbyは当初、静的サイト生成との強い結び付きで知られていましたが、現在のドキュメントでは複数のレンダリング方式が定義されています。これらはページごとに選択できるため、公開記事、大規模なアーカイブ、リクエストに依存するルート、アプリケーション領域に異なる本番モデルを適用できます。

レンダリングオプション	ページが生成されるタイミング	検討に適した質問
静的サイト生成（SSG）	ビルド中	ページに必要なコンテンツはデプロイ前に利用可能ですか？
遅延静的生成（DSG）	遅延対象のページが初めてリクエストされたとき	このページを初回ビルドから除外できますか。また、ホストはGatsby DSGに対応していますか？
サーバーサイドレンダリング（SSR）	getServerDataを使用してリクエスト時	レスポンスにリクエスト時のデータまたはコンテキストが必要ですか？
クライアントサイドルート	アプリケーションパスに対してブラウザ内	このセクションは意図的にアプリケーション形式になっていますか。また、JavaScriptの実行が完了する前に何が利用できますか？

静的ページと遅延ページ

SSGはビルド中にHTMLと関連アセットを生成します。入力が事前に分かっているコンテンツに適した自然な選択肢です。生成ファイルは配信しやすい一方、ページ数の多さ、高コストなクエリ、多数のコンテンツソース、負荷の高い画像処理によって、ビルド要件が増える可能性があります。

DSGは、選択したページの生成を最初のリクエストまで延期します。特に、リクエスト頻度の低いロングテールコンテンツがあるサイトでは、初回ビルドで作成するページ数を減らせます。また、Gatsbyの遅延生成動作を実装したデプロイ環境が必要です。静的ファイルだけを任意のホストにアップロードすることと同じではありません。

リクエスト時レンダリングとブラウザレンダリング

SSRは、GatsbyのgetServerData APIを通じてリクエスト時にレスポンスを生成します。出力がリクエスト時点の最新情報に依存するページを提供できますが、純粋な静的ページでは不要なサーバー実行、キャッシュ判断、障害処理、インフラ要件が加わります。

クライアントサイドルートは、ブラウザで処理されるアプリケーションセクションをサポートします。生成された公開ページと共存できますが、チームはローディング状態、ナビゲーション、アクセシビリティ、クライアントサイドコードの実行前に利用できるコンテンツを確認すべきです。ブラウザルートが最終的に正しい情報を表示するという理由だけで、公開コンテンツとしての発見可能性を当然視すべきではありません。

どのレンダリング方式も、速度や検索での可視性を保証しません。結果は、ページ設計、JavaScript、アセット、データソース、キャッシュ、ホスティング、実装品質によって異なります。Gatsbyはチームに複数のアーキテクチャ上の選択肢を提供しますが、それらを測定する必要性をなくすものではありません。

画像とコンテンツ制作

画像は多くの場合、テキストや構造化レコードと同じコンテンツパイプライン内にあります。Gatsbyプラグインは画像ファイルを取得して変換し、処理済みアセットをページクエリに接続できます。その後、コンポーネントは選択された画像データをページテンプレートの一部としてレンダリングできます。

有用な編集ワークフローでは、責任を次のように分けます。

• 編集者は、選択したソース内でタイトル、本文、メタデータ、画像参照を管理します。
• ソースプラグインが、それらのレコードと参照先アセットを取り込みます。
• Gatsbyのデータレイヤーが、コンテンツノードを必要な画像データに接続します。
• クエリが、テンプレートに必要なフィールドと画像バリエーションのみを要求します。
• コンポーネントが、キャプション、代替テキスト、寸法、レイアウト動作を提供します。
• 本番ビルドで、レコード、アセット、ルートがまとめて解決されることを検証します。

画像処理は一貫性を向上させられますが、それ自体もビルド作業です。チームは、実際のアセット数とサイズをテストし、変更が再ビルドにどう影響するかを確認し、編集ソースにある意味のある代替テキストを保持すべきです。画像が情報を伝えるものか、装飾的なものか、適切に説明されているかをプラグインが判断することはできません。

Gatsbyが適している可能性がある場面

Gatsbyは、すでにReactを使用しており、複数のシステムからコンテンツを集約する必要があるプロジェクトに特に適しています。そのデータグラフは、各ソースと、それを使用するページテンプレートの間に一貫したレイヤーを提供できます。

評価する価値のある一般的な状況は次のとおりです。

• ファイル、画像、コンテンツプラットフォームを組み合わせるドキュメントサイトまたは編集サイト。
• 再利用可能なReactコンポーネントと構造化されたページレコードを持つマーケティングサイト。
• 1つのクエリインターフェースが有効な、複数ソースを扱う公開プロジェクト。
• ページAPI、GraphQL、確立されたプラグインを中心に構築された既存のGatsbyサイト。
• 選択したページがDSGの候補になり得る大規模なコンテンツコレクション。
• 生成された公開ページと、リクエスト時またはクライアントサイドのセクションを組み合わせるサイト。

コンテンツソースが1つだけで単純な場合、正規化されたグラフの利点がない場合、または主にリクエスト時およびクライアントサイドの処理を中心としたアプリケーションアーキテクチャが必要な場合、Gatsbyはそれほど直接的な選択肢ではないかもしれません。これはアーキテクチャ上の判断であり、フレームワークの品質に対する評価ではありません。

ビルドとデプロイのトレードオフ

静的生成は作業をデプロイ前に移します。Gatsbyは、ソースデータの取得、スキーマの構築、クエリの実行、ページの作成、画像の処理、コードのバンドル、出力の書き込みを行う必要がある場合があります。所要時間とリソース要件は実際のプロジェクトによって異なります。

実際を代表する評価では、次の項目を記録すべきです。

テスト領域	検証する内容
コンテンツ規模	ページ数、ノード数、関係、現実的なレコードサイズ
ソースの信頼性	認証、レート制限、障害、再現可能な取得
クエリ	スキーマの安定性、クエリコスト、コンテンツ変更後のエラー
画像	処理量、メモリ使用量、出力サイズ、編集用メタデータ
レンダリング	SSG出力、DSGの初回リクエスト、SSRレスポンス、クライアントルートの読み込み
デプロイ	選択したすべてのモードへの対応、キャッシュ動作、障害復旧

小規模なデモだけでは、完全なカタログがどのように動作するかを確認できません。チームは、クリーンビルド、対応している場合の差分変更、コンテンツソースの停止、データセット内で一般的なページと極端なページの両方をテストすべきです。

DSGは作業を初回ビルドから移し、SSRは作業をリクエスト時に移します。これは実行タイミングと運用責任の変更であり、無条件に得られるパフォーマンス改善ではありません。選択したホストが必要なGatsbyの動作をサポートしている必要があり、チームはコールドリクエストや上流障害の際に何が起こるかを理解すべきです。

Gatsby、Astro、その他の代替案

GatsbyとAstroは、どちらもコンテンツ主導型ウェブサイトの評価対象になる可能性がありますが、プロジェクトの構成方法は異なります。Gatsbyでは、React、GraphQLデータレイヤー、ソースプラグイン、ページ生成APIが中心となります。Astroは、単により高速またはより新しい選択肢として扱うのではなく、独自のドキュメントに記載されたアーキテクチャに基づいて評価すべきです。

チームがインターフェース全体でReactを使用したい場合、正規化された複数のコンテンツソースをクエリする必要がある場合、Gatsbyの統合機能に依存する場合、または確立されたGatsbyコードベースを保守している場合、Gatsbyはより詳しく検討する価値があります。そのグラフとプラグインのライフサイクルが実際のコンテンツ問題を解決せずに構造だけを追加する場合は、別のフレームワークの方が単純かもしれません。

有用な比較では、各候補で同じ代表的な範囲を構築します。1つのコンテンツソース、1つの複雑なページ、一覧、画像処理、ナビゲーション、想定するデプロイモードです。開発者の理解しやすさ、ビルド動作、ブラウザ出力、アクセシビリティ、ホスティング要件、保守責任を比較してください。デフォルトテンプレートだけを見て普遍的な勝者を決めることは避けてください。

創設者と公式コミュニティリソース

2020年4月2日に公開されたGatsby公式コミュニティQ&Aでは、Kyle Mathewsは「Founder @ GatsbyJS」と記載されていました。この日付付きの肩書きは、その情報源における歴史的な役割を説明するものであり、Gatsbyの現在のリーダーシップに関する主張として解釈すべきではありません。

Gatsbyのドキュメントでは、目的別に公式コミュニティチャンネルを案内しています。

• Discordは、開発者向けの支援をコミュニティに求める場所として記載されています。
• GitHub Discussionsでは、プロジェクトと機能について議論できます。
• コントリビューション用ドキュメントでは、プロジェクトに参加する方法を説明しています。
• 保守されているgatsbyjs/gatsbyリポジトリには、フレームワークのソース、パッケージ、issue、コントリビューション履歴があります。

これらのリソースは、読者がドキュメントを検証し、実装について質問し、公開されているプロジェクト作業を確認するのに役立ちます。ただし、その存在を、応答時間、パッケージの存続期間、将来の計画に関する裏付けのない主張へ変換すべきではありません。

Gatsbyを採用する前にチームが決めるべきこと

1. コンテンツを整理する。 すべてのソース、レコード間の関係、更新頻度、各フィールドを使用するページを特定します。これにより、Gatsbyの正規化されたGraphQLレイヤーが意味のある調整上の問題を解決するかどうかが分かります。

2. 代表的なページにレンダリングモードを割り当てる。 どのページを静的にできるか、どのページを遅延できる可能性があるか、どのページにgetServerDataが必要か、どのページを意図的にクライアントサイドにするかを確認します。デプロイ先が、その組み合わせをサポートしていることを検証してください。

3. 具体的な依存関係一式を監査する。 必要なソースプラグイン、変換プラグイン、テーマ、スターター、画像ツールがプロジェクトのGatsbyバージョンに対応しているかを確認します。不確実な統合は、アーキテクチャ上の依存関係にする前に試作してください。

4. 本番環境に近いワークロードでテストする。 Gatsbyは一貫性のあるReactとコンテンツのフレームワークを提供しますが、その適合性は、速度、検索順位、容易なスケーリングに関する広範な約束ではなく、チームのデータ、ページ、統合、ホスティングモデルとの整合性によって決まります。