اپنی الماری کو منظم کرنے میں آپ کی مدد کے لیے فیشن ایپ کیسے بنائیں

اگرچہ میرے پاس پوری الماری تھی، میں یہ فیصلہ کرنے میں بہت زیادہ وقت صرف کرتا تھا کہ کیا پہننا ہے۔

اس مایوسی نے میرے لیے مسئلہ بالکل واضح کر دیا۔ کم کپڑے پہننا کوئی مسئلہ نہیں تھا۔ لباس کے فیصلے کرتے وقت بہتر تنظیم، بہتر مرئیت، اور بہتر رہنمائی فراہم کرنا ضروری تھا۔

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

اس آرٹیکل میں، ہم ایپ کے فیچرز، اسے کیسے بنایا گیا، راستے میں کیے گئے فیصلے، اور ان چیلنجز کو دیکھیں گے جنہوں نے حتمی نتیجہ کو شکل دی۔

انڈیکس

ایپ کیا کرتی ہے۔

اعلی سطح پر، ایپ چھ بنیادی خصوصیات کو یکجا کرتی ہے:

1. الماری کا انتظام

2. ملبوسات کی سفارشات

3. خریداری کی تجاویز

4. سفارش کو حذف کریں۔

5. تاثرات اور استعمال سے باخبر رہنا

6. ملٹی یوزر اکاؤنٹ سیکیورٹی

صارفین لباس کی اشیاء اپ لوڈ کر سکتے ہیں، تجویز کردہ لباس کو براؤز کر سکتے ہیں، اور سفارشات کو مددگار یا غیر مددگار کے طور پر نشان زد کر سکتے ہیں۔ آپ اپنے لباس کی درجہ بندی بھی کر سکتے ہیں اور یہ بھی ٹریک کر سکتے ہیں کہ آیا آئٹمز پہنے، ذخیرہ کیے گئے یا ضائع کیے گئے ہیں۔

یہ تاثرات مستقبل کی سفارشات کے معیار کو بہتر بنانے کے لیے منظم ڈیٹا بن جاتا ہے۔

میں نے اسے کیوں بنایا

میں کچھ ایسی تخلیق کرنا چاہتا تھا جو ذاتی اور حقیقت میں مفید محسوس ہو۔ بہت سی فیشن ایپس سجیلا نظر آتی ہیں، لیکن وہ روزمرہ کے فیصلوں میں ہمیشہ مددگار نہیں ہوتیں۔ میرا مقصد ایسی مصنوعات بنانا تھا جو الماری کے انتظام کو آسان اور لباس کے انتخاب کو کم مشکل بنائے۔ ایپ کو تین چیزیں اچھی طرح سے کرنی تھیں:

• ہر صارف کی الماری کا ڈیٹا محفوظ کریں۔

• اپنی سفارشات کو ذاتی بنائیں

• ہم وقت کے ساتھ صارف کے تاثرات سے سیکھتے ہیں۔

فیڈ بیک لوپس میرے لیے اہم تھے کیونکہ انہوں نے ایپ کو جامد کے بجائے زیادہ زندہ محسوس کیا۔

ٹیکنالوجی اسٹیک

یہ وہ ٹولز ہیں جو میں نے ایپ بنانے کے لیے استعمال کیے تھے۔

• فرنٹ اینڈ: React + Vite

• پسدید: فاسٹ اے پی آئی

• ڈیٹا بیس: SQLite (مقامی ترقی)

• پس منظر کے کام: سیلری + ریڈیس

• توثیق: JWT (رسائی + ریفریش ٹوکن فلو)

• تعیناتی کی حمایت: Docker اور GitHub Codespaces

یہ کافی حد تک ماڈیولر سیٹ اپ کی اجازت دیتا ہے جو خصوصیات میں اضافہ ہونے کے ساتھ ہی بہت مدد کرتا ہے، بشمول تیز فرنٹ اینڈ تکرار، صاف API حدود، اور UI سے علیحدہ سفارشات تیار کرنے کے لیے جگہ۔

پروڈکٹ ٹور (صارفین کیا دیکھتے ہیں)

1. آن بورڈنگ اور اکاؤنٹ سیٹ اپ

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

ہر اکاؤنٹ الگ ہے، لہذا الماری کی تاریخ اور سفارشات فی صارف رہیں۔

اوپر دی گئی آن بورڈنگ اسکرین آپ کو ایک اکاؤنٹ بنانے، اپنے ای میل کی تصدیق کرنے اور جسمانی قسم، قد، وزن، اور طرز کی ترجیحات کے لیے پروفائل فیلڈز دیکھنے کی اجازت دیتی ہے۔

2. اپنی الماری اپ لوڈ کریں۔

صارفین کپڑوں کی تصاویر اپ لوڈ کر سکتے ہیں۔

تصویری تجزیہ آپ کو ہر آئٹم پر لیبل لگانے اور سفارشات کو بازیافت کرنے کی اجازت دیتا ہے۔ الماری اپ لوڈ فارم زمرہ، بنیادی رنگ، ثانوی رنگ، اور پیٹرن کی تفصیلات کی فہرست میں آپ کی تصویر کے تجزیہ کے نتائج دکھاتا ہے۔

3. لباس کی سفارش

صارفین سفارشات کی درخواست کر سکتے ہیں اور پھر نتائج کا جائزہ لے سکتے ہیں۔

اوپر آپ Outfit Recommendations کا ڈیش بورڈ دیکھ سکتے ہیں، جو تاثرات اور درجہ بندی کے اعمال کے ساتھ درجہ بندی والے لباس کارڈ دکھاتا ہے۔ سفارشات کی درجہ بندی وزنی اسکورنگ ماڈل کی بنیاد پر کی جاتی ہے۔

4. شاپنگ اور ڈسپوزل اسسٹنٹ

ایپ آپ کے موجودہ وارڈروب ڈیٹا کے مطابق نئی آئٹمز کا جائزہ لیتی ہے اور کم قیمت والی الماری اشیاء کو جھنڈا دیتی ہے جن سے چھٹکارا حاصل کرنے کے قابل ہو سکتے ہیں۔

مندرجہ بالا ہر آئٹم کے لیے، آپ کو ایک سفارشی سکور، تحریری وجوہات (صرف بائنری فیصلہ نہیں) اور اسٹائلنگ کے رہنما خطوط ملیں گے۔ اگر آپ انہیں وہاں رکھنا چاہتے ہیں تو یہ آئٹمز کو "سٹائل کرنے کا طریقہ” بھی فراہم کرتا ہے۔

میں نے اسے کیسے بنایا

1. فرنٹ اینڈ سیٹ اپ (رد عمل + وائٹ)

ہم نے React + Vite کا استعمال کیا کیونکہ ہم تیز رفتار تکرار اور ایک صاف اجزاء کا ڈھانچہ چاہتے تھے۔

فرنٹ اینڈ کو فنکشنل ایریاز میں تقسیم کیا گیا ہے: آن بورڈنگ، وارڈروب مینجمنٹ، آؤٹ فِٹنگ، شاپنگ، اور ترک شدہ آئٹم کی تجاویز۔ یہ API کالز کو سروس لیئر میں بھی رکھتا ہے تاکہ UI اجزاء رینڈرنگ اور تعامل پر مرکوز رہ سکیں۔

ذیل کا ٹکڑا ایپ میں استعمال ہونے والے API سروس پیٹرن کی ایک سادہ مثال ہے۔ اسے کاپی اور پیسٹ نہیں کیا جا سکتا جیسا کہ ہے، لیکن یہ وہی ڈھانچہ دکھاتا ہے جسے فرنٹ اینڈ بیک اینڈ کے ساتھ بات چیت کرتے وقت استعمال کرتا ہے۔

مثال API کلائنٹ پیٹرن:

export async function getOutfitRecommendations(userId, params = {}) {
  const query = new URLSearchParams(params).toString();
  const url = `/users/({userId}/outfits/recommend){query ? `?${query}` : ""}`;

  const response = await fetch(url, {
    headers: {
      Authorization: `Bearer ${localStorage.getItem("access_token")}`,
    },
  });

  if (!response.ok) {
    throw new Error("Failed to fetch outfit recommendations");
  }

  return response.json();
}

اس ٹکڑوں میں کیا ہوتا ہے یہاں ہے:

• URLSearchParams مندرجہ ذیل کی طرح ایک اختیاری استفسار سٹرنگ لکھیں: occasion, seasonیا limit.

• درخواست کے راستے صارف کے دائرہ کار میں ہیں، ہر صارف کی سفارشات کو الگ تھلگ رکھتے ہوئے۔

• کہ Authorization ہیڈر ایک رسائی ٹوکن بھیجتا ہے تاکہ بیک اینڈ سیشن کی تصدیق کر سکے۔

• چونکہ ہم جواب کو پارس کرنے سے پہلے چیک کرتے ہیں، اس لیے درخواست ناکام ہونے کی صورت میں UI ایک مفید خامی ظاہر کر سکتا ہے۔

اس پیٹرن نے فرنٹ اینڈ کو سادہ اور دوبارہ قابل استعمال رکھا کیونکہ API کالز کی تعداد میں اضافہ ہوا۔

2. فاسٹ اے پی آئی کا استعمال کرتے ہوئے بیک اینڈ فن تعمیر

پسدید کو صاف روٹ گروپس کے گرد منظم کیا گیا ہے۔

• رجسٹریشن، لاگ ان، ریفریش، لاگ آؤٹ، اور سیشنز کے لیے تصدیقی راستے

• صارف کے تجزیہ کا راستہ

• الماری CRUD پاتھ

• کپڑے کی سفارش کا راستہ، خریداری، اور ضائع کرنے کا تجزیہ

• تشخیص اور استعمال کے سگنل کے لیے تاثرات کا راستہ

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

ذیل میں بیک اینڈ کا ٹکڑا ایپ پاتھ پرت کی ایک اور آسان مثال ہے۔ اصل اسکورنگ ٹاسک تجویز کنندہ کی خدمت پر قائم رہتے ہوئے درخواست کی توثیق اور مفاہمت کی منطق کو ظاہر کرتا ہے۔

@app.get("/users/{user_id}/outfits/recommend")
def recommend_outfits(user_id: int, occasion: str | None = None, season: str | None = None, limit: int = 10):
    user = get_user_or_404(user_id)
    wardrobe_items = get_user_wardrobe(user_id)

    if len(wardrobe_items) < 2:
        raise HTTPException(status_code=400, detail="Not enough wardrobe items")

    recommendations = outfit_generator.generate_outfit_recommendations(
        wardrobe_items=wardrobe_items,
        body_shape=user.body_shape,
        undertone=user.undertone,
        occasion=occasion,
        season=season,
        top_k=limit,
    )

    return {"user_id": user_id, "recommendations": recommendations}

اس کوڈ کو پڑھنے کا طریقہ یہاں ہے:

• get_user_or_404 ذاتی نوعیت کے لیے درکار پروفائل ڈیٹا لوڈ کریں۔

• get_user_wardrobe صرف موجودہ صارف کے آئٹمز کو بازیافت کیا جاتا ہے۔

• کم سے کم الماری کی جانچ نامکمل ڈیٹا پر سفارش کی منطق کو چلنے سے روکتی ہے۔

• generate_outfit_recommendations اسکورنگ منطق کو الگ سے ہینڈل کرنا روٹ ہینڈلرز کو چھوٹا اور جانچنے میں آسان رکھتا ہے۔

• جواب ایک ایسی شکل میں نتائج دیتا ہے جسے فرنٹ اینڈ براہ راست استعمال کر سکتا ہے۔

اس علیحدگی نے API پرت کو پڑھنے کے قابل رکھنے میں مدد کی جبکہ سفارش کی منطق اپنی خدمت میں الگ تھلگ رہی۔

3. تجویز کی منطق

میں نے جان بوجھ کر ہیوی ایم ایل کو متعارف کرانے سے پہلے تعییناتی اصولوں کے ساتھ آغاز کیا۔ یہ رویے کو ڈیبگ کرنے اور بیان کرنے میں آسان بناتا ہے۔

ملبوسات کا تجویز کنندہ مجموعوں کو اسکور کرنے کے لیے وزنی سگنل استعمال کرتا ہے۔

$$text{Clothing Score} = 0.4 cdot text{Color Harmony} + 0.4 cdot text{Body Fit} + 0.2 cdot text{Low Fit}$$

ذیل کا ٹکڑا سفارشی انجن کی ایک سادہ مثال ہے۔ ایپ دکھاتی ہے کہ ایک ہی سکور میں متعدد سگنلز کو کیسے ملایا جائے۔

def score_outfit(combo, user_context):
    color_score = color_harmony.score(combo)
    shape_score = body_shape_rules.score(combo, user_context.body_shape)
    undertone_score = undertone_rules.score(combo, user_context.undertone)

    total = 0.4 * color_score + 0.4 * shape_score + 0.2 * undertone_score
    return round(total, 3)

اس نقطہ نظر کے پیچھے منطق سادہ ہے.

• رنگوں کی ہم آہنگی آپ کے لباس کو بصری طور پر مستقل محسوس کرنے میں مدد کرتی ہے۔

• جسمانی شکل کا اسکور آپ کے لباس کو نمایاں کرنے میں مدد کرتا ہے۔

• انڈر ٹون گریڈنگ رنگوں کو آپ کے صارف پروفائل سے بہتر طریقے سے ملنے میں مدد کرتا ہے۔

ہم نے اپنی تصرف کی سفارشات اور خریداری کی تجاویز کے لیے ایک جیسا ڈھانچہ استعمال کیا، لیکن مختلف عناصر اور حد کے ساتھ۔

4. تصدیق اور محفوظ کثیر صارف ڈیزائن

سیکورٹی اس تعمیر کے سب سے اہم پہلوؤں میں سے ایک تھا۔

میں نے مندرجہ ذیل کو لاگو کیا:

• مختصر مدت تک رسائی کا ٹوکن

• JTI ٹریس کے ساتھ ٹوکن ریفریش کریں۔

• ریفریش پر ٹوکن کی گردش

• سیشن کی منسوخی (ایک سیشن اور تمام سیشنز)

• ای میل کی تصدیق اور پاس ورڈ دوبارہ ترتیب دینے کا بہاؤ

ذیل کا ٹکڑا ایپ میں استعمال ہونے والے ریفریش ٹوکن لائف سائیکل کی ایک سادہ مثال ہے۔ تمام مددگار خصوصیات کے بجائے اہم کنٹرول پوائنٹس دکھاتا ہے۔

def refresh_access_token(refresh_token: str):
    payload = decode_jwt(refresh_token)
    jti = payload["jti"]

    token_record = db.get_refresh_token(jti)
    if not token_record or token_record.revoked:
        raise AuthError("Invalid refresh token")

    new_refresh, new_jti = issue_refresh_token(payload["sub"])
    token_record.revoked = True
    token_record.replaced_by_jti = new_jti

    new_access = issue_access_token(payload["sub"])
    return {"access_token": new_access, "refresh_token": new_refresh}

یہ کوڈ کیا کرتا ہے:

• ریفریش ٹوکن کو ڈی کوڈ کریں اور ڈیٹا بیس میں متعلقہ JTI تلاش کریں۔

• یہ دوبارہ استعمال شدہ یا منسوخ شدہ سیشنز کو مسترد کرکے ری پلے حملوں کو روکنے میں مدد کرتا ہے۔

• ریفریش ٹوکنز کو دوبارہ استعمال کرنے کے بجائے، ہم انہیں سائیکل کرتے ہیں۔

• ایک نیا رسائی ٹوکن جاری کریں تاکہ صارف کو دوبارہ لاگ ان کیے بغیر سیشن درست رہے۔

اس ڈیزائن نے ملٹی ڈیوائس سیشنز کو زیادہ محفوظ بنایا اور سرور سائیڈ پر لاگ آؤٹ رویے کو کنٹرول کرنے کی اجازت دی۔

5. طویل عرصے سے چلنے والے کاموں کے لیے پس منظر کے کام

تصویری تجزیہ مہنگا ہو سکتا ہے، خاص طور پر اگر آپ کی ایپ کو کپڑوں کی درجہ بندی کرنے، رنگ کا تجزیہ کرنے اور جسمانی شکل سے متعلق سگنلز کا اندازہ لگانے کی ضرورت ہو۔ درخواست کے راستوں کو ریسپانسیو رکھنے کے لیے بیک گراؤنڈ ٹاسک کے لیے سیلری + ریڈیس سپورٹ شامل کیا گیا۔

اس سے ایپ کو دو موڈ ملے:

یہ سمجھوتہ اہم تھا کیونکہ اس نے ہمیں زیادہ مہنگے آپریشنز کے دوران ایپس کو مسدود کیے بغیر ڈویلپر کے تجربے کو آسان رکھنے کی اجازت دی۔

6. ڈیٹا ماڈل اور آراء جمع کرنا

تجویز کنندہ کے نظام صرف اس صورت میں بہتر ہوتے ہیں جب وہ صحیح سگنل پکڑتے ہیں۔

لہذا ہم نے فیڈ بیک ٹیبلز کو شامل کیا ہے:

• لباس کی درجہ بندی (1-5 + اختیاری تفصیل)

• تجویز کریں کہ مددگار نہیں ہے/مفید نہیں آراء

• شے کے استعمال کا برتاؤ (پہننا/ذخیرہ کرنا/تصرف کرنا)

یہاں ان ماڈلز میں سے ایک کیسا لگتا ہے:

class RecommendationFeedback(Base):
    __tablename__ = "recommendation_feedback"

    id = Column(Integer, primary_key=True)
    user_id = Column(Integer, ForeignKey("users.id"), nullable=False)
    recommendation_type = Column(String(50), nullable=False)
    recommendation_id = Column(Integer, nullable=False)
    helpful = Column(Boolean, nullable=False)
    created_at = Column(DateTime, default=datetime.utcnow)

اس ماڈل کو کیسے پڑھیں:

• user_id تاثرات اس شخص سے جوڑیں جس نے اسے فراہم کیا۔

• recommendation_type ہمیں بتائیں کہ کیا آپ کے تاثرات کا تعلق لباس، خریداری، یا ضائع کرنے کی تجاویز سے ہے۔

• recommendation_id درست حوالہ جات کی شناخت کریں۔

• helpful صارفین کے براہ راست جوابات کو اسٹور کریں۔

• created_at آپ وقت کے ساتھ تاثرات کے رجحانات کا تجزیہ کر سکتے ہیں۔

سسٹم کا یہ حصہ ایپ کے لیے ایک حقیقی سیکھنے کی بنیاد فراہم کرتا ہے، حالانکہ فیڈ بیک ماڈل اپ ڈیٹ لوپ اب بھی مستقبل میں بہتری ہے۔

مشکلات کا سامنا

یہ وہ حصہ تھا جہاں میں نے سب سے زیادہ سیکھا۔

1. امیج ہیوی اینڈ پوائنٹ مطلوبہ سے زیادہ سست تھا۔

تجزیہ اور الماری اپ لوڈ کے بہاؤ نے ایک ساتھ بہت سے کام انجام دیے: تصویر کی تصدیق، درجہ بندی، رنگ نکالنا، اسٹوریج، اور ڈیٹا بیس لکھنا۔

شروع میں، درخواست کا بہاؤ توقع سے زیادہ بھاری محسوس ہوا۔

میں نے کیا تبدیل کیا:

• ایپ کو ایک ساتھ بہت ساری چیزیں کرنے کی کوشش کرنے سے روکنے کے لیے ہم نے سمورتی تصویری کارروائیوں کو محدود کر دیا۔

• جہاں ممکن ہو، سست کاموں کو بیک گراؤنڈ پروسیسنگ میں الگ کر دیا گیا۔

• ہم نے لوڈ ٹیسٹ کے نتائج کا استعمال اس بات کا تعین کرنے کے لیے کیا کہ کون سے اینڈ پوائنٹس واقعی مہنگے ہیں۔

اس کا عملی اثر یہ تھا کہ تصویر کی ضرورت سے زیادہ درخواستوں نے ایک دوسرے کے ساتھ جارحانہ مقابلہ کرنا چھوڑ دیا۔ ایک ہی درخواست کے چکر میں بہت سے مہنگے کاموں کو اسٹیک کرنے کے بجائے، ہم نے فعال کاموں کو محدود کر دیا اور ضرورت پڑنے پر سست کاموں کو قطار میں دھکیل دیا۔

مسئلہ کیوں حل ہوا:

• باؤنڈڈ کنکرنسی نے سسٹم کو سی پی یو کے پابند کاموں سے اوورلوڈ ہونے سے روک دیا۔

• مہنگے آپریشنز کو غیر مطابقت پذیر آپریشنز میں منتقل کرنے سے بنیادی درخواست/جوابی سائیکل کی ردعمل بہتر ہوتی ہے۔

• لوڈ ٹیسٹنگ نے ہمیں اندازہ لگانے کے بجائے ثبوت دیا، جس سے ہمیں کارکردگی کے حقیقی رویے کی بنیاد پر سسٹم کو ٹیون کرنے کی اجازت ملی۔

دوسرے الفاظ میں، آپ نظریاتی طور پر اختتامی نقطہ کو "بہتر" نہیں کر رہے ہیں۔ ہم نے عمل درآمد کے ماڈل کو تبدیل کیا تاکہ ایک مہنگا تجزیہ اس کے پیچھے دیگر تمام درخواستوں کو روک نہیں سکتا۔

2. JWT سیشنز کو اصل سرور سائیڈ کنٹرول کی ضرورت ہوتی ہے۔

بنیادی JWT سیٹ اپ کے ساتھ کام کرنا آسان ہے، لیکن اگر آپ سیشن منسوخ نہیں کر سکتے یا متعدد آلات کو صاف ستھرا انتظام نہیں کر سکتے ہیں تو یہ کم مفید ہے۔

میں نے کیا تبدیل کیا:

• ریفریش ٹوکن کو ڈیٹا بیس میں محفوظ کیا۔

• میں نے ٹوکن JTI ویلیو کو ٹریک کیا۔

• ریفریش ٹوکن کو تبدیل کر دیا گیا جب صارف نے سیشن کو ریفریش کیا۔

• ایک سیشن یا تمام سیشنز کو لاگ آؤٹ کرنے کے لیے ایک اختتامی نقطہ شامل کیا گیا۔

یہاں اہم تبدیلی یہ ہے کہ "ٹوکن موجود ہے، لہذا سیشن درست ہے" سے "ٹوکن موجود ہے، ڈیٹا بیس ریکارڈ سے میل کھاتا ہے، اور اسے منسوخ یا تبدیل نہیں کیا گیا ہے۔" اس سے سرور کو پچھلے سیشن کو فوری طور پر باطل کرنے کا اختیار مل گیا۔

مسئلہ کیوں حل ہوا:

• سرور سائیڈ ٹوکن ٹریکنگ منسوخی کو ممکن بناتی ہے۔

• گردش ٹوکن کے دوبارہ استعمال کے امکان کو کم کر دیتی ہے۔

• ایپ کو زیادہ قابل اعتماد بناتے ہوئے سیشن کا انتظام صارف کے سامنے ہے۔

یہ لاگ آؤٹ اور ملٹی ڈیوائس مینجمنٹ کو صرف ایک کاسمیٹک UI چیز کی بجائے حقیقی طریقے سے کام کرتا ہے۔

3. صارف کے ڈیٹا کی تنہائی کو واضح ہونا ضروری تھا۔

چونکہ یہ ایک کثیر صارف ایپ ہے، ہمیں اس بات کو یقینی بنانے کے لیے محتاط رہنا چاہیے کہ ایک اکاؤنٹ غلطی سے دوسرے اکاؤنٹ کے الماری کا ڈیٹا نہ دیکھ سکے۔

میں نے کیا تبدیل کیا:

• صارف کے دائرہ کار والے راستوں میں ملکیت کا چیک شامل کر دیا گیا۔

• میں نے تمام الماریوں اور تاثرات کے سوالات کو فلٹر کیا ہے بذریعہ: user_id.

• کچے راستوں کو ظاہر کرنے کے بجائے، ہم نے انکرپٹڈ امیج اسٹوریج کا استعمال کیا۔

عملی طور پر، اس کا مطلب ہے کہ تمام راستوں کو ایک جیسے سوالات پوچھنے چاہئیں۔ "کیا یہ صارف اس وسائل کا مالک ہے جس تک وہ رسائی حاصل کرنے کی کوشش کر رہا ہے؟" اگر جواب نفی میں آیا تو درخواست کو فوراً روک دیا گیا۔

مسئلہ کیوں حل ہوا:

• ڈیٹا تک رسائی کے قوانین کو ملکیت کی تصدیق کے ساتھ واضح کیا جاتا ہے۔

• صارف کے فلٹر کردہ استفسارات حادثاتی کراس اکاؤنٹ ریڈز کو روکتے ہیں۔

• خفیہ کردہ اسٹوریج رازداری کے تحفظ کو بڑھاتا ہے اور تصویری ڈیٹا کے براہ راست سامنے آنے کے خطرے کو کم کرتا ہے۔

یہ مجموعہ اس بات کو یقینی بناتا ہے کہ آپ کے الماری کا ڈیٹا، تاثرات کی سرگزشت، اور تصاویر متعدد اکاؤنٹس میں مناسب طریقے سے الگ رہیں۔

4. ڈوکر پروجیکٹس کو شیئر کرنا آسان بناتا ہے، لیکن اسٹیک کو منظم کرنے کے بعد ہی۔

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

میں نے کیا تبدیل کیا:

• آپ نے ڈوکر کمپوز میں اسٹیک کی وضاحت کی ہے۔

• میں نے مطلوبہ ماحولیاتی متغیرات کو دستاویز کیا ہے۔

• میں نے ڈویلپمنٹ اسٹیک کو اس کے ساتھ منسلک رکھا کہ ایپ اصل میں کیسے چلے گی۔

اس سے سیٹ اپ کا بہت سا ابہام دور ہو گیا۔ کسی کو دستی طور پر یہ جاننے کے لیے کہنے کے بجائے کہ فرنٹ اینڈ، بیک اینڈ، ریڈیس اور ورکرز ایک ساتھ کیسے فٹ ہوتے ہیں، ہم نے اسٹیک کو خود وضاحتی بنا دیا۔

مسئلہ کیوں حل ہوا:

• ڈوکر شراکت داروں کو کم دستی اقدامات کے ساتھ پروجیکٹ شروع کرنے کی اجازت دیتا ہے۔

• واضح کنفیگریشن کنفیگریشن سیٹ اپ کی غلطیوں کو کم کرتی ہے۔

• اپنے اسٹیک کو اپنے فن تعمیر کے ساتھ سیدھ میں لانا آپ کی ایپ کو سمجھنا اور جانچنا آسان بناتا ہے۔

یہ اہم تھا کیونکہ ایپس بہت سے متحرک حصوں پر انحصار کرتی ہیں، اور کسی پروجیکٹ کو قابل رسائی بنانے کا سب سے آسان طریقہ یہ تھا کہ اس کے اسٹارٹ اپ رویے کو قابل پیشن گوئی بنایا جائے۔

میں نے کیا سیکھا

اس منصوبے نے مجھے کچھ اہم سبق سکھائے۔

• جب چھوٹی خصوصیات ایک ساتھ کام کرتی ہیں، تو وہ بہت زیادہ قیمتی ہو جاتی ہیں۔

• فیڈ بیک ڈیٹا سفارشات کو بہتر بنانے کے لیے سب سے زیادہ طاقتور سگنلز میں سے ایک ہے۔

• جب متعدد صارفین اس میں شامل ہوں تو کلین ڈیٹا ماڈلنگ اہم ہے۔

• Docker اور واضح سیٹ اپ ہدایات دوسروں کے لیے آپ کے پروجیکٹ کو آزمانا بہت آسان بناتی ہیں۔

میں نے یہ بھی سیکھا کہ کسی پروجیکٹ کا مفید ہونے کے لیے بہت بڑا ہونا ضروری نہیں ہے۔ ایک فوکسڈ ایپ جو ایک مسئلے کو اچھی طرح سے حل کرتی ہے وہ اب بھی معنی خیز محسوس کر سکتی ہے۔

جن چیزوں کو میں مستقبل میں بہتر کرنا چاہوں گا۔

یہ میرا روڈ میپ ہے:

1. فیڈ بیک کو براہ راست درجہ بندی کی تازہ کاریوں میں ضم کریں۔

2. سفارشی معیار کے رجحانات کے لیے بصری تجزیات شامل کریں۔

3. بہتر موبائل UX برابری۔

4. مستقل کلاؤڈ اسٹوریج اور پروڈکشن ڈیٹا بیس ڈیفالٹس کا استعمال کرتے ہوئے تعینات کریں۔

5. آسان تشخیص کے لیے عوامی ڈیمو موڈ فراہم کرتا ہے۔

مستقبل میں بہتری

اب بھی کچھ چیزیں باقی ہیں جو میں بعد میں شامل کرنا چاہوں گا۔

• ایک زیادہ جدید سفارشی انجن

• صارف کے تاثرات کا بصری تجزیہ

• بہتر موبائل سپورٹ

• مستقل کلاؤڈ اسٹوریج کا استعمال کرتے ہوئے ریئل ٹائم تعیناتی۔

• آسان جانچ کے لیے عوامی ڈیمو موڈ

نتیجہ

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

سب سے زیادہ فائدہ مند حصہ یہ دیکھنا تھا کہ کس طرح عملی سافٹ ویئر فیصلوں نے، نہ صرف چمکدار UIs، لوگوں کو روزمرہ کے انتخاب کو تیز تر کرنے میں مدد کی۔

پروجیکٹ کو دریافت کرنے یا چلانے کے لیے ریپوزٹری کو چیک کریں۔ آپ بہاؤ کو آزما سکتے ہیں اور اپنی رائے کا اشتراک کر سکتے ہیں۔ ہم خاص طور پر سفارش کے معیار، UX کی وضاحت، اور ان خصوصیات کے بارے میں آپ کے خیالات سننے میں دلچسپی رکھتے ہیں جو اسے روزمرہ کی زندگی میں واقعی مفید بناتی ہیں۔