پرانی فرنٹ اینڈ کو جدید بنانا
نہ TypeScript۔ نہ لنٹر۔ نہ Sentry۔ 170 مقامات اسے ہر روز استعمال کرتے ہیں۔
موجودہ صارفین کے لیے مصنوع دستیاب رکھتے ہوئے بغیر اقسام اور نگرانی والی پرانی فرنٹ اینڈ کو مرحلہ وار جدید بنانا۔
پڑھنے کا وقت: 5 منٹتحریر Abdullah Raheel
وراثت میں ملی پابندیاں حقیقی تھیں
ورثے میں ملی CRA فرنٹ اینڈ سادہ JavaScript میں تھی؛ TypeScript، ESLint، Prettier، Sentry، دوبارہ استعمال ہونے والا کمپوننٹ نظام یا مربوط خصوصیتی ساخت موجود نہیں تھی۔ اس میں 5,000 سے زیادہ خام CSS سطریں، اِن لائن اسٹائلز سے بدل جانے والی Tailwind کلاسز، نقل شدہ صفحات اور ایک سطحی، غیر درجہ بند ڈائریکٹری ترتیب تھی۔
مسائل ایک دوسرے کو بڑھاتے تھے۔ API تبدیلیاں کمپائلر کی تنبیہ کے بغیر براؤزر تک پہنچتی تھیں۔ نقل شدہ اسکرینز انداز بندی کے وہی نقائص دہراتی تھیں۔ نگرانی کا راستہ نہ ہونے کی وجہ سے پروڈکشن نقائص عموماً صارفین کی اطلاعات سے سامنے آتے تھے۔
دیکھ بھال کی لاگت کا اثر صارفین تک پہنچ گیا
ایپ اب بھی روزانہ 170 صارف مقامات کو خدمت دیتی تھی۔ ہم نے V1 کو وہیں مکمل تبدیل نہیں کیا، نہ مکمل متبادل کا انتظار کیا۔ پرانے راستے چلتے رکھے اور ہر نئے V2 راستے کے لیے نئے معیارات لازمی کیے۔
اس سے ٹیم کو سادہ قاعدہ ملا: پرانے طریقے مزید نہ پھیلائیں۔ راستہ دوبارہ بناتے وقت ذمہ داری منتقل کریں، پھر نیا راستہ پروڈکشن میں چلنے پر پرانا راستہ ہٹا دیں۔
اقسام والی حد بنائیں
Next.js 15 اور TypeScript نے نئی ٹائپڈ حد بنائی۔ نئے روٹس نے ٹائپڈ روٹ ڈیفینیشنز، جنریٹ شدہ API کلائنٹس، مشترک fetch رویہ اور فیچر کی ملکیت والے کمپوننٹس استعمال کیے۔ ٹیم نے پہلے ہر پرانی فائل تبدیل نہیں کی؛ نئی ان ٹائپڈ سطح بڑھانا روکا اور کام ہر روٹ تک پہنچنے پر ذمہ داری V2 میں منتقل کی۔
- TypeScript اور اقسام والے راستوں نے نیویگیشن اور API شکل کی غلطیاں تیاری کے دوران ظاہر کردیں۔
- جنریٹ شدہ کلائنٹس اور مشترک fetch رویے نے بکھرے ہوئے درخواست کے طریقوں کی جگہ لی۔
- خصوصیتی فولڈرز نے راستوں، ہُکس، اسکیما اور آزمائشوں کے واضح مالک مقرر کیے۔
- دوبارہ استعمال ہونے والے بنیادی اجزا نے دہرائے گئے تعاملات میں صفحے کی سطح کی نقول بدل دیں۔
ہر اسکرین منتقل کرنے سے پہلے فیڈبیک لوپس شامل کریں
جدید کاری نے ناکامیوں کی شناخت اور تبدیلیوں کی منظوری کا طریقہ بھی بدلا۔ Sentry نے کلائنٹ، سرور اور ایج رپورٹنگ کے ساتھ ایپ ایرر باؤنڈریز دیں۔ یونٹ اور براؤزر ورک فلوز کو واضح لازمی گیٹس ملے، جبکہ رویے پر مبنی ٹیسٹس نے Investor Intake جیسے زیادہ خطرے والے فلوز جانچے۔
ان ضابطوں نے V1 خودکار طور پر درست نہیں کیا۔ انہوں نے ہر V2 راستے کو مزید پروڈکشن ذمہ داری لینے سے پہلے قابلِ نگرانی اور قابلِ آزمائش بنایا۔
پرانی مصنوع کے گرد نئی حد بنائیں
V2 پورے ایپ شیل، تصدیقِ شناخت اور ہر نئی منتقل شدہ خصوصیت کا مالک تھا۔ CRA صرف ان راستوں کے لیے ایک iframe کے اندر رہا جن کی ملکیت اب بھی اس کے پاس تھی۔ منتقلی سے متعلق مضمون postMessage، SSO اور روٹنگ پل کی تفصیل دیتا ہے۔
اس مضمون میں اہم نکتہ ذمہ داری ہے: نئے معیارات V2 کی حد پر لاگو ہوئے، اور ہر مکمل منتقلی نے ان سے مستثنیٰ کوڈ کی مقدار کم کی۔
منتقلی کے دوران ذمہ داری واضح رکھیں
منتقلی کے دوران ذمہ داری واضح طور پر درج کی گئی۔ Navbar، Topbar، Settings، Investor Intake، Authentication اور Twilio، V2 میں منتقل ہوئے۔ Home، Genius Mode، Deals اور Buyers اپنے متبادل تیار ہونے تک V1 میں رہے۔ صارف مقامات نامکمل سطحیں ایک ساتھ لینے کے بجائے قابو شدہ گروہوں میں منتقل ہوئے۔
اس فہرست نے دوبارہ تحریر کو غیر متعین متوازی منصوبہ بننے سے روکا۔ خصوصیت یا V1 کی ملکیت تھی، مطابقتی حد سے فراہم ہورہی تھی، یا مقامی V2 تھی۔
جدید بنانا ایک سلسلہ ہے، ایک واقعہ نہیں
آخری منتقلی نے iframe، خودکار طور پر بنائے گئے پرانے کلائنٹس اور پل کا کوڈ ہٹایا، پھر غیر ضروری راستے، آزمائشیں، auth گارڈز، مشترک ڈائلر کوڈ اور کمپوننٹ ساخت صاف کی۔ جدید کاری تب مکمل ہوئی جب عارضی حد حذف کی جاسکی۔
- ترقی کو نئی فریم ورک فائلوں کی تعداد سے نہ ناپیں۔
- ناپیں کہ کون سی پروڈکشن ذمہ داریاں منتقل ہوئیں اور کون سے مطابقتی راستے ہٹائے جاسکتے ہیں۔
- پوری کوڈ بیس کی کامل تبدیلی کا انتظار کرنے کے بجائے نئے کوڈ کو نئے معیارات کے اندر رکھیں۔
- آخری منحصر سطح منتقل ہونے کے بعد عارضی منتقلی کا بنیادی ڈھانچا حذف کریں۔

