Architecture Decision Record

Active theme: Light

← ឧទាហរណ៍កំណត់ត្រាការសម្រេចចិត្ត

កំណត់ត្រាការសម្រេចចិត្តខាងស្ថាបត្យកម្ម៖ API ប្រើ JSON ប្រៀបធៀប gRPC

ស្ថានភាព

បានទទួលយក

បរិបទ

យើងកំពុងរចនា API សម្រាប់សេវាកម្មថ្មីមួយដែលនឹងត្រូវបានប្រើដោយអតិថិជនច្រើន។ យើងបានពិចារណាជម្រើសពីរសម្រាប់ការអនុវត្ត API៖ ប្រើ JSON តាម HTTP ឬប្រើ gRPC។

JSON តាម HTTP គឺជាវិធីសាស្ត្រដែលប្រើយ៉ាងទូលំទូលាយសម្រាប់កសាង API ហើយត្រូវបានគាំទ្រដោយភាសាសរសេរកម្មវិធី និងក្របខ័ណ្ឌជាច្រើន។ វិធីសាស្ត្រនេះសាមញ្ញ ស្រាល និងងាយយល់ ដែលធ្វើឱ្យវាជាជម្រើសល្អសម្រាប់គម្រោងជាច្រើន។ ទោះយ៉ាងណា វាអាចមានប្រសិទ្ធភាពតិចជាងជម្រើសផ្សេង ជាពិសេសនៅពេលដោះស្រាយទិន្នន័យមានបរិមាណច្រើន។

ម្យ៉ាងវិញទៀត gRPC គឺជាបច្ចេកវិទ្យាថ្មីជាងដែលផ្តល់វិធីកសាង API ដែលមានប្រសិទ្ធភាពជាង។ វាប្រើការបម្លែងទិន្នន័យជាប្រព័ន្ធគោលពីរដើម្បីផ្ទេរទិន្នន័យ ដែលអាចលឿនជាង និងបង្រួមជាងការប្រើ JSON។ gRPC ក៏គាំទ្រការផ្សាយបន្តទ្វេទិស ដែលធ្វើឱ្យវាជាជម្រើសល្អសម្រាប់កម្មវិធីពេលវេលាជាក់ស្តែង។

ការសម្រេចចិត្ត

បន្ទាប់ពីពិចារណាគុណសម្បត្តិ និងគុណវិបត្តិនៃជម្រើសទាំងពីរ យើងបានសម្រេចប្រើ gRPC សម្រាប់ API របស់យើង។ ទោះបី JSON តាម HTTP ជាជម្រើសសាមញ្ញជាងក៏ដោយ យើងជឿថា gRPC នឹងផ្តល់ដំណោះស្រាយដែលមានប្រសិទ្ធភាព និងអាចពង្រីកបានជាងសម្រាប់សេវាកម្មរបស់យើង។ យើងក៏រំពឹងថា API របស់យើងនឹងដោះស្រាយទិន្នន័យបរិមាណច្រើន ហើយការបម្លែងជាប្រព័ន្ធគោលពីររបស់ gRPC នឹងមានប្រសិទ្ធភាពជាងសម្រាប់ករណីប្រើប្រាស់នេះ។

លើសពីនេះ យើងជឿថាការគាំទ្រការផ្សាយបន្តទ្វេទិសរបស់ gRPC នឹងមានប្រយោជន៍សម្រាប់កម្មវិធីពេលវេលាជាក់ស្តែងដែលយើងអាចអភិវឌ្ឍនាពេលអនាគត។

ផលវិបាក

ដោយជ្រើសរើស gRPC យើងនឹងត្រូវប្រើឧបករណ៍ និងបណ្ណាល័យផ្សេងគ្នាដើម្បីកសាង API របស់យើង ធៀបនឹងការប្រើ JSON តាម HTTP។ នេះអាចតម្រូវឱ្យមានពេលវេលា និងការខិតខំបន្ថែមដើម្បីរៀន និងអនុវត្តបច្ចេកវិទ្យាទាំងនេះ។ លើសពីនេះ អតិថិជនដែលចង់ប្រើ API របស់យើងនឹងត្រូវប្រើបណ្ណាល័យដែលត្រូវគ្នានឹង gRPC ដែលប្រហែលជាមិនត្រូវបានគាំទ្រយ៉ាងទូលំទូលាយដូចបណ្ណាល័យ JSON តាម HTTP ទេ។

ទោះយ៉ាងណា យើងជឿថាអត្ថប្រយោជន៍នៃការប្រើ gRPC លើសពីគុណវិបត្តិដែលអាចកើតមានទាំងនេះ ហើយយើងមានទំនុកចិត្តថាការសម្រេចចិត្តនេះនឹងនាំឱ្យមាន API ដែលមានប្រសិទ្ធភាព និងអាចពង្រីកបានជាងមុន។