3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Next.jsで技術ブログを作ったら、page.tsxとroute.tsの役割で悩んだ話 〜責務分離と処理の流れを整理〜

3
Posted at

はじめに

久しぶりの投稿です。

Next.js を学習しながら、自分の Qiita 記事と microCMS のサンプルブログを表示する技術ブログを作成しました。
今回の記事では、その開発を通して学んだ ファイルルーティング各ファイルの責務の分け方 について、特に苦戦した点を中心にまとめたいと思います。

作成したもの

image.png

技術スタック

カテゴリ 使用技術
フロントエンド React / Next.js
言語 TypeScript
スタイリング Tailwind CSS / daisyUI
API Qiita API / microCMS
テスト Vitest / React Testing Library
デプロイ Firebase App Hosting

機能概要

トップページ

Qiita と microCMS の記事を新しい順に4件表示しています。

Qiita・microCMS の記事一覧ページ

各一覧ページでは記事を新しい順に8件表示し、8件を超える場合はページネーションで切り替えられるようにしています。

microCMS の記事詳細ページ

microCMS の記事をクリックすると、記事の詳細ページを表示できます。

大変だったこと

今回の開発で特に苦戦したのは、page.tsxroute.ts の関係を理解することでした。

実装自体が極端に複雑だったわけではありませんが、Next.js のファイル構成や責務の分け方にまだ慣れておらず、最初はどのファイルに何を書くべきか迷うことが多くありました。

特に、

  • 画面表示の処理をどこに書くのか
  • 外部 API を呼び出す処理をどこに置くのか
  • データ取得の共通処理をどこにまとめるのか

が曖昧なまま実装を進めてしまい、あとから整理し直す場面がありました。
その中で、責務を分けて実装することの重要性 を強く実感しました。

工夫したところ

今回の実装では、各ファイルの役割をできるだけ明確に分けることを意識しました。
page.tsx から直接 route.ts を呼び出すのではなく、
その間に contact.ts を用意し、データ取得処理の責務を整理しています。

page.tsx の責務

  • 画面を表示する
  • 必要なデータ取得関数を呼び出す
  • 取得したデータをコンポーネントに渡す

route.ts の責務

  • 外部 API(Qiita / microCMS)を呼び出す
  • 認証ヘッダを付ける
  • HTML の取得や整形(OGP 抽出など)を行う
  • 取得したデータをアプリ内で扱いやすい形に変換して返す

contact.ts の責務

  • ページ側から利用するデータ取得関数をまとめる
  • 何件・何ページ分のデータを取得するかを受け取る
  • どの API エンドポイントを呼ぶかを隠蔽する
  • fetch オプションやキャッシュ方針をまとめる

このように責務を分けたことで、
  • コードの役割が明確になった
  • 修正しやすくなった
  • 再利用しやすくなった

と感じています。

処理の流れ

今回のアプリでは、データ取得の流れは次のようになっています。

page.tsx

contact.ts

/api/...fetch

route.ts

外部 API(Qiita / microCMS)

たとえばトップページでは、まず page.tsx が実行され、その中で fetchArticles() が呼ばれます。
次に contact.tsfetchArticles()/api/qiita に対して fetch を実行します。
このリクエストを受けて、はじめて route.ts の処理が実行されます。

つまり、route.ts は最初から自動で動くわけではなく、
fetch("/api/...") が実行されたタイミングで、HTTP リクエストに応じて動く仕組みになっています。

この流れを理解してからは、どの処理をどこに書くべきかがかなり整理しやすくなりました。

気づき

今回の実装を通して、クライアント側とサーバー側の責務の違い を以前より意識できるようになりました。

特に大きかったのは、外部 API とのやり取りをサーバー側中心で扱う構成にしたことです。
その結果、API キーのような秘匿情報をクライアントから直接扱わずに済む形にすることができました。

この経験から、

  • クライアント側で処理するもの
  • サーバー側で処理するもの

を分けて考えることの重要性を学びました。

また、今回の開発を通して、
「動けばよい」ではなく、「どこに何を書くべきかを考えること」が設計では大切
だと実感しました。

終わりに

本来は1か月くらいで終わらせる予定でしたが、日を空けて作業することも多く、完成までかなり時間がかかってしまいました。

途中で学習のモチベーションが下がる時期もありましたが、最後まで作り切ったことで、技術面だけでなく 継続することの大切さ も改めて実感しました。

今後は今回の経験を活かして、さらに Next.js の理解を深めながら、より良い設計や実装ができるよう学習を続けていきたいと思います。

JISOUのメンバー募集中!

プログラミングコーチングJISOUでは、新たなメンバーを募集しています。
日本一のアウトプットコミュニティでキャリアアップしませんか?
興味のある方は、ぜひホームページをのぞいてみてください!
▼▼▼

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?