このブログは

・Next.js ・Vercel ・Notion ( as Backend )

で作られています！

今回はこのブログで使われている技術について, 個人的に思ったメリデメや選定理由等をまとめました. 後編 (別記事予定) ではコードも交えて, どんな流れでブログが生成されているのかを解説します. その前に, 「なんでブログサービスを使わずに自作してるんや?」と思う方もいらっしゃると思うのでその説明をしておきます. このブログを自作した背景は 前回の記事 でチラっと触れましたが, 技術のお試し場であることが大きな理由です. あとは普通にデザインや機能を自分なりにカスタマイズ可能なところです. エンジニアの方は御存知の通り, Webフロントエンドは進化とトレンドの移り変わりが激しいレイヤです. その変化に対し, キャッチアップしてついていけるようにするには実際に触ってみるのが一番手っ取り早いと個人的には感じています. 個人でサービス開発していくのも一つの手ではありますが, 何か起きたときの影響範囲やスピードを考えると, ブログの自作の方が適していると思います. 「せっかくブログ書くなら, より多くの人に見てもらいたい」というのが目的であれば, SEOの強いはてなブログや note, Medium 等を使うといいでしょう. とまぁ長くなってしまいましたが, そんな感じのスタンスでブログを作っていますという話でした！ 本題に入ります〜

イマドキなら, ブログを作るときにまず考えるのは「Static Site Generator どうしよう?」というところではないでしょうか. jamstack.org のページ を見てみると, 数百もの generator が提供されているようです. 上部にあるものが有名どころで, Next.js や Hugo, Gatsby などがありますね. このブログは Next.js の SSG を使って作成されています. なぜ Next.js を選んだかを説明すると, 大きく2つのポイントがあります. ・筆者のスキルセット ・OSSとしての質や評価が高いと判断できる (Githubスター数, チームの開発スピード, 充実したドキュメント・実装例, 検索をかけたときの情報量など) 前者については「まぁそうだろう」って感じですが...😅 筆者はWebフロントエンドのスキルセットとして Typescript + React を得意としているので, ツール選定時はまずここでフィルタをかけています. このスキルセットなら Gatsby も候補に上がってくるので, Gatsby も使ったことはあります (プロダクション含む) . これは筆者自身の開発経験上の話ですが, Next.js は Gatsby と比べて, 👨‍💻 設定周りでやることが少ないのでコーディングに集中できる ⚡ レンダリングに関して取りうる選択肢が多い (パフォーマンスチューニングしやすい) という印象があります. 設定周りについては, わかりやすいところで言えば必要とされるファイル数が違います. Next.js は大体 next.config.js に集約されますが, Gatsby は gatsby-config.js, gatsby-browser.js, gatsby-node.js gatsby-ssr.js などがあります (すべて必要というわけではありません). 役割を分けるのは良いことではあるのですが, 設定ファイル自体そこまで触る機会がないので, いざ変更・バグ修正するとなったときに, 該当箇所を探す手間が少ない方がいいと個人的には思います. レンダリングに関して, Next.js は CSR (Client Side Rendering) はじめ, SSR (Server Side Rendering) も可能です. 更に v9.4 からは ISR (Incremental Static Regeneration) もサポートしています. ISR については後編で解説します. また, ページごとにレンダリングの種別を切り替えることができるので, CSR したほうがユーザ体験が良いページや, 確実に早く表示するために SSR, ISR を使って生成したいページなどを分けて実装することが可能です. これによって, 静的サイトのみならず動的なWebアプリケーション開発にも問題なく対応可能です. なので Next.js のメリットは, コーディングのスピードアップやユーザ体験向上が見込める, という点であると自分は考えます. 逆にデメリットは見当たらないのですが, 設定が少ない → 手の届かない部分がある, ということは考えられます, 出くわしたことはないのですが 😅 簡単ではありますが Next.js については以上です！

Vercel は, 前身の Now を含めると, 2016年頃 (のはず) に台頭したホスティングサービスです. 歴史は浅いものの, 非常に完成度の高いサービスで, 現代の JAMStack 構成のサイトを配信する上では最高峰に位置付けていると思います. 無料のプランでも, 複数サイトのデプロイ・カスタムドメイン・サーバレスファンクション・CDなどの機能を兼ね備えているので, 個人規模のプロダクトなら何の問題もなく利用可能です. Vercel を選んだ理由は, 今回のブログを作るに当たって意図的に ISR を使おうと思っていたのでほぼ一択だった, といった感じです. こちらのブログに書いてあるように, 他のホスティングサービスで ISR をやろうとすると結構面倒です. 後は何か問題があったとき, ググった時の情報量が Vercel + Next.js が一番多いというのもあります (同じ団体が作っているのでそりゃそうなんですが) . 他にも Netlify や Firebase Hosting などがあるので, 単純に静的サイトのみデプロイできれば良いのであれば, そっちでも可能なので是非試しに使ってみてください 💪🏻

ブログを作るに当たり, 手間がかかるのでDBを用意するという選択肢はありませんでした 🙄 今までは mdx を使って書いており, 1記事につき 1 mdx ファイル を作っていたのですが, ローカルにファイルが溜めていくのも限界があるのと, 検索の実装が面倒かもしれないということで mdx の選択肢もやめました. そこで思い立ったのが notion-blog で, ちょっと調べてみたら Notion の API を呼べることがわかったので, こいつをバックエンドにしてやろうじゃないかという結論にたどり着きました. ただし, これは非公式でトークンの取り扱いによっては危険性があるので, 自己責任で利用する形です (Next.js の ISR があるおかげで, クライアントにトークンを晒すことなくAPIが叩けます) . 今年の春に API のパブリックベータ版が使えるようになるっぽいので, それまでの繋ぎにする予定です. Notion でブログを書いた方はご存知だと思いますが, 文章やタイトル, 画像などを「ブロック」として埋め込んでコンテンツにしていくような形式なので, API で取得したデータはパースする作業が結構辛いです 😭 笑 まぁでもそれを乗り越えればサーバレスでブログを作れるので最高ですね！

ここまで, 主に使用したフレームワークやツールについて選定理由等を説明しました. 他に使用したモジュールで言えば styled-components くらいなので, 現状はこれらがブログの構成要素ほぼ全てです. ということで前編はこれで終わりですが, 後編はブログの作成からデプロイまでの流れを紹介していきたいと思います！ それでは〜 👋🏻