<p>JAMStack・・・JavaScript &#x2F; API &#x2F; Markupの頭文字。<br><br><span style="color:#1a202c">JavaScriptで外部APIを叩いてMarkup(HTML)を構成する技術のこと。</span><br><br>このブログはJAMStackな技術を用いて作成しました。<br><br>作るに至ったきっかけやメリット・デメリット、そこで得た知見などをブログ構築の一番手の選択肢であるWordPressと比較しながら紹介します。<br><br>そもそもJAMStackって何？という方は、先日2021年の「フロントエンドエンジニアに求められそうなスキル」という記事の中でJAMStackについて紹介している箇所があるので併せて読んでいただければと思います。<br><br><a href="https://blog-sorellina-coda.dev/articles/mi8bywjolf" target="_blank" rel="noopener noreferrer">https://blog-sorellina-coda.dev/articles/mi8bywjolf</a><br></p><h2 id="h27111e9216">なんでJAMStackで作ったの？</h2><p>イケてる技術＆好きな技術で自前のブログを作りたい！というのがモチベーションの源泉です。<br><br>以前Nuxt.js, Contentful, Netlifyを主に使ってブログを構築したこともありましたが、ブログそのものを更新しなくなってしまいました。<br><br>その前のブログをそのまま使うでもよかったかもしれませんが、</p><ul><li>今はReactが好きで、Next.jsのSSG&#x2F;ISGがブログに適しているので使いたかったこと</li><li>上記に付随して、個人的にVueベースのNuxtを使いたい要求が弱くなったこと≒メンテに対するモチベーションが沸かなくて辛い</li><li>以前のブログはCSSのパフォーマンスが悪く画面のチラつきが鬱陶しく感じていたこと</li><li>Contentfulが正直使いづらい(簡単にブログを更新したいだけなのに英語を読みながらコンテンツ管理したくない)</li></ul><p>という点から、Next.js &#x2F; TypeScript &#x2F; Vercel &#x2F; microCMSの構成で作り直すことにしました。<br><br>結果としてトップページ、記事ページともにLighthouseで高スコアが出るくらいの改善がなされました。<br><img src="https://images.microcms-assets.io/protected/ap-northeast-1:c7c8182c-88d5-4972-a4d4-22b5f7904ef2/service/gens-blog/media/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-01-23%2023.36.26.png" alt><br>やはり静的Webサイトの生成はパフォーマンスに優れていますね。<br><br>ページ遷移も非常にサクサクで、体験もよく感じています。</p><h2 id="hc3a07fcea1">WordPressじゃダメ？</h2><p>正直、ブログで収益化を目指すならWordPressで作った方が圧倒的に立ち上げが速いと思います。<br><br>ブログ向けのテーマやプラグインも充実していますし、事例も豊富です。<br><br>SEO対策もすでに整っているテーマなどが販売されていますし、WordPressブログは始めるだけならとても簡単です。<br><br>ただ、ページデザインの自由度はJAMStackブログに軍配が上がると思いますし、偏見が入りますがWordPressのセキュリティ対策が正直面倒に感じています。<br><br>今、個人開発でWordPressか...という若干過激派思想的な部分も正直あります。</p><h2 id="h72f4f74d01">JAMStackのメリット</h2><h3 id="hd10e8f1ec5">クライアントサイドでJAMStackブログは動くこと</h3><p>JAMStackのメリットは、SPA(Single Page Application)としてクライアントサイドで動くため、自前でサーバーを立てたりレンタルサーバーと契約する必要がないところです。<br><br>静的なアセットをVercelなどのホスティングサービスに乗せて配信しているだけなので、サーバーの管理をする必要がありません。<br><br>例えばWordPressだとサーバー側でページを構築するため、サーバーが停止してしまった場合にブログの読者にページを提供できなくなってしまいます。<br><br>JAMStackの場合、ページの構築はビルドを行うタイミングになるので、仮にサーバーが不具合で止まるとしても記事・ページを新しく作る段階で影響を受ける程度です。<br><br>すでに配信されているページには影響を受けません。<br><br>また、レンタルサーバーを契約すると大体月々1000円ほどかかる見込みですが、JAMStackなこのブログは<strong><s>「完全無料」</s></strong><s>で動いています。</s>ドメイン代で年1000円ちょっとかかってます🙇‍♂️<br><br>今後ブログを収益化すると考えるとこのランニングコストの差は大きいと思います。</p><h3 id="hddfe2d5fe8">セキュリティに対して比較的安全であること</h3><p>JAMStack構成ではサーバーを基本的に持たないため、攻撃の入り口になるような対象がなく、安全性を保ちやすくなります。<br><br>WordPressのセキュリティ対策が面倒と前述したのは、WordPressはサーバー上で動くためです。<br><br>世界の約3割のサイトがWordPressで構築されていると言われており、攻撃者からすればWordPressのサイトをターゲットにすることも多いです。<br><br>常々脆弱性対策をしなくてはならないのがWordPressのデメリットとも言えます。<br><br>ログインページを&#x2F;wp-admin&#x2F;のままにしていませんか？攻撃者の格好の的ですよ。</p><h3 id="h7d81356872">静的サイトのため高速</h3><p>JAMStack構成の場合、ページをサーバーからの返却ではなく静的アセットとして事前生成しておくことでCDN(<span style="color:#252525">Content Delivery Network</span>)から配信できるので非常に高速です。<br><br>サーバーでの処理を挟まないため高速化が実現できているというわけです。<br><br>ブログとしての用途だとコメント機能など一部例外はありますが、動的に値が変わる要素はほぼ無いので、オリジンサーバーを介して配信する必要がありません。<br><br>また、静的アセットの配置などもGithub連携などCI&#x2F;CDの構築が容易である点はメリットだと思います。</p><h3 id="hac760cc108">もしもの時に...</h3><p>JAMStackブログでは、View、API、ホスティングをそれぞれ別のサービスを用いて作るため、例えばViewのところが気に入らなくなった時に他のところは残して作り直すのが容易です。<br><br>例としてNext.js &#x2F; microCMS &#x2F; Vercelでこのブログは作っていますが、今後Next.jsが落ち目になり新しいフレームワークで作った方が良いとなれば、Next.jsの部分は他の技術に置き換えてmicroCMSでブログコンテンツの管理は続ける、ということが可能です。<br><br>各サービスで責務の分離がされているので障害時にも何が悪いかの切り分けがしやすいのもメリットだと思います。</p><h2 id="h7433da2982">JAMStackのデメリット</h2><h3 id="h4756a766cf">自分で作るものが多い</h3><p>WordPressには先人たちの作った数々のプラグインやテーマが存在するため、デザインを深く考えなくてもいい感じのブログが作れます。<br><br>一方JAMStackブログでは内部処理やUIコンポーネントはパッケージ、ライブラリとして提供されているものがあるものの、基本的には自分でページデザインを考え、コンテンツデータ取得の処理を書かなくてはならないため、構築まで時間がかかります。<br><br>WordPressならおそらく1時間もあればブログとしての体を成すものが作れると思いますが、JAMStackで0から作るとそれ相応の時間がかかります。<br><br>僕はいろいろ調べながら作って2〜3週間くらいでブログの体を成す形に仕上げました。</p><h3 id="h884039bc62">時間ぴったりにブログを公開するのが難しい</h3><p>JAMStackは作成したコンテンツを公開する際に、コードをビルドしてHTMLなど静的アセットを生成し配信しています。<br><br>コードのビルドがいつ終わるかはページ数次第なので、「17時ぴったりに情報解禁！」と思って17時に公開ボタンを押したとしてもビルドが終わるまでの数分間はページ表示ができません。<br><br>WordPressならコンテンツ公開の時点でサーバーにコンテンツを登録し、ユーザーが見に来たタイミングでページを作るので時間通りに公開も可能で、(調べてないので分かりませんが)タイマー配信もできるのではないでしょうか。</p><h3 id="ha93cad7d44">ページが多いとビルド完了まで時間がかかる</h3><p>先述の通りコンテンツ公開の都度全てのページに対してビルドを行なっているので、ページ数が多いと公開まで時間がかかってしまいます。<br><br>もちろんビルド中にはそれまでに公開しているコンテンツに影響は無いので個人ブログ程度の分量ならほぼ影響はありませんが、ニュースサイトのように莫大なページ数を持つWebサイトにはJAMStackは向いていないと言えます。</p><h3 id="ha96df7d158">選択肢が多い</h3><p>JAMStackではいくつかのサービス、フレームワークを組み合わせて構築するので、「どれを使って構築していいかわからない！」となる場合がありそうです。<br></p><ul><li>静的サイトジェネレータ： Next.js &#x2F; Nuxt.js &#x2F; Gatsby.jsなど</li><li>ヘッドレスCMS：microCMS &#x2F; Contentfulなど</li><li>ホスティングサービス：Vercel &#x2F; Netlify &#x2F; Firebase Hosting &#x2F; AWS S3など</li></ul><p><br>WordPressならWordPressだけで完結できるのでJAMStackのこのサービスの組み合わせは煩雑に写るかもしれません。<br><br>どの組み合わせがいいか迷ったときはNext &#x2F; microCMS &#x2F; Vercelで良いのではないでしょうか。<br><br>メリットのところでも書きましたが、合わなければそのサービスの部分だけ置き換えることも十分可能です。</p><h2 id="h157b8f3d90">これまでに得た知見</h2><p>ざっと箇条書きにします。</p><ul><li>CI &#x2F; CDの構築がとても簡単。WebhookでmicroCMSとVercelをつないでいるので、microCMSでコンテンツ公開すればすぐVercelでビルドを行ってくれる。</li><li>デザインからAPI構成まで自分で考える必要がある。コントロールが効きやすいので作ってて楽しい。</li><li>microCMSめちゃくちゃ使いやすい。個人的にはContentfulよりmicroCMSの方がいい。</li><li>SEO対策のためのコードやOGP画像生成を作るのはNext.jsの&#x2F;apiで行なった。</li><li>コードリファクタリングの余地がかなりあるので対応したい。</li><li>SEO対策用にAPIに概要欄を設けてdescriptionを書くようにしたのは効果がありそう。</li><li>サイトマップをどうやって作るかは模索中。</li><li>Webhookでブログの記事公開を検知させてNext.jsでSSGしているが、Webhook外してISRするのでもいいような気はしている。</li><li>難易度はめちゃくちゃ高いわけではない。フロントエンドエンジニアを目指したい初学者にはJAMStackブログの構築・運用をお勧めしたい。</li></ul><h2 id="ha214098e44">まとめ</h2><p>JAMStackは2021年現在、注目されている技術であり、ブログの構築の場合WordPressよりも運用コストは低いと考えています。(導入コストは若干高いですが...)<br><br>JAMStackブログの構築は以下のようにメリットが多くデメリットも実はほとんどない手法だと思います。</p><ul><li>クライアントサイドで動くためサーバーの管理が要らない</li><li>サーバーを持たないのでセキュアであるし、レンタルサーバー代もかからない</li><li>静的サイトなため非常に高速に描画が可能</li><li>自分で作るものが多いがプログラミングスキルアップに繋がる</li><li>ビルドに時間がかかったり時間通りに公開が難しいが、個人ブログには影響なし</li></ul><p><br>知見のところで述べましたが、フロントエンドエンジニアを目指したい人ほどJAMStαckでブログを立ててみるのは有効な気がしています。<br><br>Viewの部分はゴリゴリJSフレームワークを使って作りますし、APIとの接続≒バックエンドとの連携は現場で必ず使う技術ですし、ブログを立てた後はそこに学習記録を残していくことで求職時のアピールにも繋がります。<br><br>トレンドな技術でブログを立ててみたい！という気概があればぜひJAMStackに挑戦してみてはいかがでしょうか。</p>

<ol><li>なんでJAMStackで作ったの？</li><li>WordPressじゃダメ？</li><li>JAMStackのメリット</li><li>JAMStackのデメリット</li><li>これまでに得た知見</li><li>まとめ</li></ol>

JAMStackのメリット・デメリットを解説し、JAMStackでブログを作ることの有効性について書きました。JAMStackは2021年のフロントエンド技術トレンドとして上がってくると思っています。

JAMStackでブログを作った理由とそのメリット・デメリット − JAMStackはいいぞ

<p>先日「<a href="https://coliss.com/articles/build-websites/operation/work/front-end-developers-should-learn-in-2021.html" target="_blank" rel="noopener noreferrer">フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと</a>」という記事を読みました。<br><br>こちらの記事で挙げられている10個のポイントを踏まえて僕の考えを述べていきたいと思います。</p><h2 id="h13c3fb5a8b">フレームワーク</h2><p>近年React・Vue・Angularの三つ巴で推移していたJavaScriptフレームワーク・ライブラリですが、日本においてはReact・Vueの2強体勢になってきた印象を受けます。<br><br>Vueの方がタグテンプレート形式であるためHTML&#x2F;CSSに慣れたWebクリエイターの方でも触りやすい、理解しやすいという利点からデザイナーがHTML&#x2F;CSSを書くようなプロジェクトでは好まれて採用されるケースがあるようです。<br><br>一方でTypeScriptとの相性はReactに軍配が上がり、型安全でスケールしやすく開発効率が高いのはReactだと考えています。<br><br>個人的にはReactを推したいですが、2021年にから新たに学ぶのであればReact・Vueのどちらを採用しても有用であると言えます。<br><br>その他の選択肢としてSvelteも名前が上がるようになってきていますが市民権を得るにはもう少し時間がかかりそうですね。</p><h2 id="h413687ae4c">静的サイトジェネレーター（SSG）</h2><p>JavaScriptフレームワークで開発されるSPAの弱点として初回ローディングの遅さやSEOの対策などが挙げられますが、アプリのビルド時に静的なファイルとして書き出すStatic Site Generation(SSG)と言う手法でその弱点を回避することができます。<br><br>静的なHTMLファイルとして書き出されるので、CDNにキャッシュを配置しておけるし、ページ遷移時にはSPAとして動的に変更ができるので非常に高速です。<br><br>少し前はReact製でSSGするならGatsby.js、と言う情勢でしたが、特に注目しているのがNext.jsです。<br><br>Next.jsはServer Side Renderingが主のフレームワークでしたが最近はSSGを推しているようで、<span style="color:#333333">Incremental Static Regeneration(ISR)が注目されていますね。</span><br><br>SSGの弱点がアプリのビルド時に全てのページを再出力する必要がある点でしたが、ISRでは設定した一定時間ごとにバックグラウンドでデータの再取得・HTMLの再生成が行われます。<br><br>こうすることでアプリ全体を都度再ビルドすることなく変更を反映させることができるのが利点です。</p><h2 id="he8f868b3f5">JAMStack</h2><p>JAMとはJavaScript、API、Markupの頭文字で、JavaScriptで外部APIを叩いてMarkup(HTML)を構成することを意味しています。<br><br>主に静的サイトジェネレーター、ヘッドレスCMS、ホスティングサービスを使って構築されます。<br><br>ヘッドレスCMSで入力フォームを作成し、サービスで使うコンテンツをまとめ、APIとして公開します。<br><br>静的サイトジェネレーターでアプリをビルドする際にAPIを叩いてコンテンツを取得、HTMLなど静的コンテンツを生成します。<br><br>そして生成した静的コンテンツをホスティングサービスから配信します。<br><br>ほぼGitでマネジメントができるので開発効率も非常に良いですね。<br><br>ヘッドレスCMSはmicroCMS、Contentfulなどが有名どころで、microCMSは日本製と言うこともあり情報にリーチしやすく重宝しています。<br><br>静的サイトジェネレーターは上述の通り。Next.jsが個人的にはアツいです。<br><br>そしてホスティングサービスはNetlifyやFirebase Hostingなどがありますが、Next.jsを使うのであればVercel1択だと思っています。<br><br>Vercel社がNext.jsの開発母体と言うこともあり、VercelにNext.jsアプリを乗せればよしなにやってくれることが非常に多く、あえて他のホスティングサービスを利用する理由が見つかりません。<br><br>このブログは上述のSSG及びISRを取り入れ、Next.js×microCMS×VercelのJAMStackな技術スタックで開発されています。<br><br>開発体験もユーザー体験も上々だと感じているので、しばらくはNext.jsとVercelでWebアプリやWebサイトを開発していきたいなと思っています。</p><h2 id="h1e7d0998b4">プログレッシブウェブアプリ（PWA）</h2><p>Progressive Web Application(PWA)はWebアプリケーションをiPhoneやAndroidのネイティブアプリのように提供できる技術で、Webとスマホアプリの両面を兼ね備えたようなアプリです。<br><br>AppStoreからのインストールも不要でホーム画面へのアイコン追加やプッシュ通知ができるなど、ネイティブアプリのような使用感を得ることができます。<br><br>常々注目はされている技術ではありますが、スマホユーザー側にそれほど認知されていないようで普及が進んでいません。<br><br>また、執筆時点でPWAに必要なService Workerと言う技術がSafariに対応しておらず、iPhoneがシェアを多く占める日本のスマホ市場では向かい風な状況なのかもしれません。</p><h2 id="h12e6136e43">GraphQL</h2><p>GraphQLはFacebookが開発しているWeb APIのための規格で、クエリとレスポンスデータの構造が似ていること、スキーマによる型付けができることが特徴です。<br><br>クライアント側はシンプルに書けること、そしてREST APIと違ってエンドポイントが1点となることから複数のAPIを叩いてデータを統合して...と言うことをしなくてよいのが利点だと考えています。<br><br>1回のリクエストで必要なデータのみ取得することが可能なのがREST APIでの構築との違いだと思います。<br><br>ただ、サーバー側のリゾルバーを書くのがクライアント側に比べると複雑で、N+1 SQL問題が発生しやすいと言うのが難点です。<br><br>リゾルバーを書くのをマネージドにするためにHasura GraphQL Engineが個人的には良いソリューションなのではと思っていて、PostgreSQLまたはMySQLのデータソースを元にGraphQLのリゾルバーを自動生成してくれるので、バックエンド側で複雑なことをしない限りは有用な選択肢だと考えています。<br><br>Hasuraは注目するだけしてまだアプリに落とし込めていないのでしっかりと運用してみたいと思います。</p><h2 id="h48d7d178c7">コードエディタ&#x2F;IDE</h2><p>記事同様、VSCodeで十分すぎるパワーがあると思っています。<br><br>WebStormのようなJet Brains製品のような有料エディタも非常に有用なのですが、拡張性の高いエディタが無料で使え、有料のエディタと遜色ない点がVSCodeを使う理由です。<br><br>LiveShareの機能でオンラインペアプログラミングもできる優れものです。</p><h2 id="h3dfa11cabe">テスト環境</h2><p>フロントエンドのテスト、特にビジュアルは変更が多いため「テストなんて書いてもなぁ...」などと言われたこともありますが、開発中に予期せぬエラーを見つけやすくなったり、コードレベルでの機能の担保ができるのは大きな利点です。<br><br>(目視とExcelへのスクショを貼りまくったSIer時代を思い出す...)<br><br>テストを書かぬままのコード変更はリファクタリングではなくただの破壊的変更だ、と言うことも聞いたことがあります。<br><br>Storybookを使ったUIコンポーネントテスト、Jestでのユニットテストやスナップショットテスト、React-testing-libraryでの結合テスト、SeleniumでのE2Eテストなど、アプリ品質を確保するためにも使いこなせるようになりたいですね。</p><h2 id="h49d93d0381">クリーンなコード</h2><p>リーダブルコードを読みましょう。随分前の書物にはなってしまっていますが、「なぜクリーンなコードを書くべきか」概念は掴めるはずです。<br><br>エンジニアとして働くと、コードを書く時間よりも調べたり既存資産のコードを読む時間の方が長かったりします。<br><br>そして自分が書いたコードですら人間は愚かなので意図を忘れるのです。<br><br>変数名が省略されていたり一つの関数に複数の意味があるようなものを作らないなど、日々気をつけて開発したいですね。</p><h2 id="h7343673ad5">Git</h2><p>複数人で開発する上でGitを使わない開発はほぼないと言えます。もちろん個人開発でもGitは必須です。<br><br>記事にないGitコマンドの中では最近amendやrebaseはよく使っています。コミットログの変更・修正になるので使い所は考える必要がありますが、コミットログと言うプロジェクトコードの歴史はきれいに管理していきたいですね。 </p><h2 id="h6025f90d75">ソフトスキル</h2><p>上記の中でも最も必須スキルだと思います。<br><br>エンジニアはただパソコンを前にして一人で開発だけを進める仕事ではなく、複数人のチームで進めていくことが主になります。<br><br>特にリモートワークが普及しつつある昨今、オンラインでのコミュニケーションをいかにとることができるかは重要視されていると思います。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>10つのスキル、2021年のフロントエンドエンジニアに求められるものとしてとても共感できるものでした。<br><br>付け加えるとしたらTypeScriptですかね？もはや当たり前だと言うことで元記事には挙げられていないのかもしれませんが。<br><br>PWAやGraphQLはまだまだ自分にとって知識不足だと思いましたし、フレームワークなどわかったつもりになっている技術もあると思います。<br><br>フロントエンドフレームワークは今年も引き続きNext.jsに注目していきたいなと思っています。<br><br>基礎を疎かにせずこれからも精進していきたいですね。</p>

<ol><li>フレームワーク</li><li>静的サイトジェネレーター（SSG）</li><li>JAMStack</li><li>プログレッシブウェブアプリ（PWA）</li><li>GraphQL</li><li>コードエディタ&#x2F;IDE</li><li>テスト環境</li><li>クリーンなコード</li><li>Git</li><li>ソフトスキル</li><li>終わりに</li></ol><p><br></p>

「フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと」を読んで、フロントエンドエンジニアが2021年に求められそうなスキルについて自分の考えを書きました。

JAMStackでブログを作った理由とそのメリット・デメリット − JAMStackはいいぞ

2021年のフロントエンドエンジニアに求められそうなスキル