Project: Mobile Auth နှင့် Notification Architecture

နားလည်ထားရမယ့် အချက်

ဤ project သည် ဤ course ထဲက identity နှင့် messaging ကို အဓိကထားသော lesson နှစ်ခုဖြစ်သည့် mobile authentication architecture နှင့် push notification architecture ကို ပေါင်းစပ်ထားသည်။ lesson တစ်ခုချင်းစီက loop တစ်ခုစီကိုသာ ရှင်းပြခဲ့သည် — user တစ်ဦးက သူ့ကိုယ်သူ ဘယ်လို သက်သေပြပြီး session ကို ဘယ်လို ဆက်လက် active ထားလဲ၊ backend က install လုပ်ထားသော app instance အတိအကျတစ်ခုဆီကို polling မလုပ်ဘဲ ဘယ်လို ရောက်စေလဲ။ app အစစ်တစ်ခု တည်ဆောက်ရန်အတွက် ထို loop နှစ်ခုကို ချိတ်ဆက်ဖို့ လိုအပ်သည် — အကြောင်းမှာ backend က user ဘယ်ဦး၏ device ဆီ ပို့ရမည်ကို မသိပါက push notification သည် အသုံးမဝင်တော့သောကြောင့် ဖြစ်ပြီး၊ ထို link သည် authentication နှင့် device registration တို့ တစ်ခုနှင့်တစ်ခု ပြောဆိုမှသာ ရှိလာနိုင်သောကြောင့် ဖြစ်သည်။

• Mobile authentication architecture — login, session token, secure storage, နှင့် နောက်ဆက်တွဲ authenticated call တိုင်း
• Push notification architecture — device-token registration နှင့် backend တစ်ခုက install လုပ်ထားသော app အတိအကျတစ်ခုဆီ ဘယ်လိုရောက်လဲ

ဤ project ၏ စိတ်ကူးယဉ် app သည် user account နှင့် lesson-reminder notification ပါဝင်သော learning platform တစ်ခု ဖြစ်ပြီး၊ ဤ course ရှိရာ site အစစ်နှင့် တမင်တကာ နီးစပ်အောင် ရွေးထားသည်။ learner တစ်ဦးသည် email/password ဖြင့်သော်လည်းကောင်း၊ password သီးခြား စီမံစရာမလိုသော alternative path အဖြစ် Google ကဲ့သို့ OAuth provider မှတစ်ဆင့်သော်လည်းကောင်း login ဝင်နိုင်သည်။

path နှစ်ခုစလုံးသည် mobile authentication architecture ထဲက session token တစ်ခုတည်းဆီသို့ စုစည်းသွားသည်။ ထို token သည် plain preferences ထဲသို့ မဟုတ်ဘဲ device ပေါ်ရှိ secure storage ထဲသို့ ဝင်ပြီး၊ push-notification lesson ၏ device-token registration call အပါအဝင် နောက်ဆက်တွဲ API call တိုင်းသည် ၎င်းကို identity အထောက်အထားအဖြစ် ယူဆောင်သွားသည်။

project တစ်ခုလုံးကို ဆက်စပ်ပေးနေသော design အသေးစိတ်မှာ backend ၏ data model ဖြစ်သည် — device token ကို ၎င်းတစ်ခုတည်းသီးသန့် သိမ်းမည့်အစား၊ authenticated call အောင်မြင်ပြီးမှသာ ဖြည့်စွက်မည့် user id နှင့် linked ဖြစ်သော device token အဖြစ် သိမ်းသည်။

notification ပေးလောက်သော event တစ်ခု ဖြစ်ပေါ်လာသောအခါ — ဤ scenario ၌ lesson အသစ် unlock ဖြစ်လာခြင်း — backend သည် device ကို တိုက်ရိုက် ဆက်သွယ်မည့်အစား ထို user ၏ သိမ်းထားသော device token ကို ရှာဖွေပြီး Apple (သို့) Google ၏ notification service မှတစ်ဆင့် push ကို ပို့သည်။

MOBILE AUTH + PUSH NOTIFICATION ARCHITECTURE
--------------------------------------------
[Login: password]  or  [Login: OAuth (Google)]
              |
              v
     [Backend issues session token]
              |
              v
   [Token stored in secure storage on device]
              |
              v
  [Authenticated API calls]  +  [Device token registration]
              |
              v
   [Backend: user record now linked to device token]
              |
              v
        [Event: new lesson unlocked]
              |
              v
     [Push service: Apple APNs / Google FCM]
              |
              v
           [Learner's device]

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

• push notification တစ်ခု ကောင်းမကောင်းသည် user id အတည်ပြုပြီးသားနှင့် device token ကြားက link ပေါ်တွင်သာ မူတည်သည် — backend သည် တစ်ခုတည်းသီးသန့် ဘယ်တော့မှ မသိမ်းသင့်ပါ။
• OAuth login နှင့် password login နှစ်ခုစလုံးသည် session token တစ်ခုတည်းသို့ ရောက်သည် — path ဘယ်ဟာကို learner ယူသည်ကို architecture ကျန်ပိုင်းက ဂရုမစိုက်ပါ။
• Device-token registration ကိုယ်တိုင်သည် authenticated API call တစ်ခုဖြစ်ပြီး token မရှိ (သို့) invalid ဖြစ်ပါက API call တခြားများကဲ့သို့ပင် ပယ်ချခံရမည်။

အတူတူ စမ်းရေးကြည့်မယ်

function simulateAuthAndNotificationFlow(user, event) {
  const steps = [];

  if (!user.isAuthenticated) {
    steps.push("Auth check: FAILED - no valid session token");
    steps.push("Aborting before device-token lookup");
    return { user: user.name, event, steps, notificationSent: false };
  }
  steps.push("Auth check: PASSED - session token valid");

  if (!user.deviceToken) {
    steps.push("Device token lookup: NONE REGISTERED");
    steps.push("Aborting before push dispatch");
    return { user: user.name, event, steps, notificationSent: false };
  }
  steps.push(`Device token lookup: FOUND (${user.deviceToken})`);

  steps.push(`Event received: "${event}"`);
  steps.push(`Push dispatch: sending to ${user.platform} push service`);
  steps.push(`Notification delivered to device ${user.deviceToken}`);

  return { user: user.name, event, steps, notificationSent: true };
}

const scenarios = [
  {
    user: {
      name: "Aye (authenticated, registered device)",
      isAuthenticated: true,
      deviceToken: "device-abc123",
      platform: "Android (FCM)"
    },
    event: "New lesson unlocked: How Mobile Apps Work"
  },
  {
    user: {
      name: "Unknown visitor (no session)",
      isAuthenticated: false,
      deviceToken: null,
      platform: null
    },
    event: "New lesson unlocked: How Mobile Apps Work"
  }
];

scenarios.forEach(({ user, event }) => {
  const result = simulateAuthAndNotificationFlow(user, event);
  console.log(`${result.user}`);
  result.steps.forEach((s) => console.log(`  - ${s}`));
  console.log(`  Notification sent: ${result.notificationSent}\n`);
});

scenario နှစ်ခုကို run လုပ်လျှင် — device register ပြီးသား authenticated user သည် auth check ကို ဖြတ်သန်းပြီး device token "device-abc123" ကို ရှာတွေ့ကာ push dispatch/delivery အောင်မြင်ကြောင်း log ထုတ်ပြီး notificationSent: true နှင့် အဆုံးသတ်သည်။ authenticate မလုပ်ရသေးသော visitor သည် auth check ကို ချက်ချင်း ကျရှုံးကာ abort message တစ်ခု log ထုတ်ပြီး notificationSent: false နှင့် အဆုံးသတ်သည် — device-token lookup ဘယ်တော့မှ run မဖြစ်ပါ။

Firebase Cloud Messaging — Architectural Overview — How Mobile Apps Work