<p>
  以前、弊社のお問い合わせ機能は、AWS Lightsail 上に Docker Compose で構築した環境で運用していました。Python + Django、MySQL、Nginx を組み合わせた、一般的な Web アプリケーション構成です。
</p>

<p>
  当時は Django や Docker、サーバー運用への理解を深める目的もあり、この構成には学習上の意味がありました。ただ、現在のお問い合わせ機能に求められているのは、フォームの送信内容を受け取って保存し、確認メールと社内通知メールを送るという、比較的ミニマムな処理です。
</p>

<p>
  あらためて振り返ると、「この規模の機能のためだけに Django アプリケーションを用意し、サーバーを立て続ける必要があるのか」という疑問が出てきました。学習目的としては十分に意味があった一方、現時点では運用・保守の負担が機能の規模に対して相対的に大きくなっていました。
</p>

<p>
  そこで今回、お問い合わせ機能を Hono・Cloudflare Workers・Cloudflare D1 を使ったサーバーレス構成に置き換えることにしました。メール送信については、従来通り AWS SES を利用しています。
</p>

<h2>以前の構成</h2>

<p>
  以前のお問い合わせ機能は、AWS Lightsail 上で Docker Compose を使って構築していました。
</p>

<syntax filename="以前の構成イメージ" language="plaintext">
AWS Lightsail
├── Nginx
├── Django
└── MySQL
</syntax>

<p>
  Django 側でフォームの POST を受け取り、MySQL に保存し、メール送信処理を行う構成です。Web アプリケーションとしては自然な形ですが、現在のお問い合わせ機能に必要な処理と照らし合わせると、やや大がかりに感じていました。
</p>

<p>具体的には、次のような点が気になっていました。</p>

<ol>
  <li>お問い合わせ機能だけのために Django アプリケーションを維持している</li>
  <li>Lightsail インスタンス、Nginx、MySQL、Docker Compose の運用が必要</li>
  <li>OS やミドルウェアの更新、プロセス監視などを継続的に意識する必要がある</li>
  <li>機能の規模に対して、構成が重くなっている</li>
</ol>

<p>
  Django は非常に優れたフレームワークで、管理画面や認証、複雑な業務ロジックを持つアプリケーションでは今でも有力な選択肢です。ただ、「フォームを受け付けて保存し、メールを送る」だけの用途に絞れば、もう少し軽い構成でも十分に対応できると考えました。
</p>

<h2>新しい構成</h2>

<p>今回採用した構成は次のとおりです。</p>

<syntax filename="新しい構成イメージ" language="plaintext">
Frontend
  ↓
Cloudflare Workers + Hono
  ↓
Cloudflare D1

Cloudflare Workers
  ↓
AWS SES
</syntax>

<p>
  フロントエンドから送信されたお問い合わせ内容を Cloudflare Workers で受け取り、Hono でルーティングと入力値の検証を行い、Cloudflare D1 に保存します。その後、AWS SES を使ってお問い合わせ者への確認メールと社内向けの通知メールを送信します。
</p>

<p>
  大きな Web アプリケーションサーバーを立てるのではなく、必要な処理だけを Worker 上で完結させる構成です。
</p>

<h2>Hono / Cloudflare Workers / D1 を採用した理由</h2>

<h3>ミニマムに実装できる</h3>

<p>お問い合わせ機能に必要な処理は、主に次の 3 つです。</p>

<ul>
  <li>フォームの入力値を受け取る</li>
  <li>内容を検証して DB に保存する</li>
  <li>確認メール・通知メールを送る</li>
</ul>

<p>
  この程度の処理であれば、フルスタックな Web フレームワークや常時起動するサーバーは必要ありません。Cloudflare Workers はリクエストが来たときだけ処理を実行するため、インフラ管理の負担を大きく減らせます。
</p>

<h3>TypeScript で書ける</h3>

<p>
  弊社の自社サイトや周辺の Web アプリケーションでは、Next.js や React を利用しています。フロントエンドと同じ TypeScript でバックエンドの処理を書けることは、技術スタックの統一という観点で素直に利点でした。
</p>

<p>
  Django / Python での実装と比べると、フロントエンドとバックエンドで言語や型の扱いを揃えやすくなります。フォームの入力項目とバックエンドのスキーマが密接に関係する箇所では、この一貫性が実装の見通しをよくしてくれます。
</p>

<h3>Hono が軽量で扱いやすい</h3>

<p>
  Hono は、Cloudflare Workers などの Edge Runtime で動作する軽量な Web フレームワークです。Express に近い感覚でルーティングを書けるうえに Workers 環境との相性がよく、今回のような小さな API には適切な選択肢でした。
</p>

<p>
  ルーティングや CORS の設定、バリデーションとの組み合わせもシンプルに記述できます。必要なエンドポイントだけを定義する、という小さな構成にちょうどよくフィットしました。
</p>

<syntax filename="src/index.ts" language="typescript">
const app = new Hono();

app.use("/contact", cors(/* 許可するオリジンを設定 */));

app.post("/contact", validateRequest, async (c) => {
  // 入力値を検証する
  // D1 に保存する
  // メール送信処理を予約する
  // レスポンスを返す
});
</syntax>

<p>
  実際の実装では、許可するオリジンを環境変数から読み込み、お問い合わせフォームを設置しているドメインからのリクエストだけを受け付けるようにしています。
</p>

<h3>Cloudflare D1 で十分だった</h3>

<p>
  お問い合わせデータの保存先には Cloudflare D1 を採用しました。D1 は Cloudflare が提供する SQLite ベースのサーバーレスデータベースです。
</p>

<p>
  今回の要件はシンプルで、送信された氏名・メールアドレス・会社名・住所・件名・本文などを保存できれば十分です。
</p>

<syntax filename="migrations/table.sql" language="sql">
CREATE TABLE inquiries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL,
  email TEXT NOT NULL,
  organization TEXT,
  subject TEXT NOT NULL,
  content TEXT NOT NULL,
  created_at TEXT NOT NULL
);
</syntax>

<p>
  実際には氏名の姓・名、ふりがな、住所の各項目など、フォームに合わせてもう少しカラムを細かく分けています。ただデータ構造としてはシンプルであり、常時稼働する MySQL サーバーを管理するほどの複雑さはありません。D1 を使うことで、データベースプロセスの管理を意識せずに済むようになりました。
</p>

<h2>ローカル開発環境について</h2>

<p>
  Cloudflare Workers の開発には、公式 CLI ツールの Wrangler を使っています。
  <code>wrangler dev</code> コマンドを実行すると、Workers のランタイムをローカルでエミュレートした
  開発サーバーが起動します。
</p>

<p>
  D1 についても、Wrangler はローカル上に SQLite のモック環境を自動的に用意してくれます。
  <code>wrangler.toml</code> に D1 バインディングを定義しておけば、
  ローカル実行時にはその設定に従ってローカルの SQLite ファイルが使われ、
  実際の D1 データベースには影響しません。
</p>

<syntax filename="wrangler.toml" language="toml">
[[d1_databases]]
binding = "DB"
database_name = "inquiries-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
</syntax>

<p>
  マイグレーションも Wrangler から実行できます。
  <code>--local</code> オプションを付けることで、ローカルのモック環境に対してのみ適用され、
  本番の D1 は変更されません。
</p>

<syntax language="bash">
# ローカル環境にマイグレーションを適用
wrangler d1 migrations apply inquiries-db --local

# 本番環境に適用する場合は --local なし
wrangler d1 migrations apply inquiries-db
</syntax>

<p>
  ローカル開発時の環境変数は <code>.dev.vars</code> ファイルに記述します。
  このファイルは <code>.gitignore</code> に追加しておき、リポジトリには含めないようにします。
  本番の secret との対応関係が明確になるため、どの値をローカルで差し替えているかも把握しやすくなります。
</p>

<syntax filename=".dev.vars" language="plaintext">
TURNSTILE_SECRET_KEY=1x0000000000000000000000000000000AA
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
SENDER_EMAIL=dev@example.com
NOTIFY_EMAIL=dev-internal@example.com
ALLOWED_ORIGIN=http://localhost:3000
</syntax>

<p>
  Turnstile については、Cloudflare がテスト用のシークレットキーとサイトキーを公式に提供しています。
  ローカル開発時はこのテスト用キーを使うと、実際のチャレンジを経由せずに検証が常に成功するため、
  フォームの動作確認がしやすくなります。
</p>

<h2>実装の流れ</h2>

<h3>入力値を検証する</h3>

<p>
  フォームから送信される値の検証には Zod を利用しています。Hono と Zod を組み合わせることで、リクエストの JSON を受け取った段階で、必須項目やメールアドレス形式、本文の最大文字数などをまとめて確認できます。
</p>

<syntax filename="src/routes/contact/schema.ts" language="typescript">
const InquirySchema = z.object({
  name: z.string().min(1),
  email: z.email(),
  organization: z.string().optional(),
  subject: z.string().min(1),
  content: z.string().min(1).max(2000),
});
</syntax>

<p>
  実際のフォームでは氏名・ふりがな・住所・電話番号など、もう少し多くの項目を扱っています。スキーマとして一箇所に定義しておくと、どの項目が必須でどれが任意かが一目でわかるため、フォームとの整合性も確認しやすくなります。
</p>

<h3>Turnstile でボット送信を防ぐ</h3>

<p>
  フォームのボット送信対策として、Cloudflare Turnstile を導入しています。
  Turnstile は reCAPTCHA の代替として Cloudflare が提供するチャレンジ機能で、
  フロントエンド側でトークンを取得し、バックエンドでその有効性を検証する形をとります。
</p>

<p>
  Workers 側では、フォームのデータを受け取った後、まず Turnstile のシークレットキーを使って
  トークンの検証リクエストを Cloudflare のエンドポイントに送ります。
  検証が通らなかった場合はそこで処理を打ち切り、D1 への保存もメール送信も行いません。
</p>

<syntax filename="src/routes/contact/index.ts" language="typescript">
const verifyRes = await fetch(
  "https://challenges.cloudflare.com/turnstile/v0/siteverify",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      secret: c.env.TURNSTILE_SECRET_KEY,
      response: body.turnstileToken,
    }),
  }
);

const { success } = await verifyRes.json<{ success: boolean }>();
if (!success) {
  return c.json({ error: "ボット判定されました。時間をおいて再度お試しください。" }, 400);
}
</syntax>

<p>
  Turnstile のシークレットキーは他のクレデンシャルと同様に Cloudflare Workers の
  secret として設定し、アプリケーションコードには直接含めていません。
</p>

<h3>D1 に保存する</h3>

<p>
  検証を通過したデータは Cloudflare D1 に保存します。Workers では D1 を binding として扱えるため、環境変数経由でデータベースにアクセスできます。
</p>

<syntax filename="src/routes/contact/index.ts" language="typescript">
await db
  .prepare("INSERT INTO inquiries (...) VALUES (...)")
  .bind(/* フォームから受け取った値 */)
  .run();
</syntax>

<p>
  SQL を直接実行する形ですが、今回のような小さな用途では十分に見通しよく書けます。保存に失敗した場合はエラーレスポンスを返し、成功した場合のみメール送信処理に進む流れにしています。
</p>

<h3>メール送信を予約する</h3>

<p>
  お問い合わせを保存した後は、AWS SES を使ってメールを送信します。送信するのは、お問い合わせ者への受付確認メールと、社内向けの通知メールの 2 通です。
</p>

<p>
  メール送信は API のレスポンスを遅らせないよう、Workers のバックグラウンド処理として実行しています。
</p>

<syntax filename="src/routes/contact/index.ts" language="typescript">
c.executionCtx.waitUntil(
  Promise.all([
    sendConfirmationMail(/* お問い合わせ者宛 */),
    sendInternalNotification(/* 社内通知宛 */),
  ]),
);
</syntax>

<p>
  <code>waitUntil</code> を使うことで、レスポンスを返した後も Worker 側で処理を継続できます。ユーザーへはできるだけ早く送信完了を返しつつ、メール送信も確実に行いたい場面では、この仕組みがよく合います。
</p>

<h2>AWS SES を使った理由</h2>

<p>
  メール送信については、移行後も AWS SES を引き続き利用しています。もともと使っていた送信基盤をそのまま活かせること、送信元ドメインやメールアドレスの管理をそのまま継続できることが主な理由です。
</p>

<p>
  Cloudflare Workers から AWS SES を呼び出す際には、AWS の署名付きリクエストを作成する必要があります。今回はその部分を扱いやすくするためのライブラリを利用し、Worker から SES の API を呼び出す形にしました。
</p>

<syntax filename="src/routes/contact/mailer.ts" language="typescript">
const client = createAwsClient({
  region: "ap-northeast-1",
  service: "ses",
});

await client.fetch(sesEndpoint, {
  method: "POST",
  body: buildSesRequestBody(/* 宛先・件名・本文 */),
});
</syntax>

<p>
  アクセスキーや送信元メールアドレスなどは環境変数として管理し、アプリケーションコードには直接書かずに Cloudflare 側の secret として設定しています。
</p>

<h2>環境変数で管理するもの</h2>

<p>今回の構成では、次の値を主に環境変数として管理しています。</p>

<ol>
  <li>CORS で許可するオリジン</li>
  <li>AWS のアクセスキー</li>
  <li>送信元メールアドレス</li>
  <li>社内通知用のメールアドレス</li>
  <li>Turnstileのシークレットキー</li>
</ol>

<p>
  ローカル開発時は開発用の環境変数ファイルを使い、本番環境では Cloudflare Workers の secret として設定します。機密情報をソースコードに含めずに運用できる点は、チームで扱う際にも安心です。
</p>

<h2>移行してよかった点</h2>

<p>
  Django + MySQL + Nginx + Docker Compose + Lightsail の構成から、Hono + Cloudflare Workers + D1 へ移行したことで、全体の構成はかなりすっきりしました。
</p>

<ol>
  <li>サーバーを常時起動しなくてよくなった</li>
  <li>OS やミドルウェアの保守を意識する場面が減った</li>
  <li>TypeScript で小さく実装できた</li>
  <li>フロントエンド側の技術スタックと統一感が出た</li>
  <li>D1 により、シンプルなデータ保存をサーバーレスで実現できた</li>
  <li>メール送信をレスポンス後の非同期処理として自然に扱えた</li>
</ol>

<p>
  特に、お問い合わせフォームのような小規模なバックエンド機能では、サーバーを持たない構成にするだけで、日常的な保守への心理的負荷もかなり下がりました。
</p>

<h2>あえて Django を使わない判断</h2>

<p>
  今回の移行は、Django が不要だという話ではありません。管理画面・ORM・認証・権限管理が一通り揃った Django は、ある程度規模のある業務アプリケーションや、管理画面を含むシステムでは今でも有力な選択肢です。
</p>

<p>
  ただ今回のお問い合わせ機能に必要だったのは、入力を受け取り、保存し、メールを送るという限定的な処理でした。それだけのためにアプリケーションサーバーを維持し続けるのは、現在の要件に対して少し大きすぎると判断しました。
</p>

<p>
  技術選定において重要なのは、技術そのものの優劣ではなく、対象となる機能の規模や運用体制に合っているかどうかです。今回の用途では、Hono・Cloudflare Workers・D1 の組み合わせがちょうどよいサイズ感でした。
</p>

<h2>まとめ</h2>

<p>
  今回は、弊社のお問い合わせ機能を Lightsail + Docker Compose + Django + MySQL + Nginx の構成から、Hono + Cloudflare Workers + D1 のサーバーレス構成に置き換えた経緯と実装方針を紹介しました。
</p>

<p>
  当初の Django 構成は、学習目的も含めて意味のある選択でした。ただ、現在のお問い合わせ機能の規模を考えると、サーバーを立てて運用し続けるよりも、Cloudflare Workers 上でミニマムに実装する方が実態に合っています。
</p>

<p>
  Hono は軽量で扱いやすく、TypeScript で書けるため Next.js などを使っているプロジェクトとの相性もよいと感じています。Cloudflare D1 を組み合わせれば、簡単なデータ保存もサーバーレスで完結します。
</p>

<p>
  お問い合わせフォームのような小さなバックエンド機能であれば、Hono・Cloudflare Workers・D1・AWS SES の組み合わせは、運用コストと実装のシンプルさのバランスがよく取れた構成だと思います。
</p>

お問い合わせ機能だけのためのサーバー運用をやめた話

<p> 以前のウェブサイトもNext.js（バックエンドとしてWordPress）を使用していましたが、この度、株式会社登紀わの自社ホームページをリニューアルするにあたって、デザイン面・内容面だけではなく、ブログ機能やお問い合わせ機能についても見直しました。その取り組みを順次ご紹介します。
</p>
<p>
  今回は、弊社の「おしらせ」ページをContentfulで実現したその方法をご紹介します。
</p>

<h2>
  Next.js採用の理由
</h2>

<p>
  TutorDirectなど、自社にて作成するウェブアプリケーションのフロントエンドのフレームワークとしてNext.js（React）を採用しており、その技術的な理解を深めるために、自社ページもNext.jsで作成することにしました。
</p>
<p>
    このウェブサイトも、Next.js（14.0.3）で作成されています。ルーティングにはpages routerを使用しており、以下のNext.jsに関する説明でも同様とします。
</p>

<h2>
  Contentful採用の理由
</h2>

<p>
リプレイス前のホームページでも、ニュース配信用にブログ機能を持たせており、そのブログ記事を管理するHeadlessCMSとしてWordPressを採用していました。また、ContactForm7を使用しており、お問い合わせフォームのバックエンドとしても使用していました。しかし、WordPressはHeadlessCMSとして用いるには機能が多いため、今回はブログ機能とお問い合せ機能を分割し、それらをわかりやすく管理しようと思い、HeadlessCMS、なかでもドキュメントや参考サイトが充実しているContentfulを採用しました。なお、Contentfulは、TutorDirectのブログ機能でも採用しています。
</p>

<h2>
Contentfulでおしらせ（ブログ）を配信する
</h2>

<h3>
  必要なライブラリをインストール
</h3>

<p>
今回、ContentfulのContent Modelの型定義には<strong>contentful-typescript-codegen</strong>を使用します。また、Contentfulの公式のライブラリもあわせてインストールしましょう。
</p>

<syntax filename='node' language='plaintext'>
npm install contentful contentful-management contentful-typescript-codegen @contentful/rich-text-types
    </syntax>

 <h3>
  Content Management Tokenを発行
  </h3>

  <p>続いて型定義のためには、<strong>Content Management Token</strong>の発行が必要です。<strong>これは、Delivery API Access Tokenとは異なる</strong>ので注意が必要です。</p>

    <p>Contentfulの管理画面にログインし、左上の「Settings」をクリックし、<strong>CMA tokens</strong>メニューへ移動します。
    </p>

    <p>
        <strong>Create personal access token</strong>ボタンを押下してtokenに名前をつけます。有効期限が求められますので、適宜設定してください。これを確認したら控えておいてください。
    </p>

    <p>
        控えたアクセストークンは、.env.localに記述しておきます。.env.localに書かれた環境変数を利用するために、dotenvもインストールしておきます。
    </p>

    <syntax filename=".env.local" language="plaintext">
CONTENTFUL_MANAGEMENT_API_ACCESS_TOKEN=xxxx
    </syntax>
    <syntax filename="node" language="plaintext">
npm install dotenv
    </syntax>

<h3>
    getContentfulEnvironment.jsを作成
</h3>

<p>
    projectのrootに<strong>getContentfulEnvironment.js</strong>を作成し、以下のように記述します。
</p>

<syntax filename='getContentfulEnvironment.js' language='javascript'>
    require("dotenv").config({ path: `.env.local` });

    const contentfulManagement = require("contentful-management")

    module.exports = function () {
        const contentfulClient = contentfulManagement.createClient({
            accessToken: process.env.CONTENTFUL_MANAGEMENT_API_ACCESS_TOKEN,
        })

        return contentfulClient
            .getSpace(process.env.CONTENTFUL_SPACE_ID)
            .then(space => space.getEnvironment(process.env.CONTENTFUL_ENVIRONMENT))
    }
    </syntax>

<p>
    package.jsonに、次のようなnpm scriptを追加します。
</p>

<syntax filename="package.json" language="json">
{
    "scripts": {
        "contentful-typescript-codegen": "contentful-typescript-codegen --output @types/generated/contentful.d.ts"
    }
}
    </syntax>

こうすることで、型定義が@types/generated/contentful.d.tsに生成されるようになりますので、実行してみましょう。

<syntax filename="node" language="plaintext">
npm run contentful-typescript-codegen
    </syntax>

<h2>生成した型定義ファイルを確認</h2>

<p>
    次のようなファイルが生成されているはずです。内容はご自身の作成したContent Modelのfieldsに合わせて変わります。
</p>

<syntax filename="@types/generated/contentful.d.ts" language="typescript">
import { Asset, Entry } from "contentful";
import { Document } from "@contentful/rich-text-types";

export interface IPostFields {
    /** Title */
    title: string;

    /** Body */
    body: Document;

    /** Slug */
    slug: string;

    /** Excerpt */
    excerpt: string;
}

/** Blog post */

export interface IPost extends Entry&lt;IPostFields&gt; {
    sys: {
        id: string;
        type: string;
        createdAt: string;
        updatedAt: string;
        locale: string;
        contentType: {
          sys: {
            id: "post";
            linkType: "ContentType";
            type: "Link";
          };
        };
      };
    }
    </syntax>

<h2>
    SSGでブログ記事を配信する
</h2>

<p>
    Next.jsの有用な機能の一つであるSSG（Static Site Generation）を用いて、ブログ記事を配信します。SSGとは、build時にContentfulからデータを取得し、静的なHTMLを生成する機能です。この機能を用いることで、ブログ記事の配信に必要なAPIリクエストを減らすことができます。
</p>

<h3>
    contentful clientの作成
</h3>

<p>
    contentfulから記事を取得するために、contentful clientを作成します。筆者は、次のように作成しました。
</p>
<syntax
language="plaintext"
filename=".env.local">
CONTENTFUL_SPACE_ID = yyy
CONTENTFUL_ACCESS_KEY = zzz
    </syntax>
<syntax
language="typescript"
filename="utls/contentful.ts">
const client = createClient({
    space: process.env.CONTENTFUL_SPACE_ID,
    accessToken: process.env.CONTENTFUL_ACCESS_KEY
  })
    </syntax>
<p>
    以後、clientとして他の.tsxファイルから使用します。
</p>
<h3>
    post一覧ページの作成
</h3>

<p>
    まず、post一覧ページを作成します。pages/posts/index.tsxを作成しましょう。

<h4>
    getStaticPropsを実装
</h4>

<p>
    getStaticPropsを実装し、Contentfulからpostのデータを取得します。このとき、取得するデータの順番を指定することもできます。今回は、作成日時の降順で取得するようにしています。
</p>
<syntax language="typescript" filename="pages/posts/index.tsx">
export const getStaticProps: GetStaticProps = async () => {
    const contentfulClient = getContentfulEnvironment()
    const entries = await client.getEntries&lt;IPostFields&gt;({
        content_type: "post",
        order: "-sys.createdAt",
    })
    const posts = entries.items.map((entry) => entry.fields)
    return {
        props: {
            posts,
        },
    }
}
    </syntax>
</p>

<h4>
    PostListPageを実装
</h4>

<p>
    続いて、受けとったpostデータのstaticPropsをもとに、post一覧ページを作成します。pages/posts/index.tsxを以下のように編集します。
</p>

<syntax language="typescript" filename="pages/posts/index.tsx">
type Props = InferGetStaticPropsType&lt;typeof getStaticProps&gt;

export PostListPage:NextPage&lt;Props&gt; = ({posts}) => {
    return (
        &lt;div&gt;
            &lt;h1&gt;おしらせ&lt;/h1&gt;
            &lt;ul&gt;
                {posts.map((post) => (
                    &lt;li key={post.sys.id}&gt;
                        &lt;Link href={`/posts/${post.slug}`}&gt;
                            &lt;a&gt;{post.title}&lt;/a&gt;
                        &lt;/Link&gt;
                    &lt;/li&gt;
                ))}
            &lt;/ul&gt;
        &lt;/div&gt;
    )
}
    </syntax>

<h3>
    post個別ページの作成
</h3>

<p>
    今回は、postの一意なslug fieldをもとに、post個別ページを作成します。pages/posts/[slug].tsxを作成しましょう。
</p>

<h4>
    getStaticPathsを実装
</h4>

<p>
    slugをもとに、postの個別ページを作成するためには、getStaticPathsを実装する必要があります
</p>

<syntax
language="typescript"
filename="pages/posts/[slug].tsx">

export const getStaticPaths:GetStaticPaths = async () => {
    const res = await client.getEntries&lt;IPostFields&gt;({
        content_type: "post",
    })

    const paths = res.items.map(
        item => {
            return { params: { slug: item.fields.slug } }
        }
    )

    return {
        paths,
        fallback:false
    }
    </syntax>
<h4>
    getStaticPropsを実装
</h4>

続いて、一覧取得したslugをもとに、対応する個別ページのデータを取得ための関数であるgetStaticPropsを実装します。

<syntax 
language="typescript"
filename="pages/posts/[slug].tsx">
export const getStaticProps:GetStaticProps = async ({params}) => {
    const { items } = await client.getEntries&lt;IPostFields&gt;(
        {
            content_type: "post",
            "fields.slug": params.slug,
        }
    )

    return {
        props:{
            post: items[0].fields
        }
    }
    </syntax>

<h4>
    個別ページの表示を実装
</h4>

<syntax
language="typescript"
filename="pages/posts/[slug].tsx">
type Props = InferGetStaticPropsType&lt;typeof getStaticProps&gt;

const PostPage:NextPage&lt;Props&gt; = ({post}) => {
    return (
        &lt;div&gt;
            &lt;h1&gt;{post.title}&lt;/h1&gt;
            &lt;div&gt;
                {documentToReactComponents(post.body)}
            &lt;/div&gt;
        &lt;/div&gt;
    )
}
    </syntax>
これで、post一覧ページと個別ページの作成は完了です。

<h2>
    まとめ
</h2>

<p>
    以上のように、Next.jsとContentfulを用いてブログ機能を実装する方法を紹介しました。
</p>

<p>
    弊社の「おしらせ」ページおよび「技術発信」ページも、同様の方法で実装しています。みなさまも、ぜひお試しください。
</p>

技術発信

お問い合わせ機能だけのためのサーバー運用をやめた話

Next.jsとContentfulで作るおしらせ機能