Server Action چیه؟

Server Action یعنی تابعی که:

• در سرور اجرا میشه
• مستقیماً از کامپوننت (حتی فرم) در سمت کلاینت صدا زده میشه
• نیازی به ساخت API Route و fetch نداره
• به‌صورت خودکار serialized و validated میشه

مثلاً:

'use server'

import { revalidatePath } from 'next/cache'
import { db } from '@/lib/db'

export async function addPost(formData: FormData) {
  const title = formData.get('title')
  await db.post.create({ data: { title } })
  revalidatePath('/blog')
}

و در کلاینت فقط می‌گی:

<form action={addPost}>
  <input name="title" />
  <button type="submit">Add Post</button>
</form>

هیچ API endpoint، هیچ fetch، هیچ JSON parsing‌ای لازم نیست ✅

---

🔸 اما کجاها مناسب استفاده از Server Action هست؟

به‌صورت خلاصه:

هرجا که عملی روی داده انجام می‌دی (Mutation) ولی نیاز به مصرف عمومی API نداری.

یعنی اگر:

• قراره فرم بفرسته داده‌ای رو بسازه/ویرایش کنه/حذف کنه
• اون داده صرفاً داخل همین اپلیکیشن Next استفاده میشه
• و نیازی نیست توسط کلاینت‌های خارجی یا موبایل استفاده بشه

✅ اونجا Server Actions عالیه.

---

✅ موارد مناسب استفاده از Server Actions

سناریو	توضیح
🔸 فرم‌های CRUD داخل داشبورد	ایجاد / ویرایش / حذف داده در DB
🔸 فرم Login یا Register	چون مستقیم با دیتابیس کار می‌کنی
🔸 آپلود فایل / ارسال فرم	وقتی داده از <form> میاد
🔸 فرم تماس یا feedback	چون فقط همین سایت ازش استفاده می‌کنه
🔸 ری‌ولیدیت کردن cache	با revalidatePath() یا revalidateTag()
🔸 عملیات سروری کوچک	مثل ارسال ایمیل، پردازش ساده، یا عملیات atomic

---

❌ مواردی که نباید از Server Action استفاده کنی

سناریو	دلیل
🔸 گرفتن داده برای صفحه (مثلاً پست‌های بلاگ)	چون Server Action طراحی نشده برای data fetching. از fetch یا getServerSideProps/RSC استفاده کن
🔸 API عمومی (موبایل، کلاینت دیگر)	چون Server Actions فقط از درون خود Next App قابل فراخوانی‌اند
🔸 Realtime APIs یا WebSocket	Server Actions async و request-response هستند، نه realtime
🔸 عملیات cross-domain	چون Server Action endpoint داخلی و امن است، نه برای بیرون

---

💡 در مورد مثال تو (پست‌های صفحه بلاگ)

❓ آیا برای گرفتن پست‌های بلاگ از Server Action استفاده کنیم؟

پاسخ: ❌ نه.

چرا؟
چون گرفتن پست‌ها (read operation) یعنی data fetching، نه mutation.

Server Action مخصوص mutationهاست، نه fetch.

برای گرفتن داده‌ها در صفحه بلاگ، بهتره از:

• fetch() در Server Component
• یا getServerSideProps() / generateStaticParams() (در App Router) استفاده کنی.

مثلاً:

// app/blog/page.tsx
import { getPosts } from '@/lib/api'

export default async function BlogPage() {
  const posts = await getPosts()
  return (
    <div>
      {posts.map(p => <div key={p.id}>{p.title}</div>)}
    </div>
  )
}

اینجا getPosts می‌تونه یه تابع async باشه که از دیتابیس یا API داده می‌گیره.
سرور اون رو هندل می‌کنه، نه مرورگر — دقیقاً همون مزیت RSC.

---

🔹 تفاوت ذهنی: Server Action ≠ Data Fetching

ویژگی	Server Action	Server Component Fetch
هدف	تغییر داده	دریافت داده
نوع درخواست	POST	GET
از کجا صدا زده میشه	فرم یا handler کلاینت	داخل Server Component
Cache behavior	معمولاً invalidate می‌کنه	معمولاً cached / ISR
مناسب برای	فرم‌ها و mutations	SSR و data fetching

---

🔒 مزیت بزرگ Server Actions

• امنیت بالا (کد فقط در سرور اجرا میشه)
• حذف API endpointهای تکراری
• پشتیبانی از Type safety به‌صورت مستقیم
• ادغام طبیعی با فرم‌ها و revalidatePath
• حذف نیاز به fetch یا JSON parsing
• در آینده می‌تونه از Streaming و optimistic UI پشتیبانی کنه (شبیه React mutations)

---

✨ جمع‌بندی

مورد	توضیح
چه زمانی استفاده کنیم	وقتی فرم داری یا داده‌ای در سرور تغییر می‌کنی
چه زمانی استفاده نکنیم	وقتی صرفاً داری داده می‌گیری (read-only)
هدف	جایگزین ساده‌تر برای API routes در عملیات داخلی
جایگزین برای API عمومی؟	❌ نه
جایگزین برای data fetching؟	❌ نه