2021年4月28日
POSTDをGatsby.jsベースに変更しました
POSTDの運用がリクルートからニジボックスに移管される際に、デザインのリニューアルと同時にコードベースをGatsby.jsに変更しました。
本記事では、運用移管に至るまでの過程を踏まえつつ、現在のPOSTDの構成を紹介します。
移管前のPOSTD
前述の通り、POSTDは株式会社リクルートのインキュベーション部門Media Technology Lab.（現新規事業開発部）で運用されていました。 最後に公開した記事は、2019年3月28日の「PHPはもうダメだ、PHP万歳！」となっています。
もともとはWordPressによる運用が行われていましたが、運用体制の関係で静的HTMLをFirebaseで公開する形式になっていました。 ニジボックスへの引き継ぎに伴い、記事の翻訳を始めとしたサイト運用を再開することになり、改めてCMSの形式に変換する必要が出てきます。
Gatsby.jsを選ぶ
以前のPOSTDはWordPressを元に静的ファイルのみが残っている状態でした。 再び翻訳記事の掲載が可能になる体制にするためには、何かしらの形でCMS化をしていく必要があります。
候補を検討しましたが、移管後の運用などを意識した際に、要件として上がってきたのが以下の2点です。
- レスポンス速度などのパフォーマンスを可能な限り維持する
- ニジボックスの強みを生かした構成にする
最終的には、以下の判断のもとGatsby.jsへの移行を決定しました。
レスポンス速度などのパフォーマンスを可能な限り維持する
前述の通り、引き継ぎ直後の状態は「静的HTMLをFirebase Hostingで配信する」という形態です。 この形態は、バックエンドにアプリケーションが存在しないため、非常にレスポンスが高速です。 このパフォーマンスを可能な限り維持することを考えると、CMSとしてはSSG(Static Site Generation)機能による静的HTMLの生成がほぼ必須になります。
Gatsby.jsはgatsby buildというコマンドによってソースから静的HTMLを生成できるため、速度の維持が期待できます。
ニジボックスの強みを生かした構成にする
ニジボックスの開発組織はフロントエンドに強みを持っています。 （どういう強みがあるかについては、Wantedlyやキャリア採用サイトを参照ください） 特に「React合宿」といった能力向上施策も実施しており、Reactコンポーネントの設計・実装をできるメンバーが多数います。
Gatsby.jsはReactをベースとしたフレームワークです。 そのため、ニジボックスのフロントエンド開発力を用いたコンポーネント設計・運用を進められます。
切り替えの流れ
実際の移行のために、以下の作業に分割して作業を進めていきました。
- 既存のページから記事情報を抽出
- デザインの設計とコンポーネント分割
- デプロイ・プレビューに関する設計
既存のページから記事情報を抽出
手元に存在するファイルは「WordPressから生成した静的HTML+アップロードファイル群」です。 そのため、まずはサイト全体からコンテンツ情報を抽出する必要があります。
基本的にはWordPressの記事としての運用をしていたため、「タイトル」「本文」「タグ」といったブログとしての標準的な情報を持っています。 それに加えて、翻訳記事をコンテンツとするサイトとして「多くの記事に『翻訳元の記事についての情報』を含む」という特性が存在します。
POSTDの場合は、全体として以下のような記事情報を抽出しています。
- 邦題タイトル
- 本文
- カテゴリ
- タグ
- 公開日
- サムネイル画像
- 元記事情報（タイトル、URL、記事の日付、著者名、著者リンク、その他の情報）
Gatsby.jsの関係上、記事ソースはMarkdownが望ましいので、HTMLからpandocで変換し直しています。 機械的な変換をしているため、いくつかの記事で表示崩れなどが起きているものについては、手動でフィードバックを掛けていきました。
また、既存記事に紐付いている画像については、URLがWordPressの構造から/wp/wp-contents/uploadsで始まっています。
これらについては、静的ファイルとしてstatic配下でビルド時に直接組み込めるようにしています。
デザインの設計とコンポーネント分割
Gatsby.jsを採用したため、CMSとしてのテンプレートの部分はReactコンポーネントとなります。
フロントエンド開発室のメンバーにも参画してもらい、フロントエンドエンジニアにコンポーネント設計や実装を行ってもらっています。 自分は主に「Gatsby.jsでの運用を想定したプロトタイプの用意」「Gatsby.jsとしてのデータ構造への再設計」に注力しました。
コンポーネント周りについても、比較的細かく分割してもらっています。 そのため、今後のフロントエンドメンバーによる改善だけでなく、 非フロントエンドの自分による簡素な手直しについても難易度が低く抑えられています。
デプロイ・プレビューに関する設計
ニジボックスでは、内部のクラウドリポジトリとして現在Bitbucketを利用しています。 BitbucketにはCIパイプライン機能としてBitbucket pipelinesが提供されており、 これによって特定ブランチへのコミットをそのまま公開状態としてデプロイする仕組みとなっています。
また、公開前の社内確認用としては「特定条件のブランチへのコミット」をトリガーに、 都度Cloud Runのサービスを作成してプレビュー可能な構成にしています。 Cloud Runは従量課金制のため、あまりコストを気にせずに環境の増減を行えるのがメリットとなっています。
終わりに
以上の設計・作業をもってリニューアルを行い、新しいデザインでのPOSTDをスタートさせることになりました。
ユーザー体験の向上を継続的に図りつつ、再び海外のエンジニアトレンドを紹介していきますので、よろしくお願いします。
関連記事
