សាកស្រមៃមើលពេលអ្នកបើក App កុម្ម៉ង់ម្ហូបមួយ ហើយអូសមើលបញ្ជីឈ្មោះហាងបាយ។ ឈ្មោះហាង រូបភាពម្ហូប និងតម្លៃទាំងអស់នោះ មិនមែនផ្ទុកនៅក្នុងទូរស័ព្ទរបស់អ្នកស្រាប់ឡើយ។ អ្វីដែលកើតឡើងគឺ App របស់អ្នកបានផ្ញើសំណួរទៅកាន់ Server រួច Server ក៏ឆ្លើយតបមកវិញនូវបញ្ជីហាងទាំងនោះ ដើម្បីយកមកបង្ហាញលើអេក្រង់។ ពេលអ្នកចុចមើលមុខម្ហូបមួយ App ក៏សួរទៅ Server ម្ដងទៀត។ ពេលអ្នកចុចកុម្ម៉ង់ App ក៏ផ្ញើព័ត៌មាននៃការទិញត្រឡប់ទៅវិញ។ ហើយនៅពេលអ្នកមើលផែនទីឃើញអ្នកដឹកជញ្ជូន (Rider) កំពុងជិះម៉ូតូមកជិតដល់ លើកនេះគឺជា Server វិញម្តង ដែលជាអ្នកប្រាប់មកទូរស័ព្ទរបស់អ្នកជាបន្តបន្ទាប់។

រាល់សកម្មភាពទាំងអស់នេះ សុទ្ធតែដំណើរការតាមរយៈ API (Application Programming Interface)។ ឈ្មោះរបស់វាស្ដាប់ទៅដូចជាបច្ចេកទេសធ្ងន់ធ្ងរបន្តិច ប៉ុន្តែគំនិតស្នូលរបស់វាសាមញ្ញបំផុត៖ API គឺជាសំណុំក្បួនច្បាប់ ឬជាភាសាកំណត់មួយ ដែលអនុញ្ញាតឱ្យកម្មវិធីមួយ អាចជជែក ឬស្នើសុំទិន្នន័យពីកម្មវិធីមួយទៀតបាន។

នៅក្នុងអត្ថបទនេះ យើងនឹងស្វែងយល់ពីទម្រង់ API ធំៗទាំង ៤ ដែលអ្នកនឹងជួបញឹកញាប់បំផុតក្នុងអាជីពជា Developer៖ REST, GraphQL, gRPC, និង WebSocket។ យើងនឹងមើលពីរូបរាងនៃ Request ជាក់ស្ដែង ចំណុចដែលវាធ្វើបានល្អបំផុត និងចំណុចដែលវាបង្កជាផលវិបាក។

ដំបូងបង្អស់ តើ API ដំណើរការយ៉ាងដូចម្ដេច?

ការប្រៀបធៀបដ៏ល្បី និងងាយយល់បំផុតសម្រាប់ API គឺ «ហាងអាហារ»។

ពេលអ្នកទៅញ៉ាំអីនៅហាង អ្នកមិនដែលដើរចូលទៅក្នុងផ្ទះបាយដើម្បីចម្អិនដោយខ្លួនឯងនោះទេ។ អ្វីដែលអ្នកធ្វើ គឺមើលម៉ឺនុយ ហើយប្រាប់អ្នករត់តុពីម្ហូបដែលអ្នកចង់បាន។ អ្នករត់តុក៏យកការកុម្ម៉ង់នោះទៅប្រាប់ចុងភៅក្នុងផ្ទះបាយ ហើយនៅពេលម្ហូបឆ្អិន គាត់ក៏លើកយកមកជូនអ្នកដល់តុ។

បើប្រៀបធៀបក្នុងពិភព Software៖

• រូបអ្នក (ភ្ញៀវ) គឺជា Client៖ អាចជា Browser, Mobile App ឬក៏ Program ផ្សេងទៀត។
• ផ្ទះបាយ គឺជា Server៖ កន្លែងផ្ទុកកូដ ប្រព័ន្ធទិន្នន័យ (Database) និង Business Logic ទាំងអស់។
• អ្នករត់តុ គឺជា API៖ ជាអ្នកនាំសារដែលទទួលការស្នើសុំ និងបញ្ជូនលទ្ធផលឆ្លើយតបទៅវិញទៅមកតាមទម្រង់ដែលបានព្រមព្រៀងគ្នា។

ផ្ទះបាយអាចប្តូរចង្ក្រានថ្មី ប្តូររូបមន្ត ឬប្តូរមេចុងភៅតាមចិត្ត ដោយអ្នកជាភ្ញៀវមិនចាំបាច់ដឹង ឬរងផលប៉ះពាល់អ្វីឡើយ ដរាបណាអ្នករត់តុនៅតែទទួលការកុម្ម៉ង់តាមរបៀបដដែល។ នេះហើយជាមូលហេតុចម្បងដែលគេបង្កើត API ឡើង៖ ដើម្បីឱ្យប្រព័ន្ធពីរអាចធ្វើការជាមួយគ្នាបាន ដោយមិនបាច់ដឹងពីភាពស្មុគស្មាញនៅខាងក្នុងរបស់គ្នាទៅវិញទៅមក។

ទម្រង់ API ទាំង ៤ ខាងក្រោមនេះ សុទ្ធតែកើតឡើងដើម្បីដោះស្រាយបញ្ហាមួយនេះដូចគ្នា។ អ្វីដែលខុសគ្នា គឺ របៀបនៃការសន្ទនា៖ តើនរណាជាអ្នកផ្ដើមនិយាយមុន? ត្រូវធ្វើដំណើរទៅមកប៉ុន្មានជើង? ហើយពាក្យសម្ដីដែលនិយាយតបឆ្លើយគ្នានោះស្ថិតក្នុងទម្រង់បែបណា?

១. REST៖ អាសយដ្ឋានមួយ សម្រាប់ទិន្នន័យនីមួយៗ

REST (Representational State Transfer) ត្រូវបានបង្កើតឡើងដោយលោក Roy Fielding ក្នុងសារណាថ្នាក់បណ្ឌិតរបស់គាត់កាលពីឆ្នាំ ២០០០ ហើយវាក៏ជាអ្វីដែលមនុស្សភាគច្រើននឹកឃើញមុនគេនៅពេលឮពាក្យថា "API"។ ប្រសិនបើអ្នកធ្លាប់សរសេរ fetch() ទៅកាន់ URL ណាមួយ ហើយទទួលបានទិន្នន័យជា JSON ត្រឡប់មកវិញ នោះមានន័យថាអ្នកធ្លាប់ប្រើប្រាស់វាហើយ។

គំនិតស្នូលរបស់ REST គឺ៖ រាល់ទិន្នន័យ ឬរបស់របរនៅក្នុងប្រព័ន្ធរបស់អ្នក ត្រូវតែមាន URL ផ្ទាល់ខ្លួនមួយ ហើយយើងប្រើប្រាស់ HTTP Verbs ធម្មតាៗដើម្បីធ្វើសកម្មភាពលើវា។

របស់របរទាំងនោះត្រូវបានគេហៅថា Resource។ ផលិតផល, គណនីអ្នកប្រើប្រាស់, ការកុម្ម៉ង់, មតិយោបល់៖ នីមួយៗសុទ្ធតែជានាមដែលមានអាសយដ្ឋានច្បាស់លាស់។ រីឯកិរិយាសព្ទ (Verb) គឺជាអ្នកបញ្ជាក់ថាយើងចង់ធ្វើអ្វីជាមួយវា៖

Server នឹងឆ្លើយតបមកវិញនូវ Status Code អមជាមួយទិន្នន័យជា JSON៖

const res = await fetch("https://api.shop.com/products/15");
console.log(res.status); // 200
const product = await res.json();
// { "id": 15, "name": "ម្រេចកំពត", "price": 4.5, "stock": 120, ... }

ហេតុអ្វីបានជាគេនិយមប្រើវាខ្លាំងម្ល៉េះ?

REST ដំណើរការលើ HTTP ផ្ទាល់ ដែលភាសា Programming គ្រប់ប្រភេទ, Browser និង Tool ទាំងឡាយសុទ្ធតែយល់ និងចេះប្រើរួចជាស្រេច។ អ្នកអាចធ្វើតេស្ត Endpoint មួយបានយ៉ាងងាយ គ្រាន់តែចម្លង URL យកទៅបិទភ្ជាប់លើ Address bar នៃ Browser។ លើសពីនេះ ដោយសារតែការផ្ញើ GET ទៅកាន់ URL ដដែល តែងតែផ្តល់លទ្ធផលដូចគ្នា ដូច្នេះ Browser, CDN និង Proxy អាចជួយ Cache ទិន្នន័យនោះទុកបានភ្លាមៗ ដោយយើងមិនបាច់ចំណាយកម្លាំងរៀបចំច្រើនឡើយ។ ការ Cache នេះមានប្រយោជន៍ធំធេងណាស់ ព្រោះ Request ដែលលឿនបំផុត គឺ Request ដែលមិនចាំបាច់រត់ទៅដល់ Server នោះឯង។

ចំណុចដែលចាប់ផ្ដើមជួបការលំបាក

ឧបមាថាអ្នកកំពុងបង្កើតអេក្រង់ Profile មួយ ដែលត្រូវការបង្ហាញឈ្មោះអ្នកប្រើប្រាស់, អត្ថបទដែលគាត់បានផុស, និងខមមិននៅលើអត្ថបទមួយ។ នៅក្នុង REST របស់ទាំងបីនេះគឺជា Resource បីផ្សេងគ្នា ដែលស្ថិតនៅលើ URL បីដាច់ដោយឡែកពីគ្នា៖

បញ្ហាធំពីរនឹងកើតឡើងនៅត្រង់ចំណុចនេះ៖

• Under-fetching៖ ការផ្ញើ Request មួយជើងមិនគ្រប់គ្រាន់ឡើយ នាំឱ្យអ្នកត្រូវផ្ញើរហូតដល់ទៅ ៣ ដង។ បើនៅលើទូរស័ព្ទដែលមានសេវាខ្សោយ រាល់ជើងធ្វើដំណើរទៅមក (Round-trip) នីមួយៗអាចស៊ីពេលបន្ថែមរាប់រយមីលីវិនាទី។
• Over-fetching៖ ការហៅ GET /users/42 នឹងបញ្ជូនទិន្នន័យ User មកទាំងអស់ (ទាំង email, bio, avatar, settings) ខណៈពេលដែលអេក្រង់នោះត្រូវការតែឈ្មោះមួយមុខគត់។

អ្នកអាចដោះស្រាយបញ្ហាទាំងនេះបាន ដោយបង្កើត Endpoint ពិសេសមួយដាច់ដោយឡែក ដូចជា /profile-screen/42 ជាដើម។ ប៉ុន្តែរាល់ពេលដែល Designer បង្កើតអេក្រង់ថ្មីមួយ អ្នកត្រូវបង្កើត Endpoint ថ្មីមួយទៀត ហើយយូរៗទៅ API របស់អ្នកនឹងប្រែក្លាយទៅជាគំនរ Endpoint ពិសេសៗដែលពិបាកគ្រប់គ្រងជាទីបំផុត។

គួរជ្រើសរើស REST នៅពេល៖ អ្នកកំពុងបង្កើត Public API សម្រាប់ឱ្យអ្នកដទៃប្រើ, កម្មវិធីប្រភេទ CRUD ទូទៅ, ឬតាមពិតទៅគឺគម្រោងស្ទើរតែទាំងអស់។ វាជាជម្រើសដំបូងដ៏រឹងមាំ (Default choice)។ ចូរចាប់ផ្ដើមជាមួយ REST សិន លុះត្រាតែអ្នកជួបបញ្ហាជាក់លាក់ណាមួយ ដែលទាមទារឱ្យប្រើបច្ចេកវិទ្យា ៣ ផ្សេងទៀត។

២. GraphQL៖ ចង់បានទម្រង់បែបណា សុំបែបហ្នឹង

ក្រុមការងារ Facebook បានបង្កើត GraphQL ឡើងក្នុងឆ្នាំ ២០១២ គឺដើម្បីដោះស្រាយបញ្ហា Under-fetching និង Over-fetching ខាងលើនេះផ្ទាល់តែម្ដង។ កាលនោះ Mobile App របស់ Facebook ត្រូវការទាញទិន្នន័យពីកន្លែងជាច្រើនសម្រាប់រៀបចំអេក្រង់មួយៗ ហើយបើប្រើ REST វានឹងបង្កើតឱ្យមាន Round-trip ច្រើនពេក ឬផ្ទុកទិន្នន័យលើសច្រើនពេក។ ក្រោយមក ពួកគេក៏បានបើកវាជា Open-source នៅឆ្នាំ ២០១៥។

គំនិតស្នូលរបស់ GraphQL គឺ៖ មាន Endpoint តែមួយគត់ ហើយ Client ជាអ្នករៀបរាប់ច្បាស់ៗថាតើខ្លួនចង់បានទិន្នន័យអ្វីខ្លះ។

ជំនួសឱ្យការចាំ URL ច្រើន អ្នកគ្រាន់តែសរសេរ Query មួយ ដែលមានទម្រង់ស្រដៀងគ្នាបេះបិទទៅនឹងទិន្នន័យដែលអ្នកចង់បានមកវិញ៖

query {
  user(id: 42) {
    name
    posts {
      title
    }
  }
}

ហើយលទ្ធផលដែលឆ្លើយតបមកវិញ ក៏មានទម្រង់ដូចគ្នាទៅនឹងសំណួរដែលអ្នកបានសួរដែរ៖

{
  "data": {
    "user": {
      "name": "ដារ៉ា",
      "posts": [{ "title": "សួស្ដី" }, { "title": "ស្វែងយល់ពី APIs" }]
    }
  }
}

ធ្វើដំណើរតែមួយជើង គ្មានទិន្នន័យសល់លើសសូម្បីតែមួយតួអក្សរ។ ចុះបើនៅលើអេក្រង់មួយទៀតត្រូវការរូប Avatar បន្ថែម? ងាយណាស់ គ្រាន់តែបន្ថែមពាក្យ avatar ទៅក្នុង Query របស់អេក្រង់នោះទៅជាការស្រេច ដោយខាង Server មិនបាច់កែប្រែកូដអ្វីទាំងអស់។

នៅពីក្រោយខ្នង GraphQL នៅតែដំណើរការលើ HTTP ដដែល។ គ្រប់ Query ទាំងអស់ គឺជាការផ្ញើ POST ទៅកាន់ URL តែមួយគត់៖

const res = await fetch("https://api.example.com/graphql", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    query: `{ user(id: 42) { name posts { title } } }`,
  }),
});
const { data, errors } = await res.json();

ខាង Server នឹងកំណត់នូវ Schema មួយ ដែលបញ្ជាក់ពីប្រភេទ Type នៃទិន្នន័យទាំងអស់ដែលអាចសុំបាន។ Schema នេះដើរតួជាឯកសារជំនួយ (Documentation) ស្រាប់ ហើយ Tool ផ្សេងៗអាចយកវាទៅប្រើសម្រាប់ធ្វើ Autocomplete និងជួយចាប់កំហុសអក្ខរាវិរុទ្ធ (Typos) មុនពេលអ្នកដំណើរការកូដទៀតផង។

តម្លៃដែលអ្នកត្រូវបង់

• ការធ្វើ Cache កាន់តែស្មុគស្មាញ៖ ដោយសារតែគ្រប់ Request សុទ្ធតែជា POST ទៅកាន់ URL ដដែល នោះសមត្ថភាព Cache ស្រាប់របស់ HTTP ដូចនៅលើ REST មិនអាចយកមកប្រើបានទៀតទេ។ អ្នកត្រូវពឹងផ្អែកលើ Client Library ដូចជា Apollo ឬ Relay ដែល Cache តាមរយៈ Object ID ជំនួសឱ្យ URL។
• Server ត្រូវទទួលបន្ទុកធ្ងន់៖ Client អាចសរសេរ Query ដែលមានលក្ខណៈ Nest ចូលគ្នាយ៉ាងជ្រៅ (users → posts → comments → authors → posts...) ដែលអាចធ្វើឱ្យ Database របស់អ្នកគាំងបានយ៉ាងងាយ។ ដូច្នេះ Server របស់ GraphQL ពិតប្រាកដ តម្រូវឱ្យមានការកំណត់កម្រិតជម្រៅ (Depth limits), ការកំណត់ថ្លៃចំណាយនៃ Query (Cost limits) និងការប្រើប្រាស់ Batching ដើម្បីដោះស្រាយបញ្ហា "N+1 Query"។
• ទម្រង់ Error ប្លែកពីគេ៖ ការឆ្លើយតបរបស់ GraphQL ភាគច្រើនតែងតែចេញ 200 OK ទោះបីជាមានបញ្ហាក៏ដោយ ដោយវាភ្ជាប់មកជាមួយនូវ Array errors នៅខាងក្នុង ដូច្នេះអ្នកមិនអាចពឹងផ្អែកតែលើ HTTP Status Code ដូចមុនបានឡើយ។

គួរជ្រើសរើស GraphQL នៅពេល៖ អ្នកមានអេក្រង់ច្រើន ឬមាន Client ច្រើនប្រភេទ (Web, iOS, Android) ដែល Client នីមួយៗត្រូវការទិន្នន័យខុសៗគ្នាចេញពីប្រភពរួមតែមួយ ហើយបញ្ហា Round-trips និង Over-fetching របស់ REST ចាប់ផ្ដើមធ្វើឱ្យប៉ះពាល់ដល់ល្បឿន និងបទពិសោធអ្នកប្រើប្រាស់ពិតប្រាកដ។

៣. gRPC៖ ខ្សែតភ្ជាប់លឿន និងច្បាស់លាស់រវាង Internal Services

REST និង GraphQL ភាគច្រើនផ្តោតលើការទាក់ទងគ្នារវាង Client (ដូចជា Browser ឬទូរស័ព្ទ) ជាមួយ Server។ ប៉ុន្តែនៅក្នុងប្រព័ន្ធរបស់ក្រុមហ៊ុនធំៗ ការហៅ API ភាគច្រើនមិនដែលប៉ះពាល់ជាមួយ Browser ឡើយ។ សេវាកម្ម Order ត្រូវហៅទៅសេវាកម្ម Payment, សេវាកម្ម Payment ហៅទៅសេវាកម្ម Fraud, ហើយសេវាកម្ម Fraud ហៅទៅសេវាកម្ម User ជាដើម។ ការហៅឆ្លើយឆ្លងគ្នាបែបនេះកើតឡើងរាប់ពាន់ដងក្នុងមួយវិនាទី។

ដើម្បីដោះស្រាយចរាចរណ៍ទិន្នន័យដ៏ច្រើនបែបនេះ ក្រុមហ៊ុន Google បានបង្កើត gRPC ឡើង (កែច្នៃចេញពីប្រព័ន្ធខាងក្នុងរបស់ខ្លួនឈ្មោះ Stubby) ហើយបានដាក់ឱ្យប្រើជាសាធារណៈនៅឆ្នាំ ២០១៥។ វាធ្វើឱ្យការហៅទៅកាន់សេវាកម្មផ្សេង មានអារម្មណ៍ដូចជាការហៅ Function ធម្មតាមួយនៅក្នុងកូដផ្ទាល់ខ្លួនរបស់អ្នកអ៊ីចឹង។

វាចាប់ផ្ដើមឡើងដោយ កិច្ចសន្យា (Contract file) មួយ ដែលសរសេរឡើងដោយប្រើ Protocol Buffers (.proto)៖

syntax = "proto3";

service Payment {
  rpc Charge (ChargeRequest) returns (ChargeReply);
}

message ChargeRequest {
  int64 amount = 1;     // គិតជារៀល
  string currency = 2;
}

message ChargeReply {
  bool ok = 1;
  string receipt_id = 2;
}

ក្រុមការងារទាំងសងខាង អាចយក File តែមួយនេះ ទៅ Generate ចេញជាកូដទៅតាមភាសា Programming ដែលពួកគេប្រើរៀងៗខ្លួន មិនថាជា Go, Java, Python ឬ Node ឡើយ។ ខាងសេវាកម្មដែលចង់ហៅ គ្រាន់តែហៅវាបែបនេះ៖

const reply = await payment.charge({ amount: 15000, currency: "KHR" });
console.log(reply.receiptId);

គ្មាន URL, មិនបាច់ចំណាយពេល Parse JSON, ហើយក៏មិនបាច់អង្គុយទាយឈ្មោះ Field ដែរ។ ប្រសិនបើនៅក្នុងកិច្ចសន្យាកំណត់ថា amount គឺជាលេខ (Number) តែអ្នកបែរជាបញ្ជូនអក្សរ (String) ទៅវិញ កម្មវិធីនឹងចាប់កំហុសបានតាំងពីវគ្គ Compile Time (ឬពេលសរសេរភ្លាមៗ) មិនមែនចាំទាល់តែធ្លាយ Bug នៅម៉ោង ២ យប់លើប្រព័ន្ធ Production ទើបដឹងនោះឡើយ។

កត្តាសំខាន់ពីរដែលធ្វើឱ្យ gRPC មានល្បឿនលឿនអស្ចារ្យ៖

• ទិន្នន័យជាទម្រង់ Binary៖ Protobuf មិនបញ្ជូនឈ្មោះ Field ឬសញ្ញាសម្រង់ "" ឡើយ។ វាបញ្ជូនតែលេខសម្គាល់ Field និងទិន្នន័យដែលត្រូវបានបង្រួមយ៉ាងណែនប៉ុណ្ណោះ។ ទិន្នន័យគំរូខាងលើ ប្រសិនបើសរសេរជា JSON ត្រូវចំណាយទំហំរហូតដល់ 33 bytes ប៉ុន្តែពេលបម្លែងជា Protobuf វាថយមកសល់ត្រឹមតែ 8 bytes។ កញ្ចប់ទិន្នន័យកាន់តែតូច មានន័យថាចំណាយ Bandwidth កាន់តែតិច ហើយ CPU ក៏មិនបាច់ខាតកម្លាំង Parse អក្សរដែរ។
• HTTP/2៖ ការហៅ API ច្រើនក្នុងពេលតែមួយ អាចរត់លើ Connection តែមួយបាន (Multiplexing) ហើយ gRPC គាំទ្រការធ្វើ Streaming ទាំងសងខាងក្នុងពេលដំណាលគ្នា (Bidirectional streaming)។ សេវាកម្មមួយអាចបាញ់ទិន្នន័យបន្តបន្ទាប់គ្នាជាខ្សែទឹក ដោយមិនបាច់បើក Connection ថ្មីរាល់ពេលនោះឡើយ។

ឧបសគ្គ និងចំណុចគួរយល់ដឹង

• Browser មិនអាចហៅវាដោយផ្ទាល់បានទេ៖ កម្មវិធី Browser មិនអនុញ្ញាតឱ្យ JavaScript គ្រប់គ្រងកម្រិតទាបនៃ HTTP/2 តាមតម្រូវការរបស់ gRPC ឡើយ។ អ្នកត្រូវប្រើ gRPC-Web រួមជាមួយ Proxy បន្ថែម ហេតុនេះហើយបានជាគេនិយមប្រើ gRPC នៅពីក្រោយខ្នង (Backend-to-Backend) ច្រើនជាងគេ។
• មនុស្សមិនអាចអានផ្ទាល់បានទេ៖ ដោយសារទិន្នន័យរត់លើខ្សែបណ្ដាញជា Binary ដូច្នេះអ្នកមិនអាចប្រើ curl ធម្មតាដើម្បីអានលទ្ធផលបានឡើយ។ អ្នកត្រូវប្រើប្រាស់ Tool ជំនួយដូចជា grpcurl ឬមុខងារ gRPC នៅក្នុង Postman។
• ការរៀបចំដំបូងមានច្រើនដំណាក់កាល៖ ការបង្កើត File .proto, ការ Setup កូដសម្រាប់ Generate និងការរក្សាទុកកូដដែលទើបបង្កើតឱ្យត្រូវគ្នា សុទ្ធសឹងតែជាការងារបន្ថែម បើធៀបនឹងការត្រឡប់ទិន្នន័យជា JSON ធម្មតា។

គួរជ្រើសរើស gRPC នៅពេល៖ សេវាកម្មខាងក្នុង (Internal Services ឬ Microservices) របស់អ្នកត្រូវជជែកគ្នាញឹកញាប់ ល្បឿន និងភាពត្រឹមត្រូវនៃ Type ជាអាទិភាពចម្បង ហើយអ្នកគឺជាអ្នកគ្រប់គ្រងប្រព័ន្ធទាំងសងខាងនៃខ្សែតភ្ជាប់នោះ។

៤. WebSocket៖ ខ្សែទាក់ទងដែលបើកចំហរហូត

ទម្រង់ API ទាំង ៣ ខាងលើ មានគោលការណ៍រួមមួយដូចគ្នាគឺ៖ Client ជាអ្នកសួរ Server ទើបឆ្លើយ (Request-Response)។ Server មិនអាចផ្តួចផ្តើមនិយាយមុនបានជាដាច់ខាត។

លក្ខខណ្ឌនេះនឹងក្លាយជាបញ្ហាធំសម្រាប់មុខងារដូចជា ប្រព័ន្ធឆាត (Chat), លទ្ធផលបាល់ទាត់ផ្ទាល់, ហ្គេមលេងច្រើននាក់ (Multiplayer games), តម្លៃភាគហ៊ុន ឬរូបភាពអ្នកដឹកជញ្ជូនដែលកំពុងរំកិលខ្លួនលើផែនទី។ Server ដឹងថាមានរឿងថ្មីកើតឡើង ប៉ុន្តែគ្មានមធ្យោបាយណាអាចប្រាប់មកអ្នកបានឡើយ ដរាបណាអ្នកមិនទាន់បានចុចសួរវា។

ដំណោះស្រាយចាស់កាលពីមុន គឺការធ្វើ Polling៖ ឱ្យទូរស័ព្ទសួរទៅ Server រៀងរាល់ ២ ឬ ៣ វិនាទីម្តងថា «តើមានអីថ្មីអត់?»។ ចម្លើយភាគច្រើនគឺ «គ្មានទេ» ដែលនេះធ្វើឱ្យខាតបង់ Request ដោយឥតប្រយោជន៍ ហើយសារមួយចំនួននៅតែត្រូវរង់ចាំប៉ុន្មានវិនាទីដែរ ទម្រាំតែបង្ហាញលើអេក្រង់។

WebSocket (ដែលបានក្លាយជាស្តង់ដារផ្លូវការ RFC 6455 ក្នុងឆ្នាំ ២០១១) បានមកកែប្រែបញ្ហានេះទាំងស្រុង។ Client ចាប់ផ្ដើមដោយការផ្ញើ HTTP Request ធម្មតាមួយទៅ Server ដើម្បីសុំ Upgrade។ Server ឆ្លើយតបមកវិញនូវលេខកូដ 101 Switching Protocols ហើយចាប់ពីវិនាទីនោះតទៅ ខ្សែតភ្ជាប់រវាងគ្នានឹងបើកចំហរហូត (Persistent Connection) ដែលភាគីទាំងសងខាងអាចផ្ញើសារទៅមករកគ្នាបានគ្រប់ពេលវេលាតាមចិត្តចង់ (Full-Duplex)។

នៅលើ Browser ការសរសេរកូដប្រើប្រាស់វាមានភាពសាមញ្ញបំផុត៖

const socket = new WebSocket("wss://chat.example.com/room/7");

socket.addEventListener("open", () => {
  socket.send(JSON.stringify({ type: "join", name: "Panha" }));
});

socket.addEventListener("message", (event) => {
  const msg = JSON.parse(event.data);
  console.log(`${msg.from}: ${msg.text}`); // បង្ហាញភ្លាមៗដោយមិនបាច់រង់ចាំ
});

ហើយនេះជាកូដ Node.js Server តូចមួយដោយប្រើកញ្ចប់បណ្ណាល័យ ws ដែលបញ្ជូនរាល់សារដែលទទួលបាន ទៅកាន់មនុស្សគ្រប់គ្នានៅក្នុងបន្ទប់ឆាត៖

import { WebSocketServer } from "ws";

const wss = new WebSocketServer({ port: 8080 });

wss.on("connection", (socket) => {
  socket.on("message", (data) => {
    for (const client of wss.clients) client.send(data.toString());
  });
});

ចំណុចលំបាក និងការប្រឈម

• Connection បើកចំហរហូត ធ្វើឱ្យការ Scale មានការប្រែប្រួល៖ សម្រាប់ REST ម៉ាស៊ីន Server ណាក៏អាចឆ្លើយតបសំណើបានដែរ។ ប៉ុន្តែសម្រាប់ WebSocket ម៉ាស៊ីន Server នីមួយៗត្រូវកាន់កាប់ Connection រាប់ពាន់ដែលកំពុងបើកចំហ។ ប្រសិនបើអ្នកប្រើឈ្មោះដារ៉ាភ្ជាប់ទៅ Server A ហើយសុខាភ្ជាប់ទៅ Server B នោះ Server A និង Server B ត្រូវតែមានមធ្យោបាយបញ្ជូនសារឆ្លងកាត់គ្នា ដែលជាទូទៅគេច្រើនប្រើប្រាស់ប្រព័ន្ធដូចជា Redis Pub/Sub។
• អ្នកត្រូវរៀបចំទម្រង់សារដោយខ្លួនឯង៖ WebSocket បញ្ជូនត្រឹមតែកញ្ចប់សារឆៅៗ (Raw messages) ប៉ុណ្ណោះ។ ការកំណត់ប្រភេទសារ, ការឆ្លើយតប, ឬអត្ថន័យនៃពាក្យ "join" សុទ្ធតែអាស្រ័យលើអ្នកជាអ្នកចាត់ចែង (ឬត្រូវប្រើ Library ជំនួយដូចជា Socket.IO)។
• បញ្ហាដាច់ Connection៖ ទូរស័ព្ទប្តូរពី Wi-Fi ទៅប្រើសេវាទូរស័ព្ទ, កុំព្យូទ័រ Sleep ពេលបិទគម្រប។ កូដ Client របស់អ្នកត្រូវតែមាន Logic សម្រាប់ Reconnect ឡើងវិញដោយស្វ័យប្រវត្តិ និងត្រូវទាញយកសារចាស់ៗដែលខកខានអំឡុងពេលដាច់នោះមកវិញ។

ប្រសិនបើប្រព័ន្ធរបស់អ្នកត្រូវការត្រឹមតែ Server រុញទិន្នន័យមក Client តែម្ខាងប៉ុណ្ណោះ (ដូចជាការបង្ហាញពិន្ទុបាល់ទាត់ ឬការផ្ញើ Notification) ដោយ Client មិនចាំបាច់ឆ្លើយតបទៅវិញទេ អ្នកក៏អាចពិចារណាប្រើ Server-Sent Events (SSE) ផងដែរ។ វាមានភាពសាមញ្ញជាង បញ្ជូនទិន្នន័យតែមួយទិសដៅ ហើយដំណើរការលើ HTTP ធម្មតា។

គួរជ្រើសរើស WebSocket នៅពេល៖ Server ត្រូវការរុញទិន្នន័យមកភ្លាមៗពេលមានបច្ចុប្បន្នភាពថ្មី ឬភាគីទាំងសងខាងត្រូវជជែកឆ្លើយឆ្លងគ្នាជាប្រចាំ៖ កម្មវិធីឆាត, ឧបករណ៍ធ្វើការរួមគ្នា (Collaboration tools), ហ្គេម, ឬ Dashboard ដែលបង្ហាញទិន្នន័យ Real-time។

ប្រៀបធៀបគ្នាក្បែរគ្នា

ចុះតើខ្ញុំគួរជ្រើសរើសមួយណា?

ប្រសិនបើអ្នកនៅមិនទាន់ប្រាកដចិត្តទេ សូមសាកល្បងដើរតាមលំដាប់លំដោយនេះ ហើយឈប់ត្រង់ចំណុចណាដែលត្រូវនឹងពាក្យថា «ត្រូវហើយ» ជាលើកដំបូង៖

នៅក្នុងប្រព័ន្ធជាក់ស្ដែង គេកម្រជ្រើសរើសប្រើតែមួយមុខណាស់។ កម្មវិធីកុម្ម៉ង់ម្ហូបដែលយើងបានលើកឡើងនៅដើមអត្ថបទ អាចនឹងប្រើប្រាស់បច្ចេកវិទ្យាទាំងអស់នេះរួមគ្នា៖

• REST សម្រាប់ទាញយកបញ្ជីហាង, ម៉ឺនុយម្ហូប និងការចុចកុម្ម៉ង់។
• GraphQL សម្រាប់អេក្រង់ដើម (Home screen) ដែលត្រូវការទាញយកប្រូម៉ូសិន, ការកុម្ម៉ង់ចុងក្រោយ និងហាងដែលចូលចិត្ត ក្នុង Query តែមួយជើង។
• gRPC សម្រាប់បម្រើការទំនាក់ទំនងរវាងសេវាកម្មខាងក្នុង ដូចជា Order Service, Payment Service និង Rider Matching Service។
• WebSocket សម្រាប់បញ្ជូនទីតាំងបច្ចុប្បន្នរបស់អ្នកដឹកជញ្ជូនរត់លើផែនទីក្នុងទូរស័ព្ទរបស់អ្នក។

ពួកវាអាចដំណើរការទន្ទឹមគ្នាបានយ៉ាងរលូន ព្រោះបច្ចេកវិទ្យានីមួយៗគ្រាន់តែជាទម្រង់នៃការសន្ទនាខុសៗគ្នាតែប៉ុណ្ណោះ។

ចុះទម្រង់ SOAP បាត់ទៅណាហើយ? អ្នកប្រហែលជាអាចនឹងឃើញ SOAP នៅក្នុងប្រព័ន្ធចាស់ៗរបស់ធនាគារ ឬប្រព័ន្ធរដ្ឋាភិបាលមួយចំនួន។ វាជាទម្រង់ដែលផ្អែកលើ XML តាំងពីចុងទសវត្សរ៍ឆ្នាំ ១៩៩០ ដែលមានកិច្ចសន្យាតឹងរ៉ឹង ស្រដៀងទៅនឹងដូនតារបស់ gRPC អ៊ីចឹង។ វាជារឿងល្អដែលយើងស្គាល់វា ប៉ុន្តែសម្រាប់គម្រោងថ្មីៗ អ្នកទំនងជាមិនជ្រើសរើសវាមកប្រើនោះឡើយ។

សាកល្បងដោយខ្លួនឯងមុនពេលបិទផ្ទាំងនេះ

បើក Web App ណាមួយដែលអ្នកប្រើប្រាស់រាល់ថ្ងៃ រួចចុច F12 (ឬ Right-click → Inspect) ហើយចូលទៅកាន់ផ្ទាំង Network។ បន្ទាប់មកចុច Reload ទំព័រនោះឡើងវិញ។

• ចុច Filter យក Fetch/XHR។ អ្វីដែលអ្នកឃើញភាគច្រើន គឺការហៅ REST នេះឯង។ ចុចលើ Request ណាមួយ រួចសង្កេតមើល URL, Method និងទិន្នន័យ JSON ដែលឆ្លើយតបមកវិញ។
• សាកស្វែងរក Request ណាដែលផ្ញើទៅកាន់ /graphql។ ចុចលើវា ហើយអានមើល Query ដែលស្ថិតនៅក្នុង Request Body។
• ប្តូរ Filter ទៅកាន់ WS វិញម្តង។ ប្រសិនបើគេហទំព័រនោះមានប្រព័ន្ធឆាត ឬការ Update ព័ត៌មានផ្ទាល់ អ្នកនឹងឃើញ WebSocket នៅទីនោះ។ ចុចលើវា រួចបើកផ្ទាំង Messages ដើម្បីទស្សនាការសន្ទនាដែលកំពុងកើតឡើងផ្ទាល់ភ្លាមៗ។

អ្នកនឹងមិនឃើញ gRPC នៅទីនោះទេ ហើយឥឡូវនេះអ្នកដឹងពីមូលហេតុច្បាស់ហើយ៖ ព្រោះវាដំណើរការនៅខាងក្នុង Server ផុតពីកែវភ្នែករបស់ Browser។

នៅពេលអ្នកបានឃើញកម្មវិធីពិតប្រាកដជជែកគ្នាដោយផ្ទាល់ភ្នែក ឈ្មោះទាំង ៤ នេះនឹងឈប់គ្រាន់តែជាពាក្យទ្រឹស្តីស្មុគស្មាញទៀតហើយ ប៉ុន្តែវាបានក្លាយជាឧបករណ៍ដ៏មានប្រយោជន៍នៅក្នុងប្រអប់ឧបករណ៍របស់អ្នក ដែលអ្នកអាចជ្រើសរើសយកមកប្រើប្រាស់បានយ៉ាងត្រឹមត្រូវ និងមានទំនុកចិត្ត។