کی میز کے مندرجات[چھپائیں][دکھائیں]
مائیکرو سروسز کے خیال نے حال ہی میں بہت زیادہ توجہ حاصل کی ہے، اور بہت سی فرمیں اسے بڑے، یک سنگی پس منظر کو ختم کرنے کے لیے استعمال کر رہی ہیں۔
فرنٹ اینڈ کے ساتھ ایک ہی راستے پر جانا اب بھی بہت سے کاروباروں کے لیے ایک چیلنج ہے، چاہے ویب ایپس کے سرور سائیڈ کی تعمیر کا یہ تقسیم شدہ طریقہ تحقیق اور عمل درآمد کے لحاظ سے کم و بیش قابل اعتماد ہو۔
اس کے قریبی انحصار کی وجہ سے، کلائنٹ سائیڈ مونولتھ عام طور پر نئی خصوصیات کو مربوط کرنا، نئی ٹیکنالوجیز کو اپنانا، اور انفرادی اجزاء کی پیمائش کرنا مشکل بناتا ہے۔
ان اور دیگر چیلنجز نے فرنٹ اینڈ ڈویلپرز کو مائیکرو سروسز کا استعمال کرتے ہوئے تحقیقات کرنے پر آمادہ کیا ہے۔
نتیجے کے طور پر، ویب سائٹس اور ویب پر مبنی ایپلی کیشنز کی فرنٹ اینڈ پرت بنانے کے لیے ایک بالکل نئی تعمیراتی حکمت عملی تیار کی گئی جسے مائیکرو فرنٹ اینڈ کہا جاتا ہے۔
یہ اصطلاح پہلی بار 2016 میں استعمال ہوئی تھی، اور تب سے، اس نے ایک اچھے مقصد کے لیے بہت زیادہ توجہ حاصل کی ہے۔
یہ مضمون اس بات کی عمومی تفہیم فراہم کرے گا کہ مائیکرو فرنٹ اینڈ کیا ہیں اور وہ جن مسائل کو حل کرتے ہیں۔ یہ کام کر رہا ہے، اس کے ساتھ ساتھ فوائد اور نقصانات۔
مائیکرو فرنٹ اینڈ فن تعمیر کا تعارف
فرنٹ اینڈ ڈیولپمنٹ کا ایک عصری طریقہ جسے مائیکرو فرنٹ اینڈ آرکیٹیکچر کہا جاتا ہے a ویب ایپلی کیشن چھوٹے، آزاد حصوں میں.
آخری صارف کے لیے، یہ پرزے ایک یونٹ دکھائی دیتے ہیں چاہے وہ آزادانہ طور پر بنائے گئے ہوں اور پھر ایک ساتھ رکھے ہوں۔
اس فرق کے ساتھ کہ مائیکرو فرنٹ اینڈز آن لائن سلوشنز کے سرور سائیڈ سے نہیں، کلائنٹ سائیڈ سے تعلق رکھتے ہیں، ان کا بنیادی استدلال مائیکرو سروسز کی طرح ہے۔
مائیکرو فرنٹ اینڈ اپروچ استعمال کرتے وقت جدید ترین ویب پر مبنی مصنوعات بنانا سب سے زیادہ معنی خیز ہے۔
مائیکرو فرنٹ اینڈز، ایک زیادہ روایتی فرنٹ اینڈ مونولیتھ کے برخلاف، بہت سی ٹیموں کو مختلف سافٹ ویئر پروجیکٹس پر الگ الگ تعاون کرنے کے قابل بناتے ہیں۔
پروگرامرز اس آرکیٹیکچرل ڈیزائن کا استعمال کرتے ہوئے زیادہ تیزی سے اور زیادہ اسکیل ایبلٹی اور برقرار رکھنے کے ساتھ ویب ایپس بنا سکتے ہیں۔
سیدھے الفاظ میں، ہر مائیکرو فرنٹ اینڈ ویب پیج کے ایک الگ جزو کے لیے کوڈ کا صرف ایک ٹکڑا ہے۔
ان خصوصیات کو الگ الگ ٹیموں کے ذریعے کنٹرول کیا جاتا ہے، جن میں سے ہر ایک مخصوص صنعت یا مقصد میں مہارت رکھتا ہے۔
یک سنگی بمقابلہ مائیکرو سروسز بمقابلہ مائیکرو فرنٹ اینڈ فن تعمیر
نقل مکانی کے بارے میں سوچیں۔ کیا آپ کے لیے یہ آسان ہو گا کہ ہر چیز کو بہت سے چھوٹے، ماہرانہ طور پر لیبل والے خانوں میں ترتیب دیں اور ہر ایک کو انفرادی طور پر منتقل کریں یا پورے عملے کو ایک بہت بڑے باکس میں پیک کریں اور اسے کسی نئے مقام پر منتقل کریں؟
اس کا واضح حل موجود ہے۔
یہ مشابہت دو الگ الگ ویب ایپ آرکیٹیکچرز، یک سنگی اور مائیکرو سروسز (جنہیں مائیکرو فرنٹ اینڈ بھی کہا جاتا ہے) کا موازنہ کرتا ہے۔
یک سنگی فن تعمیر
آپ "اچھے پرانے دنوں" کو یاد کرنے کے قابل ہو سکتے ہیں جب ایک مکمل درخواست ایک واحد، مربوط ہستی کے طور پر بنائی گئی تھی۔ اس طرح کے طریقہ کار کو یک سنگی کہا جاتا ہے، جو پتھر کے بڑے بلاک کے لیے پرانی اصطلاح ہے۔
یہ سمجھ میں آتا ہے۔
یک سنگی نظاموں میں ایک دوسرے پر منحصر عناصر ہوتے ہیں۔ لہذا، اگر آپ کسی چیز میں ترمیم کرنا چاہتے ہیں یا کوئی نئی خصوصیت شامل کرنا چاہتے ہیں، تو یہ ممکن ہے کہ پورا نظام ٹوٹ جائے۔
اگرچہ یہ متروک ہے، یہ کبھی کبھار اب بھی موجود ہے۔ ہاں، ہم آپ کے موجودہ تاثرات سے واقف ہیں۔
کوڈ بیس کی دو مختلف اجزاء میں تصوراتی تقسیم — فرنٹ اینڈ (کلائنٹ سائیڈ) اور بیک اینڈ (سرور سائیڈ) — ناگزیر ہو گئی کیونکہ نئی ٹیکنالوجیز تیار ہوئیں اور سافٹ ویئر پروڈکٹس مزید پیچیدہ ہو گئے۔
آپریشن کا سب سے مشہور طریقہ اب پریزنٹیشن پرت کے درمیان خدشات کو الگ کرنا ہے جس کے ساتھ ایک آخری صارف تعامل کرتا ہے اور ہر چیز جو پس منظر میں ہوتی ہے۔
اسے دو سافٹ ویئر انجینئرنگ ٹیموں کی ضرورت ہے، جس میں فرنٹ اینڈ ٹیم بصری اجزاء اور بیک اینڈ ٹیم ویب سروسز، بزنس منطق، ڈیٹا تک رسائی، انضمام وغیرہ کی تعمیر کرتی ہے۔
تاہم، اس علیحدگی کے باوجود، یہ حکمت عملی اب بھی فطرت کے اعتبار سے یک سنگی ہے۔
اہم تبدیلی یہ ہے کہ اب ہمارے پاس کوڈ کے دو بڑے بلاکس ہیں - فرنٹ اینڈ اور بیک اینڈ - ایک زبردست ایپلی کیشن کے بجائے۔ یک سنگی فن تعمیرات کا خوفناک ہونا ضروری نہیں ہے۔ ان کے چند فوائد ہیں، بشمول
- ایک واحد سورس کوڈبیس اور انتہائی سادہ ڈیزائن کے ساتھ چھوٹی ایپلی کیشنز کے لیے آسان اور فوری ترقی؛
- جانچ اور ڈیبگنگ بہت سیدھی ہے کیونکہ تمام کوڈ ایک جگہ پر ہیں، جس سے ٹیم کے لیے درخواست کے بہاؤ کو ٹریک کرنا اور کیڑے کی شناخت کرنا آسان ہو جاتا ہے۔
- ایپلیکیشن کی تیاری کے آغاز میں، اخراجات سستے ہوتے ہیں کیونکہ جب تک نئی خصوصیات شامل نہیں کی جاتیں، نہ تو بنیادی ڈھانچے کے اخراجات ہوتے ہیں اور نہ ہی ترقیاتی اخراجات۔
اس حکمت عملی کی خامیاں اس میں جھلکتی ہیں۔
- محدود تعیناتی کی لچک - ٹیموں کو انتظار کرنا چاہیے اگر ان میں سے صرف چند ایک پروجیکٹ پر کام کر رہے ہوں اور جب بھی آپ کوڈ کو اپ ڈیٹ کرتے ہیں تو نئی تعیناتی کی ضرورت ہوتی ہے۔
- نئی ٹیکنالوجیز کو اپنانا مشکل ہے کیونکہ ایسا کرنے سے ایک اہم حصہ دوبارہ لکھنا ضروری ہوتا ہے، اگر پورے پروجیکٹ کو نہیں۔
- جب ڈویلپرز کی تعداد میں اضافہ ہوتا ہے، کوڈ کا ایک نظام قریب سے جڑا ہوا، پیچیدہ، اور انتظام اور سمجھنا مشکل ہو جاتا ہے۔
- تنظیمی مسائل - ٹیم کے ہر رکن کو لائبریریوں کا ایک ہی ورژن استعمال کرنا چاہیے اور اگر بہت سی ٹیمیں یک سنگی منصوبے پر کام کر رہی ہیں تو کسی تبدیلی کی اطلاع دیں۔
- اسکیل ایبلٹی سے متعلق خدشات - چونکہ پروجیکٹ کے اجزاء آپس میں جڑے ہوئے ہیں، ان کو الگ سے اسکیل کرنے سے مشکلات پیش آتی ہیں جن کے نتیجے میں اہم وقت اور زیادہ اخراجات ہوتے ہیں۔
- پروجیکٹ کی پیچیدہ منطق کو ٹیم کے نئے ممبران کے لیے سمجھنا مشکل ہو سکتا ہے، خاص طور پر اگر وہ انجینئرز جنہوں نے اصل میں اس پر کام کیا تھا اب ملازمت نہیں کر رہے ہیں۔
مائیکرو سروسز اور ان کے قریبی رشتہ داروں اور مائیکرو فرنٹ اینڈز کی ترقی نے یک سنگی نظاموں کے ساتھ بنیادی مسائل کو حل کیا۔
مائیکرو سروسز فن تعمیر
آرکیٹیکچرل طریقہ جو مائیکرو سروسز کے نام سے جانا جاتا ہے بہت سے ڈھیلے جڑے ہوئے اور آزادانہ طور پر تعیناتی کے قابل چھوٹے اجزاء، یا خدمات کی تخلیق کی اجازت دیتا ہے، جو ایک ایپلیکیشن بیک اینڈ بناتے ہیں۔
ہر سروس کا اپنا کوڈ بیس، CI/CD پائپ لائنز، DevOps طریقہ کار، اور انہیں چلانے کے عمل ہوتے ہیں۔
اوپر دی گئی تصویر کو دیکھ کر آپ دیکھ سکتے ہیں کہ یک سنگی بیک اینڈ ٹیم کو الگ الگ ٹیموں میں تقسیم کیا گیا ہے۔
ہر ایک درخواست کے مختلف پہلو (جیسے پروڈکٹ سروس، سرچ سروس، اور ادائیگی کی خدمت) پر انفرادی طور پر توجہ مرکوز کرتا ہے۔
خدمات کے درمیان مواصلت APIs کے نام سے مشہور پروٹوکولز کے ذریعے ہوتی ہے، جیسے کہ ہلکا پھلکا REST API پروٹوکول جو مطابقت پذیر درخواست کے جواب کے نمونوں کا استعمال کرتا ہے۔
دوسرا آپشن کافکا جیسے سافٹ ویئر کا استعمال کرتے ہوئے غیر مطابقت پذیر مواصلات کا استعمال کرنا ہے، جو مواصلاتی ڈھانچے اور واقعات کو شائع/سبسکرائب کرنے کی پیشکش کرتا ہے۔
مائیکرو سروسز فرنٹ اینڈ (BFF) سروس یا نیٹ ورک کے ذریعے API گیٹ وے کے لیے بیک اینڈ کے ذریعے فرنٹ اینڈ کے ساتھ ضم ہوتی ہیں۔ BFF ہر کلائنٹ کے لیے ایک حسب ضرورت API پیش کرتا ہے، جبکہ API گیٹ ویز مائیکرو سروسز کے مجموعے کے لیے رسائی کا ایک نقطہ فراہم کرتا ہے۔
لیکن یہاں تک کہ خود مختار بیک اینڈ اجزاء اور ان کے فراہم کردہ تمام فوائد کے باوجود، فرنٹ اینڈ اب بھی یک سنگی ہے۔
لہذا، یہ وہ جگہ ہے جہاں مائکرو فرنٹ اینڈ مفید ہیں۔
مائیکرو فرنٹ اینڈ فن تعمیر
مائیکرو سروسز کی طرح، جہاں ڈھیلے طریقے سے منسلک اجزاء کا انتظام کئی ٹیموں کے ذریعے کیا جاتا ہے، مائیکرو فرنٹ اینڈ فن تعمیر اس تصور کو براؤزر پر لاگو کرتا ہے۔
یہ ویب ایپلیکیشن یوزر انٹرفیس اس ڈھانچے کی پیروی کرتے ہیں، جو کسی حد تک خود مختار اجزاء پر مشتمل ہوتا ہے۔
ٹیمیں کلائنٹ کی ضروریات پر بھی بنائی جاتی ہیں یا مخصوص مہارت یا ٹیکنالوجی کے بجائے کیسز استعمال کرتی ہیں۔
نتیجتاً، ٹیمیں مائیکرو سروسز اور مائیکرو فرنٹ اینڈ پروجیکٹس میں شامل ہیں۔
- عمودی طور پر کٹے ہوئے - جیسا کہ فرنٹ اینڈ ڈویلپرز، ڈیٹا ماہرین، بیک اینڈ انجینئرز، کیو اے انجینئرز وغیرہ اسی پروجیکٹ پر کام کر رہے ہیں، وہ اپنی خصوصیات یوزر انٹرفیس ڈیٹا بیس کو؛ اور
- کراس فنکشنل - ٹیم کا ہر رکن گروپ میں اپنی مہارت کا حصہ ڈالتا ہے۔
ٹیمیں ٹیک اسٹیک کو بھی منتخب کر سکتی ہیں جو ان کے کاروبار کی مخصوص لائن کے مطابق ہو۔
ایک ٹیم اپنے ٹکڑے کو پروگرام کرنے کے لیے React کا استعمال کر سکتی ہے۔ ایک اور ٹیم ایک نیا کونیی ورژن بناتی ہے۔ Vue.js ایسی ہی ایک مثال ہے۔
مائیکرو فرنٹ اینڈ کو متعلقہ مائیکرو سروسز کے ساتھ مل کر ان مسائل کو حل کرنے کے لیے استعمال کیا جاتا ہے جو ترقیاتی ٹیموں کو عام طور پر یک سنگی کے ساتھ ہوتے ہیں۔ حکمت عملی درج ذیل فوائد پیش کرتی ہے۔
- ٹکنالوجی کی آزادی: فرنٹ اینڈ انجینئرز کمپنی کی ضروریات کے مطابق متبادل JavaScript فریم ورک، رن ٹائم ماحول، اور پوری ٹیکنالوجی کے اسٹیک کو چن سکتے ہیں۔ پرانے فن تعمیر کے اوپری حصے میں، ایک تازہ فریم ورک لاگو کیا جا سکتا ہے۔
- لچک کی ایک بڑی حد ممکن ہے کیونکہ ہر مائیکرو فرنٹ اینڈ خود پر مشتمل ہوتا ہے اور اسے الگ سے تیار، جانچ، تعینات اور اپ گریڈ کیا جا سکتا ہے۔ نتیجے کے طور پر، اگر ایک ٹیم کسی خصوصیت پر کام کر رہی ہے اور اس نے بگ فکس کو آگے بڑھایا ہے، اور دوسری ٹیم کو اپنا فیچر شامل کرنا ہے، تو انہیں پہلی ٹیم کا اپنا کام مکمل کرنے کا انتظار کرنے کی ضرورت نہیں ہے۔
- خود مختار ٹیمیں اور سسٹم: ہر پروڈکٹ ٹیم، اور اس کے نتیجے میں ہر فیچر، دوسروں پر بہت کم انحصار کے ساتھ کام کر سکتا ہے، جو اسے اس قابل بناتا ہے کہ قریبی اجزاء دستیاب نہ ہونے پر بھی کام جاری رکھے۔
- متعدد، چھوٹے کوڈبیس: ہر مائیکرو فرنٹ اینڈ کا اپنا، زیادہ قابل انتظام، چھوٹا کوڈ بیس ہوگا۔ بہت کم لوگ کسی مخصوص UI جزو پر توجہ مرکوز کریں گے، کوڈ کے جائزوں کو آسان بنائیں گے، اور مجموعی تنظیم کو بہتر بنائیں گے۔
- سادہ ایپ اسکیلنگ: مائیکرو فرنٹ اینڈز کا ایک اور فائدہ ہر فیچر کو انفرادی طور پر اسکیل کرنے کی صلاحیت ہے۔ monoliths کے برعکس، جہاں ہر بار کوئی نئی خصوصیت شامل کرنے پر پورے پروگرام کو چھوٹا کرنا ضروری ہے، یہ وقت اور پیسے دونوں کے لحاظ سے پورے عمل کو زیادہ موثر بناتا ہے۔
مائیکرو فرنٹ اینڈ کیسے کام کرتا ہے؟
جیسا کہ ہم نے پہلے کہا ہے، ٹیمیں عمودی طور پر مائیکرو فرنٹ اینڈ آرکیٹیکچر کے اندر منظم ہوتی ہیں، جس کا مطلب ہے کہ وہ ڈومین کے علم یا مقصد سے الگ ہوتی ہیں اور کسی مخصوص پروڈکٹ کے لیے شروع سے ختم ہونے تک ذمہ دار ہوتی ہیں۔
اس میں ایک یا دو بیک اینڈ مائیکرو سروسز کے ساتھ ساتھ ایک چھوٹا فرنٹ اینڈ بھی ہوسکتا ہے۔ مزید تفصیل میں، آئیے اس بصری عنصر کی خصوصیات، دوسرے UI اجزاء کے ساتھ تعامل، اور ہوم پیج میں شامل ہونے کا جائزہ لیں۔
ایک مائیکرو فرنٹ اینڈ ہو سکتا ہے۔
- ایک پورا صفحہ (مثال کے طور پر، مصنوعات کی تفصیل کا صفحہ) یا
- صفحہ کے وہ حصے جنہیں دوسری ٹیمیں استعمال کر سکتی ہیں، جیسے ہیڈر، فوٹر اور سرچ بارز۔
آپ ایک بڑی ویب سائٹ کو کئی صفحات کی اقسام میں تقسیم کر سکتے ہیں اور ہر قسم کو کام کرنے کے لیے مخصوص عملے کو دے سکتے ہیں۔
تاہم، کئی اجزاء اکثر متعدد صفحات پر پائے جاتے ہیں، جیسے ہیڈر، فوٹر، تجویز بلاکس، وغیرہ۔ ایک تجویز بلاک، مثال کے طور پر، ہوم پیج، پروڈکٹ کی تفصیل والے صفحہ، یا یہاں تک کہ چیک آؤٹ صفحہ پر بھی شامل کیا جا سکتا ہے۔
جوہر میں، ٹیمیں ایسے ٹکڑے بنا سکتی ہیں جنہیں دوسری ٹیمیں اپنے صفحات پر استعمال کر سکتی ہیں۔
تاہم، مائیکرو فرنٹ اینڈز کو دوبارہ استعمال کے قابل اجزاء کے برعکس مختلف پروجیکٹس کے طور پر الگ سے تعینات کیا جا سکتا ہے۔
یہ سب کچھ لاجواب لگتا ہے، لیکن ایک متحد انٹرفیس بنانے کے لیے، صفحات اور ٹکڑوں کو کسی نہ کسی طرح ملایا جانا چاہیے۔
اس کے لیے فرنٹ اینڈ انضمام کی ضرورت ہوتی ہے، جسے مختلف حکمت عملیوں کے ذریعے پورا کیا جا سکتا ہے، بشمول روٹنگ، کمپوزیشن، اور کمیونیکیشن (اوپر گرافک دیکھیں)۔
روٹنگ
جب ایک ٹیم کے زیر کنٹرول صفحہ کی خدمت دوسری ٹیم کی ملکیت والے صفحہ تک رسائی کے لیے درکار ہوتی ہے، تو روٹنگ صفحہ کی سطح کے انضمام کے لیے مفید ہے۔
ہر مائیکرو فرنٹ اینڈ کو ایک صفحے کی ایپلی کیشن کے طور پر سنبھالا جاتا ہے۔ روٹنگ فراہم کرنے کے لیے سادہ HTML لنکس کا استعمال کیا جا سکتا ہے۔
صارف براؤزر کو سرور سے ٹارگٹ مارک اپ ڈاؤن لوڈ کرنے پر مجبور کر سکتا ہے اور ہائپر لنکس پر کلک کر کے موجودہ صفحہ کو نئے صفحہ سے بدل سکتا ہے۔
ایپ شیل HTML، CSS، اور JavaScript کا کم از کم ہے جو UI کو طاقت دیتا ہے۔ یہاں تک کہ اگر سرور سے درخواست کردہ مواد کا ڈیٹا اب بھی انتظار کر رہا ہے، صارف کو فوری طور پر ایک جامد ڈسپلے شدہ صفحہ موصول ہوتا ہے۔ مرکزی ایپ شیل مختلف ٹیموں کے ذریعہ تخلیق کردہ سنگل پیج ایپس کے لیے پیرنٹ ایپلی کیشن کے طور پر کام کرتا ہے۔
اس بات سے کوئی فرق نہیں پڑتا ہے کہ لائبریری یا فریم ورک جو استعمال کیا جا رہا ہے، میٹا فریم ورک مختلف صفحات کے فیوژن کو ایک ہی میں فعال کرتے ہیں۔
مرکب
کمپوزیشن ٹکڑوں کو ایک صفحہ پر مناسب جگہوں پر فٹ کرنے کے لیے ترتیب دینے کا عمل ہے۔ زیادہ تر معاملات میں، صفحہ کو تعینات کرنے والی ٹیم فوری طور پر ٹکڑے کا مواد حاصل نہیں کرتی ہے۔
اس کے بجائے، یہ ایک پلیس ہولڈر یا مارکر رکھتا ہے جہاں ٹکڑا مارک اپ میں ہونا چاہیے۔
ایک مختلف کمپوزنگ عمل کا استعمال کرتے ہوئے، حتمی اسمبلی مکمل ہو جاتی ہے۔ ساخت کو دو بنیادی زمروں میں تقسیم کیا جاسکتا ہے: کلائنٹ سائڈ اور سرور سائڈ۔
کلائنٹ سائیڈ کمپوزیشن: ویب براؤزر کو HTML مارک اپ بنانے اور ترمیم کرنے کے لیے استعمال کیا جاتا ہے۔ ہر مائیکرو فرنٹ اینڈ میں اپنے مارک اپ کو باقی صفحے سے الگ تبدیل کرنے اور دکھانے کی صلاحیت ہوتی ہے۔
ویب اجزاء، مثال کے طور پر، آپ کو اس قسم کی تعمیر کو انجام دینے کی اجازت دیتے ہیں۔
منصوبہ یہ ہے کہ ہر ایک ٹکڑے کو ایک ویب جزو میں تبدیل کیا جائے جسے آزادانہ طور پر a.js فائل کے طور پر انسٹال کیا جا سکتا ہے، جس کے بعد ایپس ان کو تھیم لے آؤٹ میں ان کے لیے مخصوص جگہوں پر لوڈ اور رینڈر کر سکتی ہیں۔
ویب کے اجزاء HTML اور DOM API پر منحصر ہوتے ہیں، جسے دوسرے فرنٹ اینڈ فریم ورک استعمال کر سکتے ہیں، نیز پروپس اور ایونٹس کے ذریعے ڈیٹا بھیجنے اور وصول کرنے کا ایک معیاری طریقہ۔
سرور سائیڈ کمپوزیشن: اس ڈیزائن کے ساتھ، UI کے ٹکڑوں کو سرور پر جوڑ دیا جاتا ہے، جس کے نتیجے میں ایک مکمل طور پر تشکیل شدہ صفحہ کلائنٹ کی طرف بھیج دیا جاتا ہے، لوڈنگ میں تیزی آتی ہے۔
اسمبلی اکثر ایک علیحدہ سروس کے ذریعہ کی جاتی ہے جو ویب براؤزر اور ویب سرورز کے درمیان بیٹھتی ہے۔ CDN سروس (مواد کی ترسیل کے نیٹ ورک) کی ایک مثال ہے۔
آپ اپنی ضروریات کے مطابق ایک یا دونوں میں سے ایک کا انتخاب کر سکتے ہیں۔
مائیکرو فرنٹ اینڈ کمیونیکیشن پیٹرن
مائیکرو فرنٹ اینڈ فن تعمیر بہترین کام کرتا ہے جب مختلف اجزاء کے درمیان بہت کم یا کوئی تعامل نہ ہو۔ مائیکرو فرنٹ اینڈ کو کبھی کبھار ایک دوسرے سے بات کرنے اور معلومات کا اشتراک کرنے کی ضرورت ہوتی ہے۔ یہاں کچھ ممکنہ نمونے ہیں جو اس کا باعث بن سکتے ہیں۔
- ویب ورکرز: ایک آن لائن کارکن ایک ایسا طریقہ کار ہے جو ویب مواد کو جاوا اسکرپٹ کو پس منظر میں چلانے کے قابل بناتا ہے، دوسرے اسکرپٹ سے آزاد، اور صفحہ کی رفتار کو متاثر کیے بغیر۔ ہر مائیکرو ایپ کے لیے ایک منفرد ورکر API فراہم کیا جائے گا۔ اس کا فائدہ یہ ہے کہ وقت طلب کام ایک مختلف تھریڈ میں کیا جا سکتا ہے، جس سے UI تھریڈ کو سست یا روکے بغیر آگے بڑھنے کے قابل بنایا جا سکتا ہے۔
- ایونٹ ایمیٹر: اس صورت میں، بہت سے اجزاء ایک دوسرے کے ساتھ بات چیت کرتے ہیں جس کے لیے وہ سبسکرائب کیے گئے اجزاء میں کسی بھی حالت کی تبدیلیوں کو سن کر اور اس پر عمل کرتے ہیں۔ دوسرے مائیکرو فرنٹ اینڈز جنہوں نے اس مخصوص ایونٹ کو سبسکرائب کیا ہے جب ایک مائیکرو فرنٹ اینڈ اس ایونٹ کو فائر کرتا ہے تو جواب دیتے ہیں۔ ایک ایونٹ ایمیٹر جو ہر مائیکرو فرنٹ اینڈ میں متعارف کرایا گیا ہے اسے ممکن بناتا ہے۔
- کال بیکس اور سہارے: اس حصے میں، آپ والدین کے جزو اور بچے کے اجزاء کی وضاحت کرتے ہیں۔ مواصلات کو درخت کی طرح کی ساخت میں منظم کیا جاتا ہے. والدین کے اجزاء ڈیٹا کو جزو کے درخت کے نیچے بچوں کے اجزاء تک پہنچانے کے لیے پرپس کا استعمال کرتے ہیں۔ بدلے میں، بچہ کال بیکس کا جواب دے کر والدین کو مؤثر طریقے سے آگاہ کر سکتا ہے جب ان کی ریاست میں کچھ ہوتا ہے۔ React اس موڈ کو استعمال کرتا ہے۔
مائیکرو فرنٹ اینڈ کے فوائد
تیزی سے خود مختار ٹیموں میں ترقی
مائیکرو فرنٹ اینڈ طریقہ استعمال کرتے وقت ایک آزاد ٹیم ویب ایپ یا ویب سائٹ کا ہر حصہ بنا سکتی ہے۔
ہر ٹیم مکمل طور پر خود مختار ہے، جس کا مطلب یہ ہے کہ وہ تصور سے لے کر ریلیز اور پوسٹ پروڈکشن تک پورے اجزاء کی ترقی کے چکر کی انچارج ہے۔
مزید برآں، اس کا مطلب یہ ہے کہ ایک ہی پروجیکٹ پر بیک وقت کام کرتے ہوئے مختلف ٹیمیں بغیر کسی رکاوٹ کے تعاون کر سکتی ہیں۔
لہذا، رہائی کے چکر اس سے کہیں زیادہ تیز ہوتے ہیں جو کہ سامنے والے مونولتھس کے ساتھ ہوتے ہیں۔
انفرادی مائیکرو فرنٹنڈس کے چھوٹے کوڈ بیس کلینر کوڈ کی طرف لے جاتے ہیں۔
یک سنگی سامنے والے سروں میں بڑے، غیر معمولی کوڈ بیس ہوتے ہیں جو وقت کے ساتھ ساتھ انتظام کرنے میں تیزی سے افراتفری اور چیلنج بن جاتے ہیں۔
مائیکرو فرنٹ اینڈ اس مسئلے کو حل کرتے ہیں۔ ہر مائیکرو فرنٹ اینڈ کا سورس کوڈ زیادہ قابل انتظام ہے کیونکہ یہ چھوٹا، آسان اور زیادہ کمپیکٹ ہے۔
مجموعی طور پر ویب حل کلینر کوڈ سے فائدہ اٹھاتا ہے۔
ڈھیلے کپلنگ کی وجہ سے بہتر ایپ کا استحکام
ویب حل کو شاذ و نادر ہی مکمل طور پر آزاد ٹکڑوں میں تقسیم کیا جا سکتا ہے۔ اس کے نتیجے میں، مائیکرو فرنٹ اینڈ ایک دوسرے سے بات کرتے ہیں۔
تاہم، ڈھیلے کنیکٹوٹی کے باوجود اجزاء کے درمیان ہر ایک لنک اہم ہے۔
ایک جزو کی ناکامی کا باقی تمام اجزاء کے آپریشن پر کوئی اثر نہیں پڑتا، جو ویب حل کی بہتر استحکام فراہم کرتا ہے۔
انفرادی خصوصیات کی جانچ کو آسان بنایا گیا ہے۔
یہ فائدہ مائیکرو فرنٹ اینڈ کی خصوصیات سے حاصل ہوتا ہے۔ اس آرکیٹیکچرل ڈیزائن کی بنیاد پر، ویب حل کا کلائنٹ سائیڈ ماڈیولر ہے اور ہر ماڈیول خود مختار ہے۔
نتیجے کے طور پر، یوزر انٹرفیس کے ایک چھوٹے سے حصے کا بذات خود جائزہ لینا کسی ٹیم کے لیے بڑے پیمانے پر یک سنگی کی جانچ کرنے سے زیادہ آسان ہے۔
کم بنڈل سائز تیزی سے صفحہ لوڈ کرنے کی طرف جاتا ہے۔
خصوصیت سے بھرپور یک سنگی ویب سسٹمز میں تاخیر کے اوقات کی بنیادی وجوہات میں سے ایک JavaScript بنڈل کا سائز ہے۔ دوسری طرف، ایک مائیکرو فرنٹ اینڈ اپروچ پیج لوڈ ٹائم کو کم کرنا آسان بناتا ہے۔
ایک براؤزر کو بار بار غیر ضروری کوڈ ڈاؤن لوڈ کرنے کی ضرورت نہیں ہے کیونکہ ایک ویب صفحہ کئی چھوٹے بنڈلوں سے بنا ہوتا ہے۔ نتیجے کے طور پر، صفحہ کی کارکردگی اور لوڈ کے اوقات میں اضافہ ہوتا ہے۔
ٹیکنالوجی کی آزادی
ایک سے زیادہ سامنے کے آخر میں فریم ورک مائیکرو فرنٹ اینڈ آرکیٹیکچر کے ساتھ ایک آن لائن حل بنانے کے لیے ڈویلپرز استعمال کر سکتے ہیں۔
چونکہ ہر جزو خودمختار ہے، اس لیے ٹیم کے کاموں کے لیے جو بھی ٹیکنالوجی مناسب ہو اسے استعمال کرتے ہوئے اسے بنایا جا سکتا ہے۔
فطری طور پر، پروگرامرز کو اس سافٹ ویئر پروجیکٹ کے لیے فریم ورک کا انتخاب کرتے وقت احتیاط برتنی چاہیے جس کے وہ انچارج ہیں، اور دوسری ٹیموں کے ساتھ مشاورت کا ابھی بھی سخت مشورہ دیا جاتا ہے۔
تاہم، اس بات کا کوئی امکان نہیں ہے کہ آپ ایپ کی عمر کے دورانیے کے لیے میراثی فریم ورک استعمال کرنے پر مجبور ہوں گے۔
مائیکرو فرنٹ اینڈ کے نقصانات
مکمل طور پر پیچیدہ ویب حل کی جانچ
ویب حل کے مختلف ماڈیولز کی جانچ کرنا اس وقت آسان ہوتا ہے جب یہ مائیکرو فرنٹ اینڈ آرکیٹیکچر استعمال کرتا ہے۔ اگرچہ یہ مجموعی طور پر کسی ویب ایپلیکیشن کا جائزہ لینے سے مختلف ہے۔
جاری رکھنے سے پہلے تصدیق کریں کہ تمام پرزے ارادے کے مطابق کام کرتے ہیں۔ یہ مشکل ہو سکتا ہے کیونکہ مائیکرو فرنٹ اینڈز آزادانہ طور پر کام کرتے ہیں اور ان کی ترسیل کے الگ الگ عمل ہوتے ہیں۔
مہنگی ابتدائی سرمایہ کاری
مائیکرو فرنٹ اینڈ ڈیولپمنٹس عام طور پر کافی مالی اخراجات کا مطالبہ کرتے ہیں۔ بہت سی فرنٹ اینڈ ٹیموں کو جمع کرنا اور رکھنا مہنگا ہے۔
مزید برآں، آپ کو کام کو منظم کرنے کے لیے انتظامی اہلکاروں کی ضرورت ہوگی، اس بات کو یقینی بنائیں کہ ہر چیز مربوط ہے، اور بہترین ٹیم مواصلات کی ضمانت دے گی۔
ترقی اور تعیناتی کی پیچیدگی
مائیکرو فرنٹ اینڈ ڈیزائن کے نتیجے میں ترقی اور تعیناتی کے طریقہ کار مزید پیچیدہ ہو سکتے ہیں۔
ایک ہی پروجیکٹ پر کام کرنے والی آزاد ڈیولپمنٹ ٹیموں کے ذریعہ بہت سارے اجزاء کے ساتھ حل کو بے ترتیبی کیا جا سکتا ہے، مثال کے طور پر، جو تعیناتی کے مرحلے پر مسائل پیدا کر سکتا ہے۔
تمام ماڈیولز کی صحیح اسمبلی اور مجموعی اسکیم میں ان کا ہموار انضمام بھی ہمیشہ آسان نہیں ہوتا ہے۔ اس کام کے لیے عام طور پر تمام انحصارات کی مکمل تفہیم کی ضرورت ہوتی ہے۔
صارف کے تجربے میں ہم آہنگی کو برقرار رکھنے میں مسائل
جب ٹیمیں سافٹ ویئر کے کئی حصوں پر الگ الگ کام کرتی ہیں تو ایک مستقل صارف انٹرفیس کو برقرار رکھنا مشکل ہوتا ہے۔
ویب حل کو پروجیکٹ کے تمام ڈویلپرز کے ذریعہ شیئر کیا جانا چاہئے۔ دوسری صورت میں، سڑک کے ساتھ ساتھ بہت سے تضادات ہوسکتے ہیں.
نتیجہ
مائیکرو فرنٹ اینڈز، ایک عصری آرکیٹیکچرل ڈیزائن، بڑے پیمانے پر مائیکرو سروس پر مبنی ویب ڈویلپمنٹ پروجیکٹس کی کارکردگی کو بہت زیادہ بڑھا سکتا ہے۔
یہ پروگرامرز کو مکمل حل کو مجرد حصوں میں تقسیم کرنے کے قابل بناتا ہے جو کئی خود مختار ٹیموں کے ذریعے تخلیق کیا جا سکتا ہے۔ اس سے بہت سے فوائد حاصل ہوتے ہیں، بشمول تیز فیچر رول آؤٹ، انفرادی ماڈیولز کی آسان جانچ، اور مزید ہموار اپ گریڈ۔
لیکن مائکرو فرنٹ اینڈ کے ساتھ بھی کچھ مشکلات ہیں۔
ایک درخواست کی جامع جانچ، مثال کے طور پر، مشکل ہو سکتی ہے۔
مزید برآں، چونکہ انجینئرز اور منتظمین کی ایک بڑی ٹیم کی ضرورت ہے، اس لیے مائیکرو فرنٹ اینڈ پروجیکٹ بہت مہنگے ہیں۔
نتیجتاً، فیصلہ کرنے سے پہلے، آپ کو اپنے کاروباری کیس کے تمام اجزاء کو مدنظر رکھنا چاہیے۔
ولادیمیر Čamaj
کسی نہ کسی طرح میں سمجھ نہیں پایا کہ فرنٹ اینڈ پر انفرادی اجزاء کے درمیان بات چیت کس اصول پر کام کرتی ہے۔ مجھے سمجھ نہیں آ رہی کہ آپ مختلف فریم ورک میں بنائے گئے اجزاء کو کیسے جوڑنا چاہتے ہیں۔ اس کے بارے میں مضمون میں کچھ نہیں ہے۔ واقعات اور سننے والوں کا نظام مجھے زمین پر جہنم لگتا ہے۔ ہمیں اس کا تصور کیسے کرنا چاہیے؟