مشاور جدی Next.js قبل از فیچر، مسیر درخواست را قابل توضیح می‌کند

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

کار از مسیر درخواست شروع می‌شود. کدام مسیر روی سرور رندر می‌شود، کدام می‌تواند ایستا باشد، کدام به کوکی وابسته است، و کدام به API خصوصی می‌زند. اگر این نقشه مبهم باشد، هر تصمیم کش حدس است. حدس همان جایی است که داشبورد کهنه، صفحه بازاریابی کند، و باگ فقط-پروداکشن از آن درمی‌آید.

مالکیت مسیر را بنویس

در App Router مرز مسیر مرز محصول است. صفحه قیمت، داشبورد واردشده، گردش‌کار مدیر، و endpoint وب‌هوک نباید درباره تازگی داده فرض مشترک داشته باشند. راه‌حل تنبل این است که همه‌چیز را دینامیک کنی و بگذری. نتیجه گران این است که سایت برای صفحه‌ای که باید ایستا می‌بود هزینه سرور می‌دهد و هنوز روی مسیری که باطل‌سازی صریح لازم داشت اشتباه می‌کند.

برای هر مسیر مهم سه واقعیت کافی است. مالک داده کیست. تازگی لازم چقدر است. چه چیزی ثابت می‌کند داده عوض شده. صفحه بلاگ روی Payload CMS شاید با تولید ایستا و بازتولید برچسبی کنار بیاید. صفحه صورت‌حساب باید هنگام درخواست از دیتابیس یا API مورد اعتماد بخواند. پرتال پروژه شاید ترکیبی باشد: فراداده کش‌شده، بررسی مجوز زنده، و mutation پشت Server Action یا Route Handler.

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

کش را قبل از کار عملکردی راست کن

کار Core Web Vitals بعد از صادق شدن داستان کش آسان‌تر است. اگر صفحه پشت پنج fetch سرور بند است، کتابخانه انیمیشن مسئله نیست. اگر مسیر فقط چون یک کمک‌کننده `headers` را می‌خواند دینامیک شده، سایت برای یک راحتی محلی مالیات دائمی می‌دهد. اگر هر fetch با `no-store` است، تیم یکی از دلیل‌های اصلی فریمورک را پاک کرده.

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

Search Console، آنالیتیکس، و لاگ سرور باید بگویند وقت مهندسی کجا برود. اگر مقاله برای تو نقش صفحه محصول را دارد، باید رندر سریع، فراداده تمیز، لینک داخلی، و راه تماس داشته باشد. این‌ها را بعد از ده فیچر تزئینی درست کردن، گران‌تر است.

احراز و دسترسی به داده را از UI جدا کن

جای بعدی مجوز است. خیلی کدبیس‌ها چک را از کامپوننت UI شروع می‌کنند چون سریع به نظر می‌رسد. به محض Route Handler، Server Action، کار پس‌زمینه، یا پیش‌نمایش CMS این مدل می‌شکند. قاعده باید نزدیک مرز داده باشد. UI می‌تواند دکمه را پنهان کند. سرور باید کار را رد کند.

در پروژه Payload این موضوع دو بار مهم است. کنترل دسترسی Payload می‌تواند سند را حفظ کند، ولی سایت عمومی اغلب از کمک‌کننده‌های سفارشی می‌خواند. آن کمک‌کننده‌ها باید رفتار پیش‌نویس، قاعده خواندن عمومی، حریم نویسنده، و دسترسی پیش‌نمایش را نگه دارند بدون اینکه هر صفحه یک استثناء شود. یک پوشش کوئری مشترک وقتی ارزش دارد که اشتباه تکراری دسترسی را حذف کند. لایه مخزن کلی برای هر کالکشن معمولاً تشریفات است.

ابهام را این‌طور پاک کن. کدام مسیر محتوای منتشرشده را می‌خواند. کدام پیش‌نویس را. کدام حق mutation دارد. کدام چون job مورد اعتماد است دسترسی را دور می‌زند. وقتی این مسیرها اسم دارند، هم بازبینی امنیت ارزان‌تر می‌شود هم دیباگ.

استقرار را کسل‌کننده کن

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

اگر این را نداری، فیچر تازه را روی زمینی می‌گذاری که نمی‌توانی مطمئن شوی همان کدِ بررسی‌شده به دست کاربر رسیده. لاگ خطای خوانا، منبع نقشه برای ردیابی معنی‌دار، و یک راه برگشت ساده، جزو همان گذر معماری‌اند نه تجمل عملیات.

محیط پیش‌نمایش را هم با پروداکشن یکی ندان. اگر پیش‌نمایش داده واقعی را با قاعده دیگر می‌خواند و کسی این فرق را ننوشته، باگ «فقط روی پروداکشن» تولید می‌کنی. تفاوت‌های عمدی را کوتاه و مکتوب کن.

چه چیزی را به اسپرینت فیچر راه نده

کامپوننت جدید روی مسیر دینامیک تصادفی. فرم تازه که مجوز را فقط در دکمه چک می‌کند. کش تازه بدون مالک باطل‌سازی. وابستگی UI که اولین مسیر را سنگین می‌کند در حالی که هنوز نمی‌دانی LCP کدام گره است.

ترتیب کار برای من این است. نقشه مسیرهای پول‌ساز و مسیرهای اعتماد. اصلاح یک مورد کش یا مجوز که امروز رفتار غلط می‌سازد. بعد فیچر. اگر تیم اصرار دارد همان هفته فیچر ببیند، فیچر را پشت یک مرز بگذار که ابهام قدیمی را وسیع‌تر نکند. این کندی نیست. جلوگیری از کندی ماه بعد است.

خروجی این گذر باید یک صفحه یادداشت باشد که تیم بدون حضور مشاور هم بفهمد. اگر فقط در ذهن یک نفر ماند، کار انجام نشده.

پرسش‌های کوتاه

این گذر چقدر باید طول بکشد؟ برای یک محصول متوسط، چند روز متمرکز اغلب تصویر را روشن می‌کند. اگر به پروژه چندماهه تبدیل شد، یا دامنه را زیاد کرده‌ای یا خود کد هنوز قابل خواندن نیست و مسئله جای دیگری است.

همه‌چیز را استاتیک کنیم؟ نه. ایستا برای چیزی است که تازگی و مجوزش اجازه می‌دهد. دینامیک صریح بهتر از ایستای غلط است.

مشاور باید فیچر هم بنویسد؟ بعد از این وضوح، بله اگر لازم است. قبل از آن، سرعت نوشتن فیچر معمولاً هزینه را قایم می‌کند.