本ブログは3年前にGatsby.jsとGatsbyでブログを構築するためのテンプレートであるgatsby-starter-blogを用いて作成しました。

それ以降、少しずつ記事をアップしていましたが、いくつか問題点が生じていたため、アーキテクチャなどを再検討することにしました。

抱えていた問題点

最近感じていた課題は以下のようなものでした。

1. 記事がGitHub管理で気楽に更新できない
2. 記事更新にビルドが必要で不便
3. ライブラリ更新ができていない部分で表示にエラーが発生
4. gatsby-starter-blog のエコシステムの面倒臭さ

以上のような不満を抱くようになってきて記事の更新はおろか、ソースの修正等も放置する始末でした。

意識の持ち様でなんとでもなる！という精神論で片付ける事も出来ますが、技術者としては課題にテクニカルに対処する姿勢が重要だよなと一念発起し、見直しを始めました。

最大の課題

今回の見直しに際しての一番の課題は「記事更新が気軽でない」というものでした。

この問題の原因が、問題点1. の「記事がGitHub管理」と問題点2. の「記事更新にビルドが必要」であり、これらを解決したいと考えました。

以前は、ブログのソースと記事を同じリポジトリで管理し、Netlifyでデプロイをしていたため、記事を更新したいと思った際には手順として、

1. Notionで9割ほど書く
2. Notionからマークダウンファイルを出力する
3. 出力されたマークダウンをテキストエディタで加筆・修正する
4. リポジトリにプッシュする
5. Netlify でビルドが実行される

普段から本を読んだ時や調べ物をした時などには、メモをNotionで行っています。

また、NotionだとPCだけでなくスマホ・タブレットなどから編集できるため、新しい記事を作成する際には大枠はNotionで描き始めていました。

すでに身につけているメモの習慣にブログ記事の作成を近づけることでブログ更新頻度をあげる目的でした。

これは、始めうまく行きましたが、結局はそれ以降の2〜5のプロセスがPC以外から行えず、Notionに記事は書いたがブログに更新しないような事態も発生していました。

また、最終的な記事はGitHub管理ため、公開済みのブログはもはやNotionで編集できず、誤りの訂正や最新情報の追加なども疎かになっていました。

記事更新に最大限の気軽さを

ところで、Notionには公式のAPIがあります。

APIが公開された頃に、これを使ってNotionをHeadless CMSとして使うというのが流行ったかなと思います。

今回はこの方式を採用することで、記事更新をNotionに一本化することができると考えました。

また、記事更新にビルドが不要になり、更新頻度も上げることができそうです。

ということで要件としては、

1. Notionからブログ記事を追加できる
2. Notionから投稿済みの記事を更新できる
3. Notionから記事の公開・非公開を管理できる
4. 記事の更新にビルドが不要
5. これまでのマークダウンファイルの記事を引き継げる

ことになりました。

フロントエンドのフレームワーク

先述の通りブログの構築にはGatsbyJSを利用していました。

今回の要件の一つである「記事の更新にビルドが不要」という点に対処が難しいため、今回はGatsbyはフレームワーク不採用としました。

つまり完全なる新規の開発ですね！

では何を選んだのかというと、タイトルで判明していますが、NextJSを利用することにしました。

Notion APIを利用したブログ記事作成の方法

Notion API を使ったブログ記事の作成は調べると山ほど出て来ます。

代表的なものはこちらの公式サンプルです。デプロイ済みのサンプルもhttps://notion-blog-nextjs-coral.vercel.app/から確認できます。

こちらのサンプルから編集しても良いのですが、

1. Pages Routerを使ったサンプルである
2. マークダウンの記事とは共存できない
3. 良くも悪くも記事の管理が完全にNotion依存になる

という点において、今回は別の方法を考えました。

Notion→Markdown, Markdown→HTML

最終的には以下の図のような形になっています。

AWS LambdaからNotion APIを用いてページのデータを取得し、一度Markdownファイルに変換し、一度AWS S3に保存します。

そしてリクエストがあったタイミングでVercelにデプロイしたNext.jsから、Markdownファイルを取得しHTMLに変換、クライアントに表示する。

このような構成を取ることになりました。

2度変換を挟むような構成になっているため、手間は多いですが、利点も感じています。

Markdownを経由する利点

Markdownを経由する利点はいくつかあります。

1. 個々のブログ記事自体はNotionに依存しないため、過去のMarkdown記事を容易に移行できる
2. 記事の表示にzenn-markdown-htmlを利用できる
3. Notion APIへのアクセス回数をコントロールできる

などが挙げられます。

詳細は今後別の記事として書いていこうと思っていますが、

公式サンプルを参考に自力で要素ごとのタグを定義していくのはかなり面倒でしたので、

zenn-markdown-htmlで容易に美麗な記事生成が行えたのは大きな利点でした。

ちなみにNotionからMarkdownの変換はnotion-to-mdというライブラリをLambdaで実行していますので、

こちらもほとんど手がかかっていません。

まとめ

移行自体は時間がかかりましたが、なかなか満足のいく仕上がりになってきたように思います。

この記事もNotionで書いてそのまま投稿完了しました！なんて便利なんだ！

今後はコメント機能をつけたりタグを表示したりと自分が記事を書く上でテンションの上がる機能を追加していけたらなと思っています。

次回以降で、自分の備忘録も兼ねて、技術的な説明もしていけたらと思います。