آپ کو NextJS کی ضرورت نہیں ہے
React ایپس بنانے کے لیے Next.js ایک روایتی جواب ہے۔ یہ ایک بہترین فریم ورک ہے۔ لیکن روایتی ہونے کا مطلب یہ نہیں کہ یہ ضروری بھی ہے۔
غلط پروجیکٹ کے لیے اسے استعمال کرنے سے ہماری رفتار متاثر ہوئی اور ٹیم میں اختلافات پیدا ہوئے۔ ہم نے ڈیش بورڈز اور چارٹس کے ساتھ ایک ڈیٹا سے بھرپور پروڈکٹ بنائی۔ تقریباً ہر اسکرین لاگ ان کے پیچھے تھی۔
اس قسم کی ایپ کے لیے، server-side rendering (SSR) نے بغیر کسی فائدے کے اخراجات میں اضافہ کیا۔
صحیح ٹول کا انتخاب اس بات پر منحصر ہے کہ آپ کیا بنا رہے ہیں۔
Content-first پروجیکٹس: • مارکیٹنگ سائٹس • بلاگز • Storefronts • Docs • یہاں Next.js کا استعمال کریں۔ SEO اہم ہے اور مواد static ہوتا ہے۔
Application-first پروجیکٹس: • انٹرنل ٹولز • ڈیش بورڈز • ایڈمن پینلز • SaaS کنسولز • یہاں Vite پر مبنی SPA کا استعمال کریں۔ یہ ایپس auth کے پیچھے ہوتی ہیں اور APIs پر انحصار کرتی ہیں۔
ہم Next.js سے Vite SPA پر منتقل ہو گئے۔ اس کی وجوہات درج ذیل ہیں:
آسان Debugging سرور کی غلطیاں (errors) آپ کے کمپوننٹس کے ساتھ صحیح طرح سے مطابقت نہیں رکھتیں۔ کلائنٹ سائیڈ کی غلطیاں براؤزر میں واضح stack traces کے ساتھ ظاہر ہوتی ہیں۔ اس سے بگ فکس کرنا تیز ہو جاتا ہے۔
بہتر Testing آپ ایسے سرور کمپوننٹ کی unit test آسانی سے نہیں کر سکتے جو دوسرے سرور کمپوننٹس کو رینڈر کرتا ہو۔ ہم نے صرف ٹیسٹ کرنے کے قابل رہنے کے لیے ڈیزائن کے کچھ فیصلے کیے۔ وہ ایک غلطی تھی۔
سادہ Auth SSR کے لیے ہر ریکویسٹ پر سرور کو ٹوکنز کی تصدیق کرنی پڑتی ہے۔ اس سے حملوں کے مواقع (attack surfaces) بڑھ جاتے ہیں اور کوکی لاجک پیچیدہ ہو جاتی ہے۔ ایک client-first ایپ auth کو ایک ہی جگہ سنبھالتی ہے: API۔
کم Infrastructure اخراجات SSR کو ہر ریکویسٹ کے لیے ایک ہمیشہ آن رہنے والے سرور کی ضرورت ہوتی ہے۔ ایک static فرنٹ اینڈ CDN سے فائلوں کی صورت میں فراہم کیا جاتا ہے۔ آپ کو چلانے اور محفوظ کرنے کے لیے ایک سروس کم ہو جاتی ہے۔
کم پیچیدگی Next.js سرور اور کلائنٹ کے درمیان تقسیم کرنے پر مجبور کرتا ہے۔ فرنٹ اینڈ انجینئرز کو middleware اور caching جیسے سرور کے معاملات کو سنبھالنا پڑتا تھا۔ اس نے ہماری رفتار کم کر دی۔
ہم مراحل میں منتقل ہوئے۔ ہم نے عوامی SEO کے لیے اہم صفحات کے لیے Next.js کو برقرار رکھا۔ ہم نے باقی سب کچھ Vite SPA پر منتقل کر دیا۔
نقصانات (trade-offs) معمولی تھے: • SEO: لاگ ان کے پیچھے موجود ڈیش بورڈز کو SEO کی ضرورت نہیں ہوتی۔ • Initial load: ڈیٹا سے بھرپور ایپس عام طور پر ڈیٹا بیس کی وجہ سے سست ہوتی ہیں، فریم ورک کی وجہ سے نہیں۔
اگر SEO اور social previews اہم ہیں تو Next.js استعمال کریں۔ اگر آپ کی ایپ انٹرایکٹو، ڈیٹا پر مبنی ہے اور لاگ ان کے پیچھے ہے، تو Vite SPA استعمال کریں۔
روایتی (default) چیزوں کا استعمال چھوڑ دیں۔ خود سے پوچھیں کہ آپ اصل میں کیا بنا رہے ہیں۔
Source: https://dev.to/moruno21/you-dont-need-nextjs-heres-why-708