توسعه با Next.js و React

Server Components مسئله را عوض کرده‌اند#

مدل قدیمی React این بود: سرور یک HTML خالی می‌فرستد، مرورگر چند صد کیلوبایت جاوااسکریپت دانلود می‌کند، بعد داده می‌گیرد، بعد صفحه را می‌سازد. هر مرحله یک تأخیر.

با App Router و Server Components، کامپوننتی که فقط داده را نمایش می‌دهد اصلاً به مرورگر نمی‌رود. جاوااسکریپتی که به کلاینت می‌رسد فقط همان تکه‌هایی است که واقعاً تعاملی‌اند.

// روی سرور اجرا می‌شود؛ هیچ بایتی از این فایل به مرورگر نمی‌رسد.
export default async function InvoiceList({ customerId }: { customerId: string }) {
  const invoices = await db.invoice.findMany({
    where: { customerId },
    orderBy: { issuedAt: "desc" },
  });
 
  return (
    <ul>
      {invoices.map((invoice) => (
        <li key={invoice.id}>{invoice.number}</li>
      ))}
    </ul>
  );
}

نتیجه عملی: صفحه‌ای که با چند کیلوبایت جاوااسکریپت کار می‌کند، نه چند صد کیلوبایت.

دیپلوی روی هاست ایرانی#

این بخشی است که معمولاً از قلم می‌افتد و بعداً گران تمام می‌شود. خیلی از پروژه‌های Next.js ناخواسته به قابلیت‌های اختصاصی Vercel گره می‌خورند و بعد روی سرور معمولی کار نمی‌کنند.

کارهایی که از ابتدا انجام می‌دهم:

• output: "standalone" تا خروجی بیلد یک سرور Node مستقل باشد.
• هیچ runtime = "edge" در هیچ روتی.
• بهینه‌سازی تصویر در زمان بیلد، نه توسط پلتفرم.
• متغیرهای محیطی از فایل، نه از داشبورد یک سرویس خاص.

کجا Next.js انتخاب اشتباهی است#

اگر سایت شما پنج صفحه محتوایی است که سالی دو بار عوض می‌شود، Next.js پیچیدگی بی‌دلیل می‌آورد. اگر تیم شما فقط با PHP آشناست و قرار است خودشان نگهداری کنند، همین‌طور. این را قبل از شروع می‌گویم، نه بعد از فاکتور.