1. **ルーティング**
1.1. ルーティングって？
1.1.1. プロジェクトの骨格となる部分
1.1.2. 遷移先のURLを決定する作業
1.1.2.1. 実例を見てみよう
1.1.3. ルーティング設計やプロジェクト構成が開発の肝でもある
1.2. 階層構造の基本
1.2.1. 🌳をイメージ
1.2.2. Tree(Root)
1.2.2.1. Sub Tree(Root)
1.2.2.1.1. Leaf
1.2.2.1.2. Sub Tree(Root)
1.2.2.2. Sub Tree(Root)
1.2.2.2.1. Leaf
1.2.2.3. Sub Tree(Root)
1.2.2.3.1. Leaf
1.2.3. https://ja.next-community-docs.dev/docs/app-router/building-your-application/routing/
1.2.4. 混乱する用語
1.2.4.1. Root
1.2.4.1.1. ツリー or サブツリーの根本のフォルダ
1.2.4.2. Root Segment
1.2.4.2.1. Segment ＝部分/断片
1.2.4.2.2. サブツリーの各フォルダ
1.3. App Routerのルーティング
1.3.1. /app配下にフォルダやファイルを配置していく
1.3.1.1. /app/page.tsx
1.3.1.1.1. https://xxx.com
1.3.1.2. /app/dashboard/page.tsx
1.3.1.2.1. https://xxx.com/dashboard
1.3.1.3. /app/dashboard/settings/page.tsx
1.3.1.3.1. ネストされたルート
1.3.1.3.2. https://xxx.com/dashboard/settings
1.3.1.4. /app/tags/[slug]/page.tsx
1.3.1.5. 実例を紹介
1.3.2. ファイル規約
1.3.2.1. 以下のファイル名は特殊な役割を持っている
1.3.2.2. page
1.3.2.2.1. ルーティングとして認識
1.3.2.3. layout
1.3.2.3.1. ページ共通レイアウト作成
1.3.2.4. loading
1.3.2.4.1. ストリーミングとローディングUI
1.3.2.5. not-found
1.3.2.5.1. 404ページの作成
1.3.2.6. error / global-error
1.3.2.6.1. エラー時のページ作成
1.3.2.7. route
1.3.2.7.1. APIルーティングとして認識
1.3.2.8. template
1.3.2.8.1. 共通レイアウト作成
1.3.2.8.2. layoutと違って遷移すると再レンダリングされる
1.3.2.8.3. アニメーション遷移の実装時などに利用される
1.3.2.9. default
1.3.2.9.1. Pararell Routesで使用
1.3.2.10. コンポーネント階層
1.3.2.10.1. これらのファイル群は自動的に同階層(Root Segment)のpage.tsxにレンダリングされる
1.3.2.10.2. 裏ではどのようにレンダリングされているのか？
1.3.2.10.3. https://ja.next-community-docs.dev/docs/app-router/building-your-application/routing/#%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%8D%E3%83%B3%E3%83%88%E3%81%AE%E9%9A%8E%E5%B1%A4
1.3.3. コロケーション機能
1.3.3.1. 関連するものは近い位置に配置すること
1.3.3.2. page.tsxを宣言せずに利用
1.3.3.2.1. pageを使用しなければルーティングとして認識されない
1.3.3.2.2. /app/dashboard/header.tsx /app/dashboard/footer.tsx /app/dashboard/utils.ts
1.3.3.2.3. /app/api/db.ts
1.3.3.2.4. 近い位置で管理＝保守・運用しやすい
1.3.3.2.5. 使うかどうかはチーム次第
1.3.3.2.6. https://ja.next-community-docs.dev/docs/app-router/building-your-application/routing/#%E3%82%B3%E3%83%AD%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
1.3.4. プロジェクト整理機能
1.3.4.1. プライベートフォルダ
1.3.4.1.1. ルーティングから除外する機能
1.3.4.1.2. フォルダの前にアンダースコアをつける
1.3.4.1.3. /app/dashboard/_components/button.tsx /app/dashboard/_lib/page.tsx
1.3.4.1.4. メリットは？
1.3.4.2. ルートグループ
1.3.4.2.1. プロジェクトをグループ化できる
1.3.4.2.2. フォルダ名を()で括る
1.3.4.2.3. /app/(admin)/dashboard/page.tsx /app/(marketing)/about/page.tsx
1.3.4.2.4. メリットは？
1.3.4.3. /src
1.3.4.3.1. /app内にプロジェクト設定を入れたくない場合に有効
1.3.4.3.2. /appはルーティングだけに集中させる
1.3.4.3.3. 個人的に/srcは導入しています
1.4. ベストプラクティス
1.4.1. ルーティング設計のベストプラクティス
1.4.1.1. 3つの戦略
1.4.1.1.1. **/appの外側にプロジェクトファイルを配置**
1.4.1.1.2. **/appの内側のトップフォルダにプロジェクトファイルを配置**
1.4.1.1.3. **機能やRouteごとにプロジェクトファイルを配置する**
1.4.1.1.4. プロジェクトやチームによって変わる
1.4.2. プロジェクト配置設計のベストプラクティス
1.4.2.1. Atomic Design
1.4.2.1.1. 化学とのアナロジー
1.4.2.1.2. Atoms
1.4.2.1.3. Molecules
1.4.2.1.4. Organism
1.4.2.1.5. Templates
1.4.2.1.6. Pages
1.4.2.1.7. 懐疑的な意見もちらほら....
1.4.2.2. Bulletproof-React
1.4.2.2.1. 採用率高めかも?
1.4.2.2.2. featuresディレクトリを配置
1.4.2.2.3. 実際に作って(見て)みよう
1.4.2.2.4. https://zenn.dev/t_keshi/articles/bulletproof-react-2022
1.5. 応用と発展
1.5.1. Parallel Routes
1.5.1.1. あ
1.5.2. Intercepting Routes
1.5.2.1. あ
2. **コンポーネント**
2.1. コンポーネントって？
2.1.1. アプリを構成する部品のこと
2.1.2. 部品が集まってアプリが完成する
2.1.3. 部品が作られる「場所」がNext.jsでは重要
2.1.3.1. クライアント側? or サーバー側?
2.1.3.2. まずはクラサバ関係を図解で理解しよう
2.2. ClientComponent
2.2.1. ファイル先頭に"use client"
2.2.2. 無闇に使わない
2.2.3. ユースケース
2.2.3.1. Hooksを利用する時
2.2.3.1.1. useState
2.2.3.1.2. useEffect
2.2.3.1.3. useRef etc...
2.2.3.2. イベントハンドラを利用する時
2.2.3.2.1. onClick
2.2.3.2.2. onChange etc...
2.2.3.3. ブラウザAPIを利用する時
2.2.3.3.1. localStorage / sessionStorage
2.2.3.3.2. window / doucument
2.2.3.4. クライアント操作が多いコンポーネント
2.2.3.4.1. フォームコンポーネント
2.2.3.4.2. 検索コンポーネント
2.2.3.4.3. タブ切り替え/ ハンバーガーメニュー開閉
2.3. ServerComponent
2.3.1. デフォルトでServerComponent
2.3.2. **こちらを積極的に利用する**
2.3.2.1. なぜ？
2.3.2.1.1. データフェッチが高速になる
2.3.2.1.2. サーバー側でレンダリング(SSR)されるので JSバンドルサイズが削減される
2.3.2.1.3. クライアントのスペックにほぼ依存しなくなる
2.3.2.1.4. SEOの向上
2.3.2.1.5. セキュリティの強化
2.4. 注意点
2.4.1. Client Boundary
2.4.1.1. ClientComponentの子コンポーネントは自動的に ClientComponentになる
2.4.1.2. 意図しないClientComponent化に注意
2.4.1.3. Compositionパターンで回避はできる
2.4.1.3.1. 参考文献参照
2.5. ベストプラクティス
2.5.1. **ServerComponentを積極的に利用**
2.5.2. **ClientComponentは控えめに**
3. **データフェッチ**
3.1. fetch()
3.1.1. fetch("https://dummy.com/user/1")
3.1.2. Next.jsでは拡張されている
3.1.2.1. デフォルトでSSG
3.1.2.2. オプトインでSSG/SSR/ISRに変更可能
3.1.2.3. キャッシュ設定が簡単
3.1.2.4. Request Memoization
3.1.2.5. レンダリングで後述
3.1.2.6. 実例を見てみよう
3.2. ORM等を利用した関数
3.2.1. prisma.post.findMany();
3.2.2. Route Handler(API)で書く必要はない
3.2.2.1. Route Handlerって？
3.2.2.1.1. app/api/posts/route.ts
3.2.2.1.2. Next.jsでAPIが作れる機能の事
3.2.2.2. 通信回数が増える
3.2.2.3. APIを配布する予定がある場合は良いかも？
3.2.2.3.1. それならRailsやLaravelを利用するかも
3.2.2.4. データ送信では使うかも？
3.2.2.4.1. ただServerActionsが登場した
3.2.2.4.2. これでも利用するケースは少ないかも
3.2.2.5. 私がRoute Handlerを利用するケース
3.2.2.5.1. WebhookやOAuthコールバック用のAPI
3.2.2.5.2. サードパーティサービスとの統合ポイントとして利用する時がある
3.2.3. キャッシュ方法は後述
3.3. サードパーティライブラリ
3.3.1. ClientComponentの場合
3.3.1.1. useSWR()
3.3.1.1.1. https://swr.vercel.app/ja
3.3.1.2. Tanstack Query
3.3.1.2.1. https://tanstack.com/query/latest
3.3.1.3. useEffect ← 非推奨
3.3.1.3.1. バケツリレーが増える = 可読性の低下
3.3.1.3.2. エラーハンドリングやローディング状態の管理も大変
3.3.1.3.3. キャッシュ実装が面倒＆難しい
3.3.1.4. 基本的には非推奨
3.3.1.4.1. 学習コストがかかる
3.3.1.4.2. パブリックなネットワークへ公開
3.3.1.4.3. JSバンドルサイズの増加
3.3.1.4.4. そもそもNext.jsを使う意義が損なわれる
3.4. 並行データフェッチング
3.4.1. 同期よりも並行を優先
3.4.1.1. 並行＝パラレル
3.4.1.2. 具体例
3.4.1.2.1. 家事
3.4.1.2.2. 洗濯物を回しながら、皿洗い
3.4.1.2.3. 空いた時間は別の仕事をすると効率的
3.4.2. https://ja.next-community-docs.dev/docs/app-router/building-your-application/data-fetching/patterns
3.4.3. コンポーネントに分割すると 自動的に非同期データフェッチになる
3.4.4. Promise.all()
3.4.4.1. const [results, tags] = await Promise.all([ getSearchResults(query), getRelatedTags(query) ]);
3.4.5. ただ、段階的にUIを表示したい場合は...
3.4.5.1. ストリーミングデータフェッチングを利用する
3.5. ストリーミングデータフェッチング
3.5.1. ServerComponentが基本になってます
3.5.2. 用意できたデータから順次表示する手法
3.5.2.1. UXの向上
3.5.2.2. 用意できていないデータはフォールバックを表示
3.5.2.2.1. ローディングUI
3.5.2.2.2. スケルトンUI
3.5.3. Reactの<Suspence/ >を利用
3.5.3.1. https://ja.next-community-docs.dev/docs/app-router/building-your-application/routing/loading-ui-and-streaming
3.5.4. またはルートセグメントでloading.jsを利用
3.5.4.1. ページ全体でストリーミングしたい場合のみ
3.5.4.2. 個々のコンポーネントをストリーミングしたい時はSuspenceを利用
3.5.4.3. https://ja.next-community-docs.dev/docs/app-router/building-your-application/routing/loading-ui-and-streaming
3.5.5. 実例を見てみましょう
3.6. ベストプラクティス
3.6.1. **ServerComponentを利用する**
3.6.1.1. なぜ？
3.6.1.1.1. 初回ページ読み込み速度の向上
3.6.1.1.2. SEO向上
3.6.1.1.3. セキュア
3.6.1.1.4. キャッシュの利用
3.6.1.1.5. ただし、デメリットも
3.6.1.1.6. 必要に応じて並行データフェッチ / ストリーミングデータフェッチングを行う
3.6.2. Container / Presentationパターンの意識
3.6.2.1. https://zenn.dev/akfm/books/nextjs-basic-principle/viewer/part_2_container_presentational_pattern
3.6.2.2. Container = データ取得層
3.6.2.3. Presentation = 見た目の部分
3.6.2.4. 実装例
3.6.2.4.1. https://zenn.dev/akfm/books/nextjs-basic-principle/viewer/part_2_container_presentational_pattern
3.6.2.5. なぜ？
3.6.2.5.1. 関心の分離
3.6.2.5.2. テストしやすくなる
3.6.2.5.3. Compositionパターンにも対応しやすい
3.6.2.6. 小規模ならオーバーエンジニアリングかも
4. **キャッシュ**
4.1. ちょっと難しいトピック
4.1.1. そもそもキャッシュって？
4.1.1.1. データを一時的に保存し 再度取り出しやすくすること
4.1.1.1.1. 例：図書館
4.1.1.1.2. 良く貸出される人気の本
4.1.1.1.3. 書物の奥底ではなく、フロント近くの本棚に置いておく
4.1.1.1.4. すぐに本が提供できて便利！
4.1.2. Request Memoization
4.1.2.1. 同じリクエストは「重複排除」される
4.1.2.1.1. https://nextjs.org/docs/app/building-your-application/caching#request-memoization
4.1.2.1.2. 注意点
4.1.2.2. ServerComponentでfetch()を使う場合のみ適用
4.1.2.2.1. ORM等で作った関数はメモ化されない
4.1.2.2.2. RouteHandler(API)内での利用では適用されない
4.1.2.2.3. fetch以外ならReact cacheを利用
4.1.2.3. コンポーネント最下層でfetchしても問題ない
4.1.2.4. 動的メタデータ設定の際等に効果を発揮する
4.1.2.4.1. generateMetadata()
4.1.2.4.2. 同じfetchリクエストしても重複排除される
4.1.2.5. キャッシュ期間
4.1.2.5.1. 永続的ではない
4.1.2.5.2. fetchリクエスト毎
4.1.3. Data Cache
4.1.3.1. fetch()に関するキャッシュ
4.1.3.1.1. 理解しておかないと意図しないデータが返ってくる
4.1.3.2. fetch()でData Cache設定できる
4.1.3.2.1. fetch("https://...", **{cache: "force-cahce"})**
4.1.3.2.2. fetch("https://...", **{cache: "no-store"})**
4.1.3.2.3. fetch("https://...", **{cache: {next: {revalidate: 3600}}}**)
4.1.3.2.4. SSG/SSR/ISRが関係する
4.1.3.3. https://ja.next-community-docs.dev/docs/app/building-your-application/caching#fetch-optionscache
4.1.3.4. キャッシュ期間
4.1.3.4.1. 永続的
4.1.3.4.2. サーバーを再起動 / タブを閉じたりしてもData Cacheは残る
4.1.3.4.3. 最新のデータを返したいなら
4.1.3.4.4. 再検証を設けることも可能
4.1.4. Full Route Cache
4.1.4.1. 静的ページ全体をキャッシュする
4.1.4.1.1. SSG / ISRで生成されたページをサーバー側でキャッシュ
4.1.4.1.2. 具体的にはHTML / RSCPayloadをキャッシュする
4.1.4.1.3. レンダリングコストの削減、ページ表示速度の向上
4.1.4.1.4. https://ja.next-community-docs.dev/docs/app/building-your-application/caching#full-route-cache
4.1.4.2. Static Renderingのみ適用される
4.1.4.2.1. SSG / ISR時のみ
4.1.4.2.2. SSRの場合はキャッシュされない
4.1.4.2.3. AppRouterはStaticRenderingを推奨
4.1.4.3. Router Cacheでクライアント側にもキャッシュされる
4.1.4.3.1. これは次動画で後述するが
4.1.4.3.2. サーバー側→クライアント側へキャッシュが移行する
4.1.4.3.3. 以降のナビゲーションは高速になる
4.1.4.4. キャッシュ期間
4.1.4.4.1. 永続的
4.1.4.4.2. ユーザー間を超えてキャッシュが共有される
4.1.4.4.3. 指定時には慎重に
4.1.5. Router Cache
4.1.5.1. クライアントでRSC Payloadをキャッシュすること
4.1.5.1.1. ページ訪問時にキャッシュされる
4.1.5.1.2. Full Route Cacheで見た通り
4.1.5.1.3. 戻る / 進むボタンでキャッシュが利用される
4.1.5.1.4. UXの大幅な向上
4.1.5.2. ページを訪問する前にキャッシュはできないのか
4.1.5.2.1. 実はできます
4.1.5.3. キャッシュを無効にしたいときは...
4.1.5.3.1. ServerActionsで
4.1.5.3.2. router.refresh
4.1.5.4. キャッシュ期間
4.1.5.4.1. セッション中のみ = ブラウザのタブが閉じるまで
4.1.5.4.2. 静的ページ
4.1.5.4.3. 動的ページ
4.1.5.4.4. staleTimes
4.1.6. ベストプラクティス
4.1.6.1. **キャッシュの挙動をちゃんと理解しよう**
4.1.6.1.1. 予期しないキャッシュが発生しなければOK
4.1.6.1.2. キャッシュすべき箇所も把握できれば最高
4.1.6.1.3. ドキュメントから最新情報を知ると尚良い
4.1.6.2. キャッシュをもっと制御したい場合
4.1.6.2.1. Remix等を利用する
4.1.6.2.2. WebAPI標準に遵守している
4.1.6.2.3. キャッシュの詳細なカスタマイズが可能
4.1.7. Next.js 15で "use cache"が実験的に登場
4.1.7.1. キャッシュ実装がもっと簡単になるようです
4.1.7.1.1. SSG / ISR にしたい
4.1.7.1.2. SSRにしたい
4.1.7.1.3. シンプルになりました
5. **レンダリング**
5.1. レンダリングって？
5.1.1. HTML/CSS/JSを組み合わせてページとして見れる状態すること
5.1.1.1. ①HTMLの骨格を形成
5.1.1.2. ②CSSでスタイリング
5.1.1.3. ③JSでインタラクティブ化
5.1.1.4. https://zenn.dev/oreo2990/articles/280d39a45c203e
5.1.1.5. 「レンダリング」は文脈によって意味が変わる
5.1.1.5.1. 上記レンダリングフロー全体を指すこともあるが
5.1.1.5.2. Reactのレンダリング
5.1.2. キャッシュと何が違うの？
5.1.2.1. キャッシュ ＝ データを「いつ再利用するか」
5.1.2.2. レンダリング = ページを「いつ作るか」
5.1.2.3. 図書館で例えると
5.1.2.3.1. キャッシュ = 本棚の本
5.1.2.3.2. レンダリング = 本を読むタイミング
5.1.2.3.3. レンダリング方法を決定すると⇨ キャッシュ方法も自動的に決まる
5.1.3. クライアント側 or サーバー側でレンダリングするかでパフォーマンスが変わる
5.1.3.1. パフォーマンスって何で図る？
5.1.3.1.1. どれだけ早くユーザーのデバイスにコンテンツを表示させるか
5.1.3.1.2. TTFB etc...
5.1.4. Next.jsでは基本サーバー側でレンダリングさせる
5.1.4.1. クライアント側に負荷をかけさせない
5.1.4.2. 事前にデータフェッチしておくため
5.2. Static Rendering
5.2.1. おさらいです
5.2.2. SSG
5.2.2.1. 最速
5.2.2.2. fetch("https://...", **{cache: "force-cache"}**)
5.2.2.3. 静的ページで有効
5.2.2.3.1. ドキュメント
5.2.2.3.2. ヘルプページ
5.2.2.3.3. ポリシーページ
5.2.2.3.4. 更新の少ないブログメディア等
5.2.3. ISR
5.2.3.1. これも早い
5.2.3.2. データのキャッシュ更新時間を 指定可能
5.2.3.3. 静的と動的の中間ページで有効
5.2.3.3.1. ブログメディア
5.2.3.3.2. ニュースサイト
5.2.3.3.3. ECサイト etc...
5.2.3.4. fetch("https://...", **{cache: {next: {revalidate: 3600}}}**)
5.2.3.4.1. revalidate = 再検証 = キャッシュ更新
5.2.3.4.2. 古いキャッシュを削除する時間を指定する
5.3. Dyanamic Rendering
5.3.1. SSR
5.3.1.1. 程よく早い
5.3.1.1.1. 初期ロードはClientComponentよりも早い傾向
5.3.1.2. リクエスト毎に都度サーバーでレンダリング
5.3.1.3. fetch("https://...", **{cache: "no-store"}**)
5.3.1.3.1. no-store = ストアしない = キャッシュしない
5.3.1.3.2. 都度データソースにアクセスする
5.3.1.4. 注意点
5.3.1.4.1. キャッシュされません
5.3.1.4.2. 都度APIリクエストを投げるので負荷がかかる
5.3.1.4.3. headers() / cookies()で自動的にSSRになる
5.4. Suspence / Streaming
5.4.1. ストリーミングって？
5.4.1.1. 段階的にUIやデータを提供すること
5.4.1.2. SSRの時に利用する
5.4.1.2.1. Streaming SSR
5.4.1.3. データフェッチのストリーミングデータフェッチングを参照
5.5. Partial Pre Rendering(PPR)
5.5.1. レンダリング方式の新時代へ突入か
5.5.2. v15で実験的に導入されている
5.5.3. Partial ＝ 部分的 Pre Rendering = 部分レンダリング
5.5.3.1. https://zenn.dev/akfm/articles/nextjs-partial-pre-rendering#ppr%E3%81%A8%E3%81%AF
5.5.3.2. Static と Dyanamicの混在が可能
5.5.3.2.1. Suspence境界の外側がStaticRendering
5.5.3.2.2. Suspence境界の内側がDyanamicRendering
5.5.3.2.3. https://nextjs.org/blog/next-15-rc#incremental-adoption-of-partial-prerendering-experimental
5.5.4. ページ単位からUI単位でのレンダリング方式決定へ
5.5.4.1. SSG or SSR等の判別議論が過去のものになる？
5.5.4.2. 今の内にキャッチアップしておくと良いかも
5.5.4.3. 具体的な実装例を見てみよう
5.6. ベストプラクティス
5.6.1. **実装箇所によってレンダリング方式を判断できたらOK**
5.6.1.1. ex. ヘルプページ ⇨ SSG ex. プロフィールページ⇨ISR / SSR ex. タイムライン⇨SSR/CSR
5.6.1.2. ただ、PPRの登場で考えるべき粒度が変わる可能性も
5.6.1.2.1. ページ単位⇨UI単位へ
5.6.1.3. デフォルトではStaticRenderingを推奨
5.6.1.3.1. 必要に応じてDyanamic Renderingを
5.6.2. キャッシュも同様
5.6.3. Next.jsユーザーであれば理解しておくべきトピック
5.6.3.1. はじめての Next.js：App Router によるフロントエンド開発の教科書
5.6.3.2. 執筆予定です。2026年の上旬に出版になると思います。
5.6.3.3. 撮影してる途中で決定しました。よければお手にとっていただけると嬉しいです。
6. **メタデータ**
6.1. メタデータって？
6.1.1. Googleのクローラーが巡回しやすいように設定するデータ
6.1.1.1. タイトル
6.1.1.2. 詳細
6.1.1.3. OGP画像
6.1.1.4. サイトマップ
6.1.2. SEO対策をするならば必須の設定
6.1.3. 従来のメタデータ設定は...
6.1.3.1. 直接<meta/>を作って、タイトルや詳細文を入れていた
6.1.3.2. Next.jsだと
6.1.3.2.1. export const metadata = {} を記述するだけ
6.1.3.2.2. 静的ページと動的ページによってメタデータ設定方法が少し変わる
6.1.3.2.3. 設定は簡単です
6.2. 静的メタデータ
6.2.1. page.tsx / layout.tsxに
6.2.1.1. export const metadata = {} を記述するだけ
6.2.2. 実例を見てみよう
6.3. 動的メタデータ
6.3.1. 動的ルーティングのpage.tsx / layout.tsxに
6.3.1.1. export async function generateMetadata(){}を記述するだけ
6.3.1.2. サーバーコンポーネントのみで動く
6.3.1.3. これも実例を見てみよう
6.3.1.4. ここでRequest Memoizationの効力が発揮される
6.3.1.4.1. fetch()を使った場合に限られるが
6.3.1.4.2. 重複にフェッチされている場合はメモ化されている
6.3.1.4.3. fetch以外の関数を呼ぶ場合
6.4. メタデータのファイル規約
6.4.1. page.tsx等のファイル規則のようにメタデータもファイル規則がある
6.4.2. たとえば
6.4.2.1. favicon.ico / apple-icon.jpg / icon.jpg
6.4.2.2. opengraph-image.jpg / twitter-image.jpg
6.4.2.2.1. opengraph-image.tsxもあります
6.4.2.2.2. ImageResponse()を使ってOGP画像を動的生成可能
6.4.2.3. robots.txt / sitemap.xml
6.4.3. ファイル規約のメタデータが優先される
6.5. メタデータの上書き(評価順序)
6.5.1. メタデータ設定には評価順序が存在します
6.5.2. 評価が高い順番はこちら
6.5.2.1. ①ファイル規約のメタデータ
6.5.2.2. ②最下層で定義したメタデータ
6.5.2.3. ③/app/layout.tsx等、最上位で定義した共通メタデータ
6.5.2.4. 具体例を見てみましょう
6.5.3. 意図しない上書きに注意
6.6. ベストプラクティス
6.6.1. まずはメタデータの基本設定を抑える
6.6.2. ＋α
6.6.2.1. 階層的な設計
6.6.2.1.1. 評価順序を理解しておく
6.6.2.1.2. layout.tsxでベース設定
6.6.2.1.3. 個別に決めたい場合は、下層のpage.tsxで設定すると良し
6.6.2.2. 静的アセットの活用
6.6.2.2.1. アイコン類はファイル規約で管理
6.6.2.2.2. デフォルトのOGP画像は静的ファイルで用意
6.6.2.2.3. 動的OGP画像はopengraph-image.tsxを積極的に使うと良い
6.6.2.3. SEO対策
6.6.2.3.1. description設定
6.6.2.3.2. OGP画像サイズ
6.6.2.3.3. robots.txt / sitemap.ts
6.6.2.3.4. etc....
6.6.2.3.5. 別途SEOの勉強すると尚良い
7. **ミドルウェア**
7.1. ミドルウェアって？
7.1.1. URLリクエスト前に 実行される関数
7.1.1.1. お城の門番みたいなもの
7.1.1.1.1. 権限のある王家の人しかお城に入れない仕組み
7.1.1.1.2. それ以外の部外者は追い出す、みたいなことができる
7.1.1.2. 安全性を担保するために 実装される
7.1.1.3. ユースケース
7.1.1.3.1. 認証と認可
7.1.1.3.2. リダイレクト制御
7.1.1.3.3. 他にも
7.2. どうやって実装する？
7.2.1. /appと同じ階層にmiddleware.tsを作成する
7.2.1.1. ファイル規約の1つです。
7.2.2. https://ja.next-community-docs.dev/docs/app/building-your-application/routing/middleware#example
7.2.3. matcherで発火URLを指定できる
7.2.3.1. Matching Pathsとも言う
7.2.3.2. export const config = { matcher: [""] }
7.2.3.2.1. 例えば
7.2.3.2.2. 指定したパスに適合したリクエストのみミドルウェアが発火する
7.2.3.2.3. 何も指定しないと
7.3. アンチパターンと制約条件
7.3.1. DBクエリを使用した認可チェック
7.3.1.1. 毎度DBにアクセスすることでレイテンシが増加する
7.3.1.2. パフォーマンスの低下に繋がる
7.3.1.3. ミドルウェアでDBクエリを実行するのは避けよう
7.3.1.4. 代替案
7.3.1.4.1. 楽観的チェック
7.3.1.4.2. DALでチェック
7.3.2. 重い処理の実行
7.3.2.1. あ
7.3.3. Node.js固有のAPI利用
7.3.3.1. あ
7.3.4. 全パスでの実行
7.3.4.1. あ
7.4. ベストプラクティス
7.4.1. a