Polling, WebSocket နှင့် Server-Sent Events

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

ပုံမှန် HTTP သည် ရိုးရှင်းသော အပြန်အလှန်ပုံစံကို လိုက်နာသည် — client က request ပို့ပြီး server က response တစ်ခု ပြန်ပေးသည်၊ ပြီးရင် အဲဒီ exchange အတွက် connection ရဲ့ အလုပ် ပြီးဆုံးသွားသည်။

ဒီပုံစံက page load လုပ်ခြင်း ဒါမှမဟုတ် form တင်ခြင်းအတွက် ကောင်းစွာအလုပ်လုပ်ပါတယ်၊ ဒါပေမယ့် အခြားနေရာမှာ တစ်ခုခု ပြောင်းလဲတာနဲ့ ချက်ချင်း update လိုအပ်တဲ့ အရာများ — chat message ရောက်လာခြင်း, live dashboard metric တက်လာခြင်း, notification, multiplayer game move, trading price ပြောင်းလဲခြင်းစသည်တို့အတွက်တော့ မလုံလောက်ပါဘူး။

ဒီကိစ္စအားလုံးမှာ browser သည် user တစ်ခုခု click လုပ်ဖို့ ငံ့လင့်နေလို့ မရပါဘူး — အဲဒီအချိန်မှာ မတောင်းဆိုထားတဲ့ ပြောင်းလဲမှုတွေကို သိရှိဖို့ လိုအပ်ပါတယ်။

Polling က အရိုးရှင်းဆုံး ဖြေရှင်းချက်ဖြစ်ပါတယ် — client က timer တစ်ခုပေါ်မှာ 'ဘာအသစ်ရှိလဲ' လို့ request အသစ်ကို ထပ်ခါထပ်ခါ ပို့နေပါတယ်။ ဆောက်လုပ်ရလွယ်ကူပြီး plain HTTP နဲ့ အလုပ်လုပ်ပေမယ့် ဘာမှမပြောင်းလဲတဲ့အခါ request တွေကို အလဟဿဖြစ်စေပြီး check ချိန်ကြားက interval ရဲ့ ကြာချိန်အတိုင်း delay ဖြစ်စေပါတယ်။

WebSocket ကတော့ နည်းလမ်းမတူပါဘူး — initial handshake တစ်ခုပြီးရင် client နဲ့ server နှစ်ဦးလုံးက request အသစ်စတင်စရာမလိုဘဲ အချိန်မရွေး ဘက်နှစ်ဘက်စလုံးကို message ပို့နိုင်တဲ့ long-lived connection တစ်ခုကို ဖွင့်ပေးပါတယ်။

ဒါက chat, live notification, real-time collaboration နဲ့ multiplayer interaction တွေအတွက် ကောင်းစွာကိုက်ညီပါတယ်။ WebSocket သည် HTTP ကို အစားထိုးခြင်း မဟုတ်ပါ — ပုံမှန် request-response exchange များထက် တည်ငြိမ်သော two-way traffic နှင့် သင့်တော်သော tool မတူညီတစ်ခုအနေနှင့် ဘေးတွဲ တည်ရှိနေခြင်းသာ ဖြစ်သည်။

Server-Sent Events (SSE) သည် နှစ်ခုကြားတွင် ရှိသည် — server သည် connection ကို ဖွင့်ထားပြီး client ဆီသို့ update များကို တစ်ဖက်တည်း (server မှ client သို့) ဆက်တိုက် push ပေးသည်။ AI response streaming, live feed, client သည် နားထောင်ရုံသာ လိုအပ်သော notification များအတွက် သင့်တော်ပါသည်။

POLLING vs WEBSOCKET vs SSE
---------------------------
POLLING vs WEBSOCKET vs SSE
-------------------------------
POLLING (client repeatedly asks)
  Client -> "anything new?" -> Server
  Client <- "no, nothing yet" <- Server
        ... wait for interval ...
  Client -> "anything new?" -> Server
  Client <- "yes, here it is" <- Server

WEBSOCKET (persistent, two-way)
  Client <==== one open connection ====> Server
  Client  -- message -------------->     Server
  Client  <------------- message --      Server
  (connection stays open until closed)

SSE (one-way stream, server to client)
  Client -- opens a stream --> Server
  Client <-- update 1 --          Server
  Client <-- update 2 --          Server
  (client does not send data back on this channel)

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

team တစ်ခုက feature မတူညီသုံးခု ဆောက်နေပြီး တစ်ခုစီအတွက် real-time approach ရွေးဖို့ လိုအပ်နေတယ်လို့ ယူဆကြည့်ပါ။

ပထမတစ်ခု, တစ်နှစ်ကို အကြိမ်အနည်းငယ်သာ ပေါ်ရမယ့် 'ဗားရှင်းအသစ်ရရှိပါပြီ' banner တစ်ခုအတွက် — မိနစ်အနည်းငယ်တစ်ခါ polling လုပ်တာက လုံလောက်ပါတယ်၊ ဒီလို ရှားပါးတဲ့ကိစ္စအတွက် persistent connection ဆောက်တာက မလိုအပ်တဲ့ complexity ဖြစ်ပါလိမ့်မယ်။

ဒုတိယတစ်ခု, message တွေက ဘက်နှစ်ဖက်စလုံးမှာ ချက်ချင်းလို ခံစားရရမယ့် customer support chat window တစ်ခုအတွက် — ဒါက WebSocket ဒီဇိုင်းလုပ်ထားတဲ့ ရည်ရွယ်ချက်အတိုင်းပါပဲ၊ ဘက်နှစ်ဖက်လုံးက conversation တစ်ခုလုံးအတွက် ဖွင့်ထားတဲ့ connection တစ်ခုတည်းပေါ်က အချိန်မရွေး message ပို့နိုင်ရမှာမို့ပါ။

တတိယတစ်ခု, အဖြေကို token တစ်ခုချင်းစီ ဖန်တီးရင်း stream ပြန်ပို့တဲ့ AI assistant တစ်ခုအတွက် — Server-Sent Events သည် သဘာဝကျစွာ ကိုက်ညီပါတယ်၊ ဘာလို့လဲဆိုတော့ data က server ကနေ client ဆီကို တစ်ဖက်တည်း စီးဆင်းနေပြီး client က အဲဒီ channel ပေါ်က ပြန်ပို့စရာ လုံးဝမလိုအပ်လို့ပါ။

မှားရွေးတာက သေစေတာမျိုးတော့ မဟုတ်ပါဘူး၊ အလဟဿ ဒါမှမဟုတ် ကြမ်းတမ်းသွားမှာသာ ဖြစ်ပါတယ် — ရှားပါးတဲ့ banner အတွက် WebSocket သုံးရင် idle connection တွေက server resource ကို ကုန်စေမှာဖြစ်ပြီး chat window အတွက် polling သုံးရင် real persistent connection နဲ့ယှဉ်ရင် နှေးကွေး၊ စကားများနေသလို ခံစားရမှာပါ။

• ပုံမှန် HTTP request-response ပုံစံသည် browser က မတောင်းဆိုထားသော ပြောင်းလဲမှုများကို သိရှိရမည့် real-time လိုအပ်ချက်များနှင့် မကိုက်ညီပါ။
• polling သည် ရိုးရှင်းသော်လည်း request များကို အလဟဿဖြစ်စေပြီး delay တိုးစေသည်; WebSocket သည် persistent two-way connection ကိုပေးသည်; SSE သည် persistent one-way server-to-client stream ကိုပေးသည်။
• WebSocket သည် HTTP ကို အစားမထိုးပါ — ၎င်းသည် ပုံမှန် HTTP request များနှင့်အတူ ဘေးတွဲအသုံးပြုသော တည်ငြိမ်သော two-way traffic အတွက် tool မတူညီတစ်ခုဖြစ်သည်။

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

function simulateApproaches(newDataEvents, { pollIntervalSeconds, totalDurationSeconds }) {
  // Polling: the client checks on a fixed timer, regardless of whether
  // anything actually changed.
  let pollingRequests = 0;
  for (let t = pollIntervalSeconds; t <= totalDurationSeconds; t += pollIntervalSeconds) {
    pollingRequests++;
  }
  const pollingDelays = newDataEvents.map((eventTime) => {
    const nextPoll = Math.ceil(eventTime / pollIntervalSeconds) * pollIntervalSeconds;
    return nextPoll - eventTime;
  });
  const avg = (arr) => arr.reduce((a, b) => a + b, 0) / arr.length;

  // WebSocket: one persistent connection opened up front; the server
  // pushes each update the instant it happens.
  const webSocket = {
    connectionsOpened: 1,
    delays: newDataEvents.map(() => 0),
  };

  // SSE: also one persistent connection, one-way server-to-client.
  const sse = {
    connectionsOpened: 1,
    delays: newDataEvents.map(() => 0),
  };

  return {
    polling: {
      totalRequests: pollingRequests,
      averageDelaySeconds: Number(avg(pollingDelays).toFixed(2)),
    },
    webSocket: {
      totalConnections: webSocket.connectionsOpened,
      averageDelaySeconds: Number(avg(webSocket.delays).toFixed(2)),
    },
    sse: {
      totalConnections: sse.connectionsOpened,
      averageDelaySeconds: Number(avg(sse.delays).toFixed(2)),
    },
  };
}

// New data actually appears at these moments over a 30-second window.
const newDataEvents = [3, 7, 7.5, 15, 16, 30];

const result = simulateApproaches(newDataEvents, {
  pollIntervalSeconds: 5,
  totalDurationSeconds: 30,
});

console.log(JSON.stringify(result, null, 2));

စက္ကန့် ၃၀ အတွင်း data အသစ် ၃, ၇, ၇.၅, ၁၅, ၁၆, ၃၀ စက္ကန့်တွေမှာ ပေါ်လာပြီး poll interval ၅ စက္ကန့်ဖြစ်တဲ့အခါ — polling က request ၆ ကြိမ်ပြုလုပ်ပြီး ပျမ်းမျှ notice delay ၁.၉၂ စက္ကန့် ရှိပါတယ်; WebSocket နဲ့ SSE တို့ကတော့ persistent connection ၁ ခုစီကိုသာ သုံးပြီး ပျမ်းမျှ delay ၀ စက္ကန့်ဖြစ်ပါတယ်၊ ဘာလို့လဲဆိုတော့ server က update ဖြစ်တဲ့ချက်ချင်း push လုပ်ပေးလို့ပါပဲ။

MDN — WebSockets API — How the Web Works