JAMStackで開発したプロダクトで使った技術スタックとpros,cons

この記事は、ハシゴ Advent Calendar 2020の 1 日目の記事です。

現在弊社では、自社メディアとしてKANSAI STARTUP NEWS、FUKUOKA STARTUP NEWSを展開しています。

本メディアはスタートアップ企業にフォーカスした WEB メディアで、起業家のインタビュー記事を中心に発信しており、2020 年 5 月にファーストリリースを行い、2020 年 10 月にフルリニューアルを行いました。

リリースわずか 5 ヶ月でフルリニューアルとかやる気マンマンですね（違

本記事では、プロダクトに採用した技術スタックと、pros/cons をお伝えします。なお、明日以降も本プロダクトの話は続くので、本記事は overview 的な立ち位置となります。

技術スタック

本プロダクトでは、主に以下の技術を採用して開発を行いました。所謂 JAMStack な構成です。

Gridsome / Vue.js
Tailwind CSS
Contentful
AWS Amplify

それぞれ採用した経緯を簡単にお伝えしておきます。

まず Gridsome に関してですが、界隈では Gatsby が圧倒的に人気です。ただ、当時担当していた別プロダクトで Vue.js を採用していたこともあり、学習コストやコンテキストスイッチを鑑みた結果、「Vue.js がいいよね」ということで、Vue.js の SSG である Gridsome を採用しました（僕が個人ブログで使ったことがあったっていうのも多少影響しています）。

Tailwind CSS は、個人的にずっと気になっていた CSS framework だったので、半ば強引（？）に採用しました。結果としては大正解で、導入初期の学習コストこそあったものの、CSS Styling が圧倒的に楽になりました。

Contentful と Amplify は社内別プロジェクトが採用していたこともあって、脳死で使った感じですね。

※細かい部分でいうと、chromatic で UI のリグレッションテストをしたり、Lighthouse CI でパフォーマンスのチェックをしたり、ship.js でリリースの自動化も行ったりしています。

では以下で、採用したそれぞれについて pros/cons を記載していきます。

Pros

AWS Amplify の DX は素晴らしい

ゼロコーディングで GitHub と繋がって、push したら deploy されて、さらには Pull Request 立てたら preview 環境も作ってくれるという至れり尽くせりな状態で、インフラのことを何も考えなくていいのは、非常に楽でした。

これを全部自前でやろうとすると、S3 + CloudFront を立てて、Code シリーズで Pipeline 組んで…というのをやらないといけないわけで、その部分の一切を面倒見てくれるのはかなり助かります（まぁ Terraform とかで一回組んじゃえば使い回せますが）。

ただ一方で Amplify のウラに立ってるであろう S3 や CloudFront に関しては完全に隠蔽されている（AWS の画面上にも出てこない）ので、細かくカスタマイズが必要なケースだとちょっと向かないかもしれません（例えば GIP でアクセス制限かけたいとか）。

今回のケースだと、そういう細かいのは一切不要だったので、完全に Amplify に乗り切ってインフラにかかる開発コストが圧倒的に低く済みました。

実際は CDK を使って構築していますが、ぶっちゃけこれくらいだったら IaC じゃなくてもいいかもです。

Tailwind CSS の DX は素晴らしい

鳴り物入りで導入した Tailwind CSS ですが、結果的にかなり手に馴染みました。

class を付けて css を当てていくよくあるスタイルなんですが、デフォルトで用意されているものの使い勝手もいいし、自分で拡張していけるのも、メンテナンス性を維持できる感じがしました。

例えば以下のコードはある Component の一部抜粋ですが、

<template>
  <time
    class="bg-theme-secondary text-white"
    :datetime="datetime | formatDatetime"
  >
    {{ datetime | formatDatetime("YYYY.MM.DD") }}
  </time>
</template>

text-whiteはデフォルトで用意されている class で、以下の定義があたっています。

.text-white {
  --text-opacity: 1;
  color: #fff;
  color: rgba(255, 255, 255, var(--text-opacity));
}

bg-theme-secondaryは拡張したカラースキーマで、以下の定義があたっています。

.bg-theme-secondary {
  --bg-opacity: 1;
  background-color: #00bfd7;
  background-color: rgba(0, 191, 215, var(--bg-opacity));
}

もちろん全てを Tailwind CSS の class として定義することも出来ますが、過剰にやりすぎてもあまりメリットがないので、再利用性の低そうなものに関しては、普通に Component 内に css を書いています。

Cons

Gridsome がまだ成熟しきっていない

ここに関しては、以前「gridsome-source-google-analytics-reporting-api を公開しました」でもお伝えしましたが、やはり Gatsby と比較してしまうと、圧倒的にまだまだかな、という感じがします。

プラグインの数もそうですが、プラグインの質で見ても、Gatsby のプラグインの方が高機能…なんてことは、結構ザラにありました。

まぁなければ作ればいいだけなので、実装上困るってことはないんですが、逐一作ってたらいくら時間があっても足りないので、エコシステムが成熟してるかどうかってのは大事ですよね。ビジネスに求められるスピードもあるので。

とはいえ、普通あるよねって感じのもの（Google Analytics とか manifest.json とか RSS とかのプラグイン）に関しては漏れなく網羅されているので、あまり凝ったことをしない限りはカバーできる気はします。

実際不足していたプラグインは、上記の記事で紹介したものくらいでした。

Contentful のマイグレーションはやや煩雑

リニューアルに際して大幅に Contentful も変更することにしたので、結構がっつりマイグレーション書いたんですが、正直ちょっとやりづらいと感じる部分が多かったです。

例えば、フィールドの定義は以下のような感じで書いていくんですが、typeって何渡せばいいの…？みたいなのがドキュメントとにらめっこしながらじゃないとわからないんですよね。

column
  .createField("eyeCatch")
  .name("eye_catch")
  .type("Link")
  .localized(false)
  .required(true)
  .validations([
    {
      linkMimetypeGroup: ["image"],
    },
  ])
  .disabled(false)
  .omitted(false)
  .linkType("Asset");

まぁこういうもんって言われたらなんとも言えないんですが、CDK みたいな感じで、ドキュメントなくても書けるみたいな感じだったらもっとよかったなーと思いました。最終的には、一旦手で雑に作ったものを引っこ抜いて、よしなに修正していくというアプローチで作っていきました。

ただ、そんなに頻繁に変えるものでもないし、許容範囲ではあると思います。Contentful 上で environment 切れるので、気兼ねなく試すことも出来ますし（フルで使い切ってたら…上位プランにアップグレードしてください…）。

おわりに

overview ということで、あまり細かい実装の部分には触れていませんが、全体感は伝わったのではないでしょうか。明日以降で、もうちょっと突っ込んだ形でご紹介していくので、お楽しみに:)