こんにちは。こちらはShifter Advent Calendar2020の14日目の記事になります！
12月も後半に差し掛かり、寒くなってきましたが、いかがお過ごしでしょうか？
最近ではJamstackの流行りとともに、Headless CMSとその周りで構成する要素が増えてきて、どれがいいのか悩むこともあるかと思います。
今回は、WordPressをHeadless CMSとして提供しているShifter HeadlessとGatsbyが提供しているプラットフォームGatsby Cloud利用して、サイトのデプロイまでをどこまで高速化できるのか試してみたいと思います。
※ShifterはShifter StaticとShifter Headlessの2つのプロダクトが提供されています。
Shifter StaticとShifter Headlessで、それぞれ解決する課題の違いは@seijiakatsukaさんが書いていただいている、Advent Calendar1日目の こちらで詳しく紹介されていますので、気になる方はチェックしてください。
まずは簡単にGatsby Cloudの概要を紹介します。
Gatsby Cloud
Gatsby Cloud は、Gatsby, Inc.が提供するGatsbyJSで構成されているサイトのデプロイやプレビューを容易に実現するプラットフォームサービスです。
GatsbyJSで構成されているサイトのGitHubリポジトリと連携し、リポジトリに変更がPushされるとビルドが走ります。また、データソースになる CMS の更新もリアルタイムにプレビュー可能です。(CMSがWordPressの場合、設定必要)
また、ビルド、デプロイ、ホスティング、CMSプレビューなどの機能は基本無料で使うことができますが、一番のメリットは、ビルドが早いと公表しているところです。(差分ビルドといったIncremental Buildsが利用できるためです。)
他に以下のサービスと連携してホスティングも可能です。
今回のゴール
今回、フロント側は、こちらのリポジトリで公開されているモノを利用します。
■gatsby-starter-wordpress-blog
https://github.com/gatsbyjs/gatsby-starter-wordpress-blog
こちらのサイトをShifter Headlessと連携し、Gatsby Cloudにデプロイして速度を見てみたいと思います。
Shifter Headlessの準備
まずは、Shifter HeadlessでSiteを作成します。
特に難しい設定もなく、WordPress URLにアクセスすると下の画面が表示されるので、これでSiteの準備が完成です。
このあたりのWordPressを一から用意する時間や手間がほとんどなく、一瞬で準備できるのは最高ですね。しかもHeadless CMS環境のホスティングなので、このあたりの体験がすごい。
次にWordpress側のコンテンツを用意します。まずは、WordPress管理画面へログインし、以下のPluginを導入します。
その他は特に特別な作業も不要なため、テスト的に投稿を作成します。
これで、Shifter Headless側の作業は完了です。続いて、Gatsbyの設定をしていきましょう。
Gatsbyのローカル環境作業
事前にローカル環境に Gatsby を環境にインストールします。Gatsby をインストールするには NodeJS も必要です。
$ npm install -g gatsby-cli
以下のリポジトリに移動し、Fork をクリックし自身のリポジトリにフォークします。
■gatsby-starter-wordpress-blog
https://github.com/gatsbyjs/gatsby-starter-wordpress-blog
次に、テキストエディターまたはviコマンドを使用して gatsby-config.js を編集します。
29行目のURLを記載する箇所にShifter HeadlessのWordPress URLを入力します。
resolve: `gatsby-source-wordpress-experimental`,
options: {
// the only required plugin option for WordPress is the GraphQL url.
url: process.env.WPGRAPHQL_URL || `https://{Shifter-url}.hl-a.getshifter.co/graphql`,
},
},
上の修正のあと、ローカルで以下の作業を行うとローカルで起動します。
$ npm install
$ gatsby develop
追加で、私の環境では、package.json内のパッケージ内容にエラーが発生したので、追加で以下を実施しました。
$ npm install gatsby-source-wordpress-experimental
調べてみたところ、バージョンが異なることが原因のようだったので、備忘録的に記載しておきます。
- "gatsby-source-wordpress-experimental": "^3.0.0",
+ "gatsby-source-wordpress-experimental": "^3.3.1",
上の手順が問題なければ、以下の様にローカルで起動確認ができます。
You can now view gatsby-starter-wordpress-blog in the browser.
⠀
http://localhost:8000/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
http://localhost:8000/___graphql
⠀
Note that the development build is not optimized.
To create a production build, use gatsby build
⠀
success Building development bundle - 12.971s
ローカルでの起動が正常に稼働していれば、以下の画面が表示されます。
問題なければ、GitレポジトリにPushしておきます。
これで、デプロイまでの準備が整いました。最後にGatsby Cloud側と連携をし、今回の作業のクライマックスです。
Gatsby Cloudとの連携
以下のURLからGatsby Cloudのサイトへアクセスします。
Gatsby Cloudにログインし、Add a Siteにて作成するSiteを追加します。
今回は、すでに準備しているGitレポジトリと連携を行うため、「Import from a Git repository」を選択し、「Github」を選択します。
GitHubを選択すると対象のリポジトリ、Branchなどを選択する画面となりますので、対象のリポジトリとブランチを選択します。ここでSite名も設定し、「Next」を選択します。
次にCMSとの連携の画面が表示されますが、WordPressはWebhookを利用して、CMS側のコンテンツが更新した場合、Gatsby Cloudで反映させるようです。手動で反映は可能ですが、自動で更新を行う場合、WordPress側に設定が必要なため、このあたりは今後、シームレスに更新できるようなアップデートに期待ですね。
最後に確認画面が表示されます。今回は環境変数等を特に設定していないので、空白ですが、こちらで値を定義してデプロイすることも可能です。そして、最後に「Create Site」を選択するとデプロイが開始されます。
デプロイの状況はログや経過時間などを随時確認できます。今回のデプロイは1分10秒ほどで初回デプロイは完了となります。
早速、対象のURLへアクセスを行うと、正常にデプロイがされており、ローカルで起動確認した内容と同様のコンテンツが表示されています。
こちらで、Shifter HeadlessとGatsby Cloudを連携した作業は完了です。
最後に次のデプロイからどの程度爆速になるのかを見てみます。
Enable incremental buildsをONにして、デプロイ！
気持ち!?少しだけ早くなった感じですね。一方incremetal buildsが機能していなさそうにも見えます。。
ここについては、Contentfulなど、IntegrationできるHeadless CMSでは機能できていることは確認できているため、もう少し調査してみたいと思います。
(分かり次第、Updateします。)
最後に
Headless CMSの役割により表現の柔軟性や構成する要素がどんどん増えてきており、Gatsbyだけでなく、Next.jsなどのフレームワークやShopifyなどとの連携により、今後もこの流れはもっと盛り上がるのではないかと思っています。そして、WordPressとの連携でShifterと連携する場面が様々なところで増えてきて、改めて面白いと感じました。
そして今回を機に、あまり書いていなかったブログをShifterに引っ越ししようかなと思います。また、来年2021年はブログも1ヶ月に1本は書いていこうと心には決めましたので、引き続きよろしくお願いいたします!!