Gatsbyでブログはじめました

December 01, 2018

ずっとHugoでブログ書こうと思って準備して放置だったんですが、まだ始めてもいないのに最近人気が出てきたGatsbyに乗り換えることにしました。
そのうち仕事でもヘッドレスCMSと組み合わせるとか、使いたくなることあるかもしれないので。
とりあえず最低限記事がアップできて見ることができる状態ではじめてから、ちょっとずつ機能を加えていきます。

ブログを始めるまでに利用するツールを色々検討して得た、昨今のブログツール/CMSについての知識を、ここにまとめたいと思います。

静的サイトジェネレータの逆襲

前から試していたHugoは「静的サイトジェネレータ(Static Site Generator)」と呼ばれるものの一種です。
簡単に言うと、Markdownなどで記述したコンテンツから記事一覧などを含む静的HTMLに変換してWebサイトを生成するツールです。
生成は自分のPCで行い、生成したWebサイト全体をサーバにアップロードします。
サーバ側には静的ファイルを配信するHTTPサーバさえあればよく、データベースやプログラムを実行する仕組みは必要ありません。

静的サイトジェネレータのクライアント/サーバ構成

ブログツールとしてデファクトスタンダードと言ってもよいほど有名なWordpressは、記事をデータベースに格納し、PHPによってサーバ側で動的にHTMLに変換します。

Wordpressのクライアント/サーバ構成

そのため

  • ブラウザで記事の編集管理ができる
  • サーバ側で複雑な処理を行わせることが可能

という利点がある一方で、

  • サーバにアクセスがある度にプログラムが走るので動作が遅い
  • PHPとデータベース(MySQL, PostgreSQLなど)の動作する環境が必要

という欠点があります。

それに対して静的サイトジェネレータを使うと、変換は自分のPCで行うため、

  • サーバはただの静的ファイルを返すだけなので動作が早い
  • 静的ファイルを配信できる環境があればオッケーで設置がお手軽

という利点があります。

実はWordpressの前にデファクト的なブログツールだったMovable Typeも静的サイトジェネレータです。
記事が増えるとサイト全体の生成が遅くなること、商用利用が有償になったこと、などがあり、オープンソースのWordpressにシェアを奪われたという経緯があります。
(今はMovableTypeで動的も可能ですし、Wordpressでプラグイン使って静的も可能ですが・・・基本的には元々そうってことで)

しかし数年前から特にエンジニアの間で静的サイトジェネレータへの回帰が見られました。
口火を切ったのはGitHubが作成したJekyllで、GitHub Pagesで使われています。
これを使うと、簡単に静的なWebサイトを構築でき、かつGitHub Pagesで無料で公開することもできます。 そのJekyllを使ったブログツールとしてOctopressが現れました。

ただしRubyベースのJekyllはページ数が増えると遅いという欠点があります。
そのためGoベースで劇速なHugoが人気を集めるようになりました。
HexoはNode.jsベースで、Hugoには負けますが十分高速で、Goに対するJavascriptの利点を活かしてプラグインで拡張できる仕組みがあります。

一般人にはブラウザで編集できるのは嬉しいのかもしれませんが、エンジニアならエディタの方が快適ですし、シンプルで整理された作りでカスタマイズしやすい方が嬉しいです。

ヘッドレスCMS戦国時代の幕開け

ブラウザでJavascriptを動かし、AJAXでデータだけをサーバから取得することが当たり前に行われるようになりました。 それの権化であるSPA(Single Page Application)も普通に使われています。
またコンテンツは、スマホアプリでも利用したいかもしれません。

コンテンツを利用するものが種々あるとなると、CMSはコンテンツの編集・管理とAPIによる配信だけを行えばいいのでは?

ヘッドレスCMS

そういう時代の流れに合わせて、コンテンツの表示を行うフロントエンドと、コンテンツの編集と管理を行うバックエンドを分離して、バックエンドだけを担当するCMSがヘッドレスCMSです。

画面としてはコンテンツの編集と管理だけの機能を持っており、RESTやGraphQLなどのAPIを通してコンテンツを配信します。
閲覧ユーザーへの表示は他のツールに任せてしまいます。
最近のトレンドとなっており、様々なサービスやツールが現れています。

特にサービス(SaaS)が多いのが印象的です。
オープンソースのものを自分で設置しようと思うと選択肢は少なく、自分が知ってるのだとstrapiとか。

ヘッドレスCMS時代の静的サイトジェネレータ

上述したHugoなどの既存の静的サイトジェネレータに対するGatsbyの特徴は2つあります。

  1. GraphQL経由で様々なデータソースからコンテンツを取得できる
  2. Reactで実装されたSPAを生成する

様々なデータソースに対応

GraphQLを通して様々なデータソースから統一された方法でデータを取得することができます。

以下はGatsbyのサイトにある図で、Gatsbyの動作を説明したものです。
各種データソースからGraphQL経由でデータを取得して、Reactで動作するSPAとしてビルドし、静的Webサイトを配信できるホストにデプロイするという流れになります。

Gatsbyの動作

データソースとしては、

  • ローカルファイル
  • ヘッドレスCMS
  • WordpressやDrupalなどのCMS
  • 各種サービスのAPI

などが考えられます。

データソースとしてWordpressやDrupalを記事の編集と管理にのみ利用すれば、ヘッドレスCMSの代わりになります。
既存のWordpressやDrupalで提供されているWebサイトのコンテンツを、Gatsbyで一部利用するといった用途も考えられます。

GatsbyはヘッドレスCMSの「ヘッド」として使えるわけですが、SPAとしてブラウザで動作しているときにデータソースからデータを取得してくるわけじゃありません。
あくまで静的サイトジェネレータであって、データソースからのデータ取得を行うのはビルド時だけです。

図で表せば以下のような感じです。 ここでは「何らかのデータソース」としてヘッドレスCMSを想定しています。

GatsbyのヘッドレスCMS利用時のクライアント/サーバ構成

データソースとしてローカルのファイルシステムを利用するプラグインを使えば、別途CMSを用意しなくて済みます。

Gatsby静的ファイルデータソース

SPAによるリッチなユーザー体験

既存の静的サイトジェネレータに対するGatsbyの利点は、閲覧者側のユーザー体験がリッチになることです。

SPAですからページ遷移は擬似的なもので、実際のページ遷移は発生せず、仮想DOMによる画面の変更は高速です。
図では「Webアプリ」とだけ書いていますが、当然コンテンツは全部を一度に取得するわけではなく、ファイルに分割されていて適宜SPAが取得します。
いい具合にプリフェッチし、いい具合にキャッシュしてくれますので、データ取得による画面切り替えのタイムラグも感じさせません。

つまり動作がサクサクなんです。

欠点はHugoやHexoほど生成は早くないこと。

あれ?でもデータソース側はGraphQL対応してないんですけど・・・??

ここまで聞いて「なるほど〜」と思いましたか?でもちょっと待ってください。

ローカル・ファイルシステムに保存してある静的ファイルも、Wordpressも、GraphQLになんて対応してません。
GatsbyがGraphQLでデータを取得するっていうのなら、GraphQL対応したAPIを持つサーバからしかコンテンツを取得できないのでは??

この辺り、Gatsbyは各データソースに対応したプラグインを入れることで、内部的にGraphQLに変換するみたいです。
つまりgatsby-source-filesystemを入れれば、プラグインがGraphQLのクエリを処理してファイルシステムから静的ファイルを取得してデータを返します。 Wordpressを使うならgatsby-source-wordpressを使います。

こうすることで、Gatsbyを利用する開発者は全ての種類のデータソースに対し、GraphQLを使ってアクセスする形で統一して記述できるわけです。

まとめ

時代の先端を行くイケてる静的サイトジェネレータ “Gatsby” を使って、ブログをはじめてみることにしました。


K5

K5: 本業はソフトウェアエンジニアで、一般社団法人ClearWaterProjectおよび株式会社creatoに所属。 趣味でケーナ、フォルクローレ・ギターを演奏し、CHASKAに所属。 Qiitaアカウントはこちら