فرنٹ اینڈ دوبارہ لکھنا۔ 170 مقامات اب بھی اسے استعمال کر رہے ہیں۔ کام میں کوئی تعطل نہیں۔

CRA V1 اب بھی 170 مقامات اور تقریباً 765 بیک وقت صارفین کو خدمت دے رہا تھا۔ ہم خصوصیات پر کام منجمد کرکے الگ متبادل نہیں بنا سکتے تھے، نہ تمام صارفین کو ایک ساتھ منتقل کرسکتے تھے۔ منتقلی کو فعال مصنوع کے اندر چلنا تھا۔

ہم نے Strangler Fig طریقہ اپنایا: نیا نظام پرانے کے گرد رکھا، پروڈکشن کی ایک ذمہ داری ایک وقت میں منتقل کی، اور جب کوئی انحصار باقی نہ رہا تو مطابقتی تہہ حذف کردی۔

Next.js V2، ایپ کا شیل بنا۔ نیویگیشن پٹی، اوپری پٹی، تصدیقِ شناخت اور مشترک انٹرفیس اس کی ذمہ داری تھے۔ ابھی منتقل نہ ہونے والے راستے ایک CRA iframe میں چلتے رہے، اس لیے فرنٹ اینڈ کے دو چلتے ماحول کے باوجود صارفین کو ایک مصنوع نظر آئی۔

iframe ہمیشہ ڈیش بورڈ کا مستقل بنیادی URL لوڈ کرتا تھا۔ وہ پیرنٹ روٹ بدلنے کے باوجود ماؤنٹ رہا؛ اسے دوبارہ ماؤنٹ کرنے سے پرانی حالت صاف ہو جاتی اور تصدیقِ شناخت دوبارہ کرنا پڑتی۔ V2 نے ابتدائی راستہ صرف iframe کے onLoad کال بیک سے، V1 کا پیغام سننے والا عمل لگنے کے بعد بھیجا، اور بعد کی تبدیلیاں صرف اس وقت بھیجیں جب نقشہ شدہ راستہ واقعی بدلا۔

iframe.contentWindow?.postMessage(
  {
    action: 'NAVIGATE',
    route: iframeRoute,
    location_id: locationId,
    migratedLocationIds: [...MIGRATED_LOCATION_IDS]
  },
  dashboardUrl
)

ہم نے پیغامات کی دونوں سمتیں واضح متعین کیں۔ V2 نے نیویگیشن، SSO ٹوکنز، صارف اور مقام کا ڈیٹا بھیجا۔ V1 نے راستے کی تبدیلیاں، صارف ڈیٹا کی درخواستیں، ٹوکن ریفریش کی درخواستیں اور Click2Call اعمال واپس کیے۔

ہر وصول کنندہ نے غیر متوقع ماخذ رد کیے، اور ہر بھیجنے والے نے وائلڈ کارڈ کے بجائے ایپ کے مقرر ماخذ کو ہدف بنایا۔ ماخذ کی جانچ پہلی حد تھی، پیغام کے پورے مواد کی تصدیق نہیں۔ ٹوکن والے پیغامات کے لیے پیغام کی معروف اقسام اور تصدیق شدہ فیلڈز بھی لازم تھے۔

if (event.origin !== dashboardUrl) return
if (event.data?.source !== 'dispo-iframe') return
if (event.data?.type !== 'ROUTE_CHANGE') return

const route = mapV1RouteToV2(event.data.route)
if (route) router.replace(route)

صارف نے V2 میں ایک بار تصدیقِ شناخت کی۔ V1 لوڈ ہونے پر موجودہ صارف کا سیاق مانگتا؛ V2 نے SSO ٹوکن کے ساتھ صارف اور مقام کا ڈیٹا واپس کیا۔ V1 نے ٹوکن اپنے موجودہ API کلائنٹ کے لیے محفوظ کیا اور ختم ہونے پر اسی پل سے نیا ٹوکن مانگا۔

iframe کے آغاز میں ریس کنڈیشن کی تشخیص کے دوران ایک پیشگی auth ہُک شامل کیا گیا۔ وہ V1 کی درخواست سے پہلے تصدیقِ شناخت بھیجنے کی کوشش کرتا تھا، مگر اس سے ٹائمنگ کا ایک اور راستہ بن گیا اور ہُک غیر ضروری طور پر پہلے چلنے لگا۔ بعد کی تبدیلی نے اسے ہٹا کر درخواست و جواب پر مبنی auth رکھا، جس سے ٹوکن کے وقت کا ایک ہی واضح مالک رہا۔

V2 نے اپنے راستوں کو /dashboard، /buyer-genie، /deals اور /my-buyers جیسے V1 راستوں سے ملایا۔ الٹا نقشہ مکمل راستے اور درجہ بند سابقے دونوں سنبھالتا تھا۔ V1 کے اندر نیویگیشن شروع ہونے پر V2 نے router.replace استعمال کیا، تاکہ ایک صارف عمل کے لیے تاریخچے کا دوسرا اندراج بنائے بغیر پتے کی پٹی اور فعال نیویگیشن بدلیں۔

اس سے تازگی، گہرے روابط اور براؤزر میں پیچھے یا آگے جانا ہم آہنگ رہے۔ براؤزر میں پیچھے جانے سے بنیادی راستہ بدلا، بنیادی سطح نے نقشہ شدہ ذیلی راستہ بھیجا، اور ماؤنٹ شدہ iframe نے شیل دوبارہ لوڈ کیے بغیر نیویگیشن کی۔

MIGRATED_LOCATION_IDS، اجرا کا کنٹرول تھا۔ ہم نے اندرونی اور اسٹیجنگ مقامات سے آغاز کیا، پھر آٹھ صارف مقامات تک پھیلایا۔ فہرست سے باہر ہر شخص موجودہ V1 راستے پر رہا۔

• مقامی V2: Navbar، Topbar، Settings، Investor Intake، SSO اور Twilio Dialer۔
• دستاویزی درمیانی مرحلے پر اب بھی V1 میں: Home، Genius Mode، Deals اور Buyers۔
• منتقلی کی اکائی: ایک الگ آغاز نہیں، ایک خصوصیت اور منتخب صارف مقامات۔

مطابقتی تہہ کو مستقل ساخت بنانے کے بجائے آخرکار ہٹا دیا گیا۔ مکمل منتقلی نے iframe نظام اور خودکار طور پر بنائے گئے پرانے API کلائنٹس حذف کیے، باقی کلائنٹس کو V2 کے تحت منتقل کیا، V2 کا اپنا سائن اِن راستہ شامل کیا، پھر راستے، آزمائشیں، مشترک ڈائلر کوڈ، auth گارڈز اور کمپوننٹ ساخت صاف کی۔

کچھ عرصہ ہم نے دو راؤٹرز، دو نشست ماڈلز، ونڈوز کے درمیان واقعات، راستے کے میپس اور آغاز کے ٹکراؤ سنبھالے۔ یہ قیمت صرف اس لیے قابلِ قبول تھی کہ ہر منتقل راستہ ہمیں پل حذف کرنے کے قریب لے جاتا تھا۔

• پرانی کوڈ بیس کو جدید بنانے سے متعلق مضمون پڑھیں