System

ထိထိမိမိ (Realtime Web Development)

မဂၤလာပါခင္ဗ်ာ။

ကြၽန္ေတာ့္နာမည္က သုထက္ထြန္းပါ။ လက္ရွိမွာ Spiceworks Myanmar Company တြင္ Web Developer အျဖစ္လုပ္ကိုင္လ်က္ရွိပါတယ္။ ဒီ Blog ‌ကေနေဝမွ်ေပးခ်င္တဲ့ အေၾကာင္းအရာေလးကေတာ့ ထိထိမိမိ (Realtime Web Development) ဆိုတဲဲ့အေၾကာင္းအရာပဲျဖစ္ပါတယ္။ စာဖတ္သူ ဖတ္လိုက္ရတဲ့အခ်ိန္အတြင္း ဗဟုသုတ တစ္ခုခုကို ထိထိမိမိရဖို႔ အာမခံပါတယ္။ အၾကမ္္းဖ်င္းေျပာမယ္ဆို Chat Application ဘယ္္္္္္္္္္္္္္္္္္္္္္္္္္္္္္္လိုအလုပ္လုပ္မလဲဆိုတာ ေဆြးေႏြးသြားပါမယ္။ အဲ့ေတာ့ ကြၽန္ေတာ္္္က ဒီ Blog ကို web development နဲဲ့ သက္ဆိုင္တဲ့လူမ်ားအတြက္ေရာ၊ မသက္ဆိုင္တဲဲ့လူေတြအတြက္ပါ ထည့္သြင္းေဆြးေႏြးသြားမွာ ျဖစ္ပါတယ္။

အိုေက ဒါဆိုရင္ စလိုက္ရေအာင္။

 ဒါကေတာ့ ပထမဦးဆုံးသိထားရမယ့္အခ်က္ပါ။ ကြၽန္ေတာ္္္္္္္္္တို႔ရဲ႕ web ကြန္ရက္က ဘယ္လိုအလုပ္လုပ္တာလဲ? ပုံအရ Client ဆိုတာက Web Server တစ္ခုနဲ႔ခ်ိတ္ဆက္ႏိုင္တဲ့ software ေတြကို ရည္ၫႊန္းပါတယ္။ ဥပမာအားျဖင့္ web browser (Google Chrome, Firefox etc ) သည္ web client လို့ဆိုႏိုင္ပါတယ္။ Client က ဘာလုပ္လဲဆိုေတာ့ Server နဲ႔အေပးအယူလုပ္ေလ့ရွိပါတယ္။ အဲ့တာကို HTTP (HyperText Transfer Protocol) လို႔ေခၚ ပါတယ္။ ပုံပါအတိုင္းဆို Client သည္ Server ကအခ်က္အလက္ေတြကို ေတာင္းဆိုတယ္။ Server က ေတာင္းဆိုလာတဲ့အခ်က္အလက္ေတြကို စီစစ္ၿပီး ျပန္ပို႔ေပးတယ္။ ဒါက ႐ိုးရွင္းပါတယ္။ အဲ့လိုနည္းနဲ႔ ကြၽန္ေတာ္္္္္္္္္တို႔သည္ Browser ကိုဖြင့္ .. မိမိရွာလိုတဲ့ အေၾကာင္းအရာ ( website address ) ကို႐ိုက္ထည့္ .. အဲ့အခ်ိန္ျဖစ္ပ်က္သြားတာက အဲ့႐ိုက္ထည့္လိုက္တဲ့အေၾကာင္းအရာကို server ကသြားရွာေပးတယ္။ ၿပီးမွ ကြၽန္ေတာ္္္္္္တို႔ browser ကို ျပန္ပို႔ေပးတယ္။ အဲ့က်မွ ကြၽန္ေတာ္္္္္္္္္တို႔ရဲ႕ browser မွာ website page ကို ေတြ႕ရတာျဖစ္တယ္။ ဒီမွာတစ္ခုရွိတာက Pull Technology ျဖစ္တာေၾကာင့္ Client ကပဲ စတင္ဆက္သြယ္လို႔ရပါတယ္။ ေျပာခ်င္တာက ကြၽန္ေတာ္္္္္္္္္္္တို႔ကအရင္ ေတာင္းဆိုမွ server အလုပ္လုပ္ၿပီးျပန္ပို႔တာျဖစ္ပါတယ္။ အိုေက.. ဒီအပိုင္းကေတာ့ ရွင္းလင္းပီလို႔ယူဆပါတယ္။ ဆက္သြားလိုက္ရေအာင္..

အေပၚက ကြၽန္ေတာ္္္္္္တို႔ ေဆြးေႏြးခဲ့တာမွာ သတိထားမိတာရွိလားမသိဘူး ..? Pull Technology သည္ Client Request မလုပ္ရင္ Server Respond မရွိႏိုင္ပါဘူး။ အဲ့တာဆို (ဥပမာ) Facebook Messenger တို႔လို Chat Application ဆို ဘယ္လိုလုပ္မွာလဲ။ စဥ္္းစားၾကည့္ရေအာင္..

(ဥပမာ) ကြၽန္ေတာ္္္က သူငယ္ခ်င္း-၁ ကို Hello လို႔ message ပို႔မယ္။ အဲ့တာဆို ဒီလိုျမင္ၾကည့္ရေအာင္.. ကြၽန္ေတာ္္္ပို႔လိုက္တဲ့ data သည္ Server ကို အရင္‌ေရာက္မယ္။ ပို႔တဲ့သူက ကြၽန္ေတာ္္၊ ပို႔ရမယ့္သူက သူငယ္ခ်င္း-၁၊ ပို႔ရမယ့္ message က Hello ဆိုၿပီး server က လက္ခံမယ္။ အဲ့မွာ server က သူငယ္ခ်င္း-၁ ဆိုတဲ့လူကိုရွာၿပီးပို႔ရေတာ့မယ္။ Server ဘက္က Client ဆီကို ဆက္သြယ္ရေတာ့မယ္။ ပုံမွန္ request-respond model မွာ Server ကအရင္ connect မလုပ္ႏိုင္ဘူးဆိုေတာ့ သူငယ္ခ်င္း-၁ ဆီ message ေရာက္ေအာင္ဘယ္လိုပို႔ေပးမလဲ? ဘယ္လို Tech မ်ိဳးသုံံးမွာလဲ? Real Time ျဖစ္ေအာင္ဘယ္လိုလုပ္မွာလဲ?

HTTP Short Polling
သူကေတာ့ realtime technique တစ္မ်ိဳးေပါ့။ Short Polling သည္ အခ်ိန္တစ္ခုအတြင္း အၿမဲ Client-Server Connection ကိုလုပ္ေဆာင္ေနတဲ့ Tech ပါ။ နဂို Pull Technology ကို ျပန္ဆန္းသစ္ထားတာလို႔ေျပာႏိုင္တယ္။ ဘာလို႔လဲဆိုေတာ့ Short Polling မွာလဲ Client ကစၿပီး request လုပ္ရပါတယ္။ ၿပီးမွ Server က respond ေပးတာပါ။ ကြာျခားသြားတာက Client က request ကို အခ်ိန္အပိုင္းအျခားတစ္ခုအတြင္း အၿမဲပို႔ေနတာေပါ့။ အခ်ိန္အပိုင္းအျခားသည္ ငါးမိနစ္လဲျဖစ္ႏိုင္သလို စကၠန႔္ပိုင္းလည္းျဖစ္ႏိုင္တယ္။ ဒါေၾကာင့္ သူက realtime feeling မ်ိဳးကိုေပးႏိုင္တယ္လို႔‌ေျပာလို႔ရပါတယ္။ သူရဲ႕မေကာင္းတဲ့အခ်က္က request ေတြမ်ားတာပါ။ Short Pulling ကို ဥပမာေပးရရင္ ကေလးတစ္ေယာက္က မိခင္ကို မုန႔္ရွိေသးလား? မုန႔္ရွိေသးလား? လို႔ ၁မိနစ္တိုင္းေမးတယ္။ မိခင္က မုန႔္ေရာက္ေနပီဆို ေပးလိုက္တယ္။ ၿပီးတာနဲ႔ ကေလးက ၁မိနစ္တိုင္းျပန္ေမးေနမယ္။ ဒီသေဘာပါပဲဲ..

HTTP Long Polling
သူကလဲ short polling နဲ႔ဆင္တူပါတယ္။ ကြဲသြားတဲ့အခ်က္က သူကရည္းစားေတြမ်ားတယ္။ အဲ ေနာက္တာပါ.. Long Polling သည္လည္း Client က Server ကိို new data ရွိေသးလားဆိုၿပီး request စလုပ္ပါတယ္။ ထူးျခားသြားတာက long polling ရဲ႕ Client request သည္ Server မွာ new data မေရာက္မခ်င္း ဆက္သြယ္္္ထားတာပဲျဖစ္ပါတယ္။ Server က new data ေရာက္လာတဲ့အခါ ေတာင္းဆိုေနတဲ့ Client ဆီကို respond ျပန္ေပးပါတယ္။ ဥပမာေပးရရင္.. ကေလးသည္ မိခင္ကို မုန႔္ရွိလားလို႔ တစ္ခါပဲေမးပါတယ္။ အဲ့တစ္ခါသည္ permanent ျဖစ္ေနတဲ့သေဘာပါ။ မုန႔္ေရာက္တဲ့အခါ မိခင္က ကေလးကိုေပးလိုက္တယ္။ ကေလးက ေနာက္တခါျပန္ေမးထားလိုက္တယ္။ အဲ့တာ looping ျဖစ္ေနတာေပါ့။ ဒါဆိုရင္ HTTP Long Polling အေၾကာင္းရွင္းမယ္ထင္ပါတယ္။

WebSocket
သူကေတာ့ advanced technology လို႔ေျပာလို႔ရမယ္။ WebSocket သည္ Client နဲ႔ Server ၾကားမွာ Two way communication (bi-directional communication) အျဖစ္အလုပ္လုပ္ေပးပါတယ္။ ပုံံံံံံမွန္ request-respond model မ်ိဳးနဲ႔ သူက လုံး၀ကြဲျခားပါတယ္။ WebSocket ကိုယ္တိုင္သည္ Client နဲ႔ Server ၾကားမွာ တည္ၿမဲေနတဲ့အဆက္အသြယ္တစ္ခု (persistent connection) လိုပါဘဲ။ သူသည္ TCP/IP (Transmission Control Protocol/Internet Protocol) ေပၚမွာ run ပါတယ္။ ဒီ Technology ကေတာ့ Real Time Feeling ကိုအျပည့္အဝရေစမွာပါ။ Server မွာတစ္ခုခု အေျပာင္းအလဲျဖစ္တာနဲ႔ အေျပာင္းအလဲသည္ WebSocket မွတစ္ဆင့္ Client ဆီ ခ်က္ခ်င္းေရာက္သြားမွာပါ။ Client ဘက္ကစမွရမယ့္ relation မ်ိဳးမဟုတ္ေတာ့ဘဲ အျပန္အလွန္ ဆက္သြယ္ႏိုင္တဲ့ relationship မ်ိဳးျဖစ္လာမွာပါ။ အဲ့ေတာ့ ကြၽန္ေတာ္္္္္္္္္္္္္္္္္္္္္္တို႔လိုခ်င္ေနတဲ့ real time feeling ကိုရရွိလာပါၿပီ။ အေပၚ က ကြၽန္ေတာ္္္္္္္္္္္္္္္တို႔ေဆြးေႏြးခဲ့တဲ့ Chat Application Example ကို WebSocket သုံံးၿပီး တည္ေဆာက္ၾကည့္ရေအာင္..
ကြၽန္ေတာ္္္က သူငယ္ခ်င္း-၁ ဆီကို Hello လို႔ chat box ကေန message ပို႔မယ္။ အဲ့အခ်ိန္မွာ Server က အၿမဲ listen ေနမယ္။ ကြၽန္ေတာ္္္္္္္္္္္္္္ပို႔လိုက္တဲ့ new data ကိုေတြ႕တာနဲ႔တၿပိဳင္နက္ သူက ေနာက္ Client တစ္ခုျဖစ္တဲ့ သူငယ္ခ်င္း-၁ ဆီကို socket connection မွတစ္ဆင့္ ခ်က္ခ်င္းပို႔ေဆာင္ေပးပါတယ္။ ထို႔အတူပဲဲ သူငယ္ခ်င္း-၁ ကလည္း ကြၽန္ေတာ္္္္္္္ဆီကို message ျပန္ပို႔လို႔ရတယ္။ ဒီလိုနည္းနဲ႔ realtime chatting ျဖစ္သြားတာပါ။

 

Realtime Web Development ( Dev Side )
Pusher
သူကေတာ့ Realtime Framework လို႔အသိမ်ားၾကပါတယ္။ Real Time Application ေတြတည္ေဆာက္ဖို႔ Developer ေတြအတြက္ အလြယ္ကူဆုံးျဖစ္ေအာင္ကူညီေပးႏိုင္ပါတယ္။ Public channel, Private channel ေတြ တည္ေဆာက္ေပးထားတယ္။ Message Storage, Notifications, typing indicators ေတြလဲပါဝင္ပါတယ္။ သူရဲ႕အဓိကအားနည္းခ်က္ကေတာ့ cost ပဲဲဲဲဲဲဲျဖစ္္ပါတယ္။ Free အသုံးျပဳႏိုင္မယ့္ limitation ရွိၿပီး အဲ့တာကိုေက်ာ္္လာရင္ အခေပးရမွာပါ။

Socket.IO
တျခားတဖက္မွာကေတာ့ Socket.IO သည္ Realtime application framework( Node.js Server ) ျဖစ္ပါတယ္။ သူကေတာ့ pusher ထက္လူသုံးမ်ားတာကိုေတြ႕ရပါတယ္။ လက္ရွိ ကြၽန္ေတာ္္္္္္တို႔ Task Management အတြက္အသုံးျပဳေနတဲ့ Trello သည္လည္း Realtime အတြက္ Socket.IO ကိုအသုံးျပဳထားပါတယ္။ Socket.IO သည္ Pusher လို အဆင္သင့္သုံးမဟုတ္ဘဲ Developer ကိုယ္တိုင္ တည္ေဆာက္ရတဲ့အပိုင္းေတြေတာ့ရွိပါတယ္။ ေနာက္ပိုင္း Realtime Development အတြက္ တျခား နည္းပညာေတြျဖစ္တဲ့ PubNub တို႔ Firebase တို႔ကလည္း ေနရာယူလာတာကိုေတြ႕ရပါတယ္။

အခ်ဳပ္အားျဖင့္ ဒီ Blog မွာ ကြၽန္ေတာ္္္္္္္္္္္္္တို႔ေဆြးေႏြးလာတဲ့ Realtime Web Development အေၾကာင္းအရာသည္ စာဖတ္သူအေပၚ္ ဖတ္လိုက္ရတဲ့အခ်ိန္တစ္ခုအတြင္း ထိထိမိမိ အက်ိဳးရွိမယ္ဆို ကြၽန္ေတာ္္ေရးရက်ိဳးနပ္ပါၿပီ။ ကြၽန္ေတာ္္ရဲ႕ တျခား Blog ေတြျဖစ္တဲ့ A Journey Map နဲ႔ A Customer Journey Map တို႔ကိုလည္း ေအာက္ပါ Link မ်ားမွ တဆင့္ ဖတ္ရႈ အားေပးႏိုင္ပါတယ္။

A Customer Journey Map Blog  – https://spiceworksmyanmar.com/blog/a-customer-journey-map/

A Journey Map Blog  – https://spiceworksmyanmar.com/blog/a-journey-map/

အခုလို ဖတ္ရႈေပးတဲ့အတြက္ အမ်ားႀကီး ေက်းဇူးတင္ပါတယ္ခင္ဗ်ာ။

Hello

Leave a Reply

Your email address will not be published. Required fields are marked *