Next.jsの代名詞「SSG」はやめた

WordPress+Next.jsだと、今のところ、もはや「SSR(Server Side Rendering)」しか選択肢がないくらいに思えます。

SSG(Static site Generation)はビルド時間が最悪。
- 最初は耐えられますが、記事はすぐに増えて、非常にストレスになる。

「ISR」もパッとしない(2021年初頭)。

Next.jsのISR(Incremental Static regeneration)は初回リクエストでSSRしてHtmlを生成&キャッシュします。

指定した時間はそのキャッシュされたデータを返しますが、指定時間を超えた場合はもう一度SSRする。→これは記事の執筆者によってトリガーされない(直感的ではない！)。revalidateが10秒とかならSSRでいいはず。

さらにVercelにデプロイしないと使えないみたい。。
VercelでDeployするより、しっかりDockerった方が何かあったときにすぐに対応できる。

SSRも少し冗長。。

SSGもISRもないのなら、SSRしかないです。

このサイトのDev BlogもSSRで実装されています。

getServerSideProps関数がリクエスト毎にデータを取得します。

何が問題かというと、

リクエスト → データ取得 → データのレスポンス → レンダリング(サーバーで) → レスポンス

の流れでは通信がリクエスト毎に2組の通信が走っています。そのせいで、ページの表示に一瞬の遅れが感じられます。

そこで、スーパーキャッシュシステムを作りました。

スーパーキャッシュシステム

「memory-cache」というnpm packageを使いました。参考URL

SSR時のデータ取得を、cacheがあればそこからcacheから、なければfetchする構成にしました。

import cacheData from "memory-cache";

// 第一引数にurl入れます。
// この関数をgetServerSidePropsの中でdata = await fetchWithCache(url);のように使用します。
export const fetchWithCache = async (input: Request | string, init?: RequestInit) => {
  const value = cacheData.get(input);
  if (value) {
    return value;
  } else {
    const res = await fetch(input, init);
    const data = await res.json();
    cacheData.put(input, data, 1000 * 60 * 60 * 24 * 15);
    return data;
  }
}

これのおかげで、2回目のアクセスのレスポンス速度が目に見えるように短縮されました。

 cacheData.put(input, data, 1000 * 60 * 60 * 24 * 15);

この部分は、半月(15日分)をセットしています。この関数はsetTimeoutを使用しており、setTimeoutでタイムアウトできるmaxの時間が

2147483647

なので、調整して15日にしてあります。

これだけではまだ解決していない。

もちろんcacheが存在していればcacheのデータを取得してレンダリングしますので、記事を更新したときに即座に反映されません。

先ほど設定したように15日間そのままです。

そこで、Next.jsのAPI作成の機能を利用しましょう！！

Next.jsには、API定義専用のディレクトリもデフォルトで備わっています。

root/pages/api

ディレクトリです。

ここに、cacheをクリアする関数を定義しておきます。

// (プロジェクトルート)/pages/api

import cacheData from "memory-cache";
import { NextApiRequest, NextApiResponse } from "next";

export default (req: NextApiRequest, res: NextApiResponse) => {
  cacheData.clear();
  res.status(204).send('');
}

このAPIに、記事の更新、投稿、削除、下書きに変更、などのタイミングでWeb hookで叩くようにします。

そうすれば、存在しているキャッシュが消去されて、リアルタイムで項目を確認できます。

リアルタイムに確認ができることがどれほど有難いことか、JAMStackにして初めてわかりました。

Next.jsは本当に優秀。さらによくなっていくはず！

Next.jsでSSRの上位互換、Super cache SSRを紹介しました。名前に関しては私たちが軽く命名しただけで、いつでも提案を承っております。

SSRの冗長性をmemory-cacheでカバーする構成は非常に今後も使えるな〜と思いました

ホームページの移行が完了しました🎉

本ホームページは、当初Nuxt.jsで作られていました。今ご覧になっていますDevBlogはGatsbyとGhostCMSという稀有な構成で構築していました。

よりシームレスに情報にアクセスしてもらうべく、ブログとホームページを統合しました🎉

今までの構成を捨てて、フロントはNext.js、CMSにWordpressでJAMStackな構成に仕上げました。

我が社は幅広いフレームワークに対応可能な集団ですなあ。

tag SSR