​​Next.js Server Actions 試用に関する所感レポート

目的

Next.jsのServer Actionsを用いたフォーム送信・バリデーション処理の実装を試行し、そのメリット・デメリットを評価する。

以下の2パターンによる実験を行う。
1.Next.js APIを使用しServer Actions内でSupabase Authユーザー登録用のエンドポイントを叩きユーザー登録を実行する。
2.Next.js APIを使用しせずに、SSRのpage.tsx一枚でSupabase Authユーザー登録を完遂させる。

実施内容

1. フォーム作成
2. • 名前、メールアドレス、パスワードの入力フォームを作成。
   • Server Actionsを経由してサーバーサイドのバリデーションを行う構成を試行。
     
2. バリデーション実装
3. • Server Actions内FormDataを受け取り、以下のバリデーションを実施：
   • 名前未入力 → メッセージ「名前を入力してください」を表示する
   • メール未入力 → メッセージ「メールアドレスを入力してください」を表示する
   • メール形式不正 → メッセージ「メールアドレスの形式が正しくありません」を表示する
   • パスワード6文字未満 → メッセージ「パスワードは6文字以上で入力してください」を表示する
     
3. フロント側実装
4. • useActionStateを用いて、Server Actionsから返却されるバリデーションメッセージを表示。
   • 複数フィールドのエラーを個別に表示するロジックを作成。
     
4. apiを切り分けずにデータベースへデータをINSERT
5. • SSRのpage.tsxにServer Actionsを用意しフォームを切り分けることなく送信してINSERTを行う。ユーザー登録がを実行でき、Server Actions内でSupabase API呼び出しが可能であることを確認。
5. apiを作成しデータベースへデータをINSERT
6. • フロントとバックエンドの責務の切り分けを行う
   • Supabase API呼び出し用のエンドポイントを用意し、エンドポイント内にバリデーションロジックを実装

気づき / 問題点

1. バリデーションメッセージの表示
2. • 例えば名前が空欄の時に送信を押下した場合、「名前」の下に「名前を入力してください」といったように各フィールドのバリデーションメッセージを表示する場合、Server ActionsとuseActionStateの組み合わせは直感的ではなく、実装が煩雑。
     
2. Server Actionsのメリット
3. • これまでSCRコンポーネントで実装していたバリデーションやロジックを隠蔽できる。
   • クライアントに直接ビジネスロジックやAPIキーを置かずに済む。
     
3. 今回のプロジェクトにおけるメリットの希薄さ
4. • 既にAPIを用意し、フロントから非公開キーを使わずに呼び出す構成であるため、Server Actionsによる隠蔽の恩恵はほとんど感じない。
   • バックエンドでバリデーションを実装するため、フロントバリデーションをServer Actionsで隠蔽する必要性も低い。
     
4. 開発コスト
5. • Server Actionsを使うことで、API経由と比べて実装の複雑さが増す。
   • 既存 API + fetch での実装の方が理解しやすく、保守性が高い。

Server Actionsのメリット・デメリットと適用すべき開発スタイル

はじめに

Next.jsに導入されたServer Actionsは、フロントエンドのフォーム処理をサーバーで非同期に直接扱える機能である。従来のAPIルートを作成して通信する方法に比べて、簡潔で型安全なコーディングが可能である。しかし、全てのプロジェクトで最適とは限らない。

主なメリット

• バリデーションロジックをフロントエンドから隠せる:
  セキュリティ面やロジックの一元管理が向上する。
  
• APIエンドポイントの作成が不要:
  Next.js内部で関数呼び出しとして処理できるため、ルーティング設定が不要。
  
• コードを不用意に分ける必要がなくなる:
  従来、SSRページにPOSTメソッド用のフォームを設置する場合は、フォーム部分をCSRコンポーネントとして切り出し、SSRページでそれを呼び出す必要があった。
  Server Actionsによって、フォーム送信処理を直接SSRコンポーネント内（例：page.tsx）に記述できるようになった。つまり、クライアント側のイベントハンドラ（onSubmit + fetchなど）を切り出す必要がない。
  これまで「フォーム部分はClient Component化し、useStateで値を管理し、fetchでAPI RouteにPOSTする」などの構成を取る必要があったのが、Server Actionsでは不要になる。
  Server Actionsを利用すれば、フォームのデータ送信処理がSSRの`page.tsx`内で完結するため、フォームを小コンポーネントとして切り出す必要がなく、構成が単純明快になる。
  

主なデメリット

• 既存の分離したAPI設計とは相性が悪い:
  Server ActionsはUIとサーバー処理を密結合させ、クライアントから直接サーバー関数を呼び出す設計である。
  そのため、既にRESTやGraphQL APIを中心に、バリデーション・認証・キー管理・レスポンス構造などを厳密に分離設計しているプロジェクトでは、Server Actionsを導入してもメリットが少なく、むしろ二重管理や責務の重複を招く可能性がある。
  このような環境では従来どおりAPIレイヤーを維持し、UI層とは疎結合な構成を保つ方が望ましい。
  
• コードの複雑化や学習コストが増すケースもある:
  慣習や設計パターンの違いにより、効率化を実感しにくい場合がある。
  
• Next.js固有の実装に依存するため、他環境や多用途利用には弱い
  

適用が向いているケース・向いていないケース

向いているケース

• Next.js単体で完結する小〜中規模プロジェクト
• クイックなCRUD操作主体のWebアプリ
• 開発効率やコードスッキリ感を重視したい場合

向いていないケース

• APIを別管理しバリデーション・認証を完全API側で行う大規模システム
• 複数クライアントやモバイルを対象とした共通API構築
• 既存のREST/GQL APIが整備済みで変更コストが高い場合

結論

既にAPIが分離されバリデーションもAPI側で完結している場合、Server Actionsの導入はメリットが少なく、逆にコードの複雑化や保守の難しさを招く可能性があると感じる。
Server Actionsは「Next.jsアプリに閉じた開発をシンプル化するための機能」であり、万能ではなかった。