Static Site, Web App និង API

មាតិកា

1. HTTP ដូចគ្នា Server ខុសគ្នា
2. Static Site
3. ទំព័រ Server-Rendered
4. Single-Page App
5. លាយទាំងបីបញ្ចូលគ្នា
6. API៖ HTTP សម្រាប់កម្មវិធី
7. CORS ដោយសង្ខេប
8. Frontend និង Backend
9. សាកល្បងដោយខ្លួនឯង

1. HTTP ដូចគ្នា Server ខុសគ្នា

អ្វីៗទាំងអស់ក្នុងស៊េរីនេះរហូតមកដល់ពេលនេះ គឺពិតសម្រាប់ website គ្រប់ website៖ URL, DNS, connection, request, response, ការ render, cookie, cache។ អ្វីដែលខុសគ្នាពី site មួយទៅ site មួយ គឺអ្វីដែល server ធ្វើ ចន្លោះ ពេលទទួល request និងពេលផ្ញើ response។

មានចម្លើយសំខាន់ៗបី ហើយអ្នកនឹងឮអ្នកអភិវឌ្ឍន៍ជជែកវែកញែកអំពីវាជារៀងរហូត៖

2. Static Site

Static site គឺជា folder មួយនៃ file ដែលបង្កើតរួចជាស្រេច។ នៅពេល request មួយមកដល់ server រក file ដែលត្រូវគ្នា ហើយផ្ញើវាត្រឡប់ទៅវិញ។ ត្រឹមតែប៉ុណ្ណឹង។ គ្មានកូដណាដំណើរការទេ ហើយក៏គ្មានការសួរ database អ្វីដែរ។

 GET /my-site/about.html  ──▶  server reads about.html from disk  ──▶  200 + the file

GitHub Pages site របស់អ្នកគឺជា static site៖ អ្នកបានសរសេរ HTML file ហើយ server របស់ GitHub គ្រាន់តែចែកវាចេញទៅ។

Static site គឺ៖

• លឿន — គ្មានអ្វីត្រូវគណនា ហើយគ្រប់ file អាចត្រូវបាន cache ដោយ CDN។
• ថោក — ជារឿយៗឥតគិតថ្លៃ។ GitHub Pages, Cloudflare Pages និង Netlify host វាដោយមិនគិតថ្លៃ។
• សុវត្ថិភាព — គ្មានកូដ server ឬ database ឲ្យគេវាយប្រហារ។
• សាមញ្ញ — គ្មានអ្វីគាំងនៅម៉ោង 3 យប់។

ដែនកំណត់៖ អ្នកចូលមើលគ្រប់គ្នាឃើញ file ដូចគ្នា។ Static site មិនអាចបង្ហាញ «សួស្តី Dara» ទៅ Dara និង «សួស្តី Sokha» ទៅ Sokha ឬរក្សាទុក comment ដែលអ្នកវាយបានទេ — មិនមែនដោយខ្លួនវាតែម្នាក់ឯងទេ។

Static ក៏មិនមែនមានន័យថាសរសេរដោយដៃដែរ។ Static site ជាច្រើនត្រូវបាន generate ដោយឧបករណ៍មួយ ដែលប្រែ Markdown ឬទិន្នន័យទៅជា HTML file តែម្តង នៅពេល build។ Website នេះគឺជាឧទាហរណ៍មួយ។ គ្រប់ tutorial រួមទាំងជំពូកនេះផងដែរ គឺជា Markdown file ដែល Next.js បានប្រែទៅជា HTML file ធម្មតា នៅពេល site ត្រូវបាន build។ គ្មានកម្មវិធី server ណាដំណើរការសម្រាប់វាទេ ហើយក៏គ្មាន database ដែរ — នោះហើយជាមូលហេតុដែលវាស្ទើរតែមិនចំណាយអ្វីសោះក្នុងការ host។

3. ទំព័រ Server-Rendered

Site ដែល server-rendered ដំណើរការកូដសម្រាប់ គ្រប់ request។ Server អាន request (path, cookie, query) សួរ database នូវអ្វីដែលវាត្រូវការ បង្កើត HTML ពីវា ហើយផ្ញើវាត្រឡប់ទៅវិញ។

 GET /dashboard
 Cookie: session=a8f3…
        │
        ▼
 server code: who is a8f3…?  → Dara
              get Dara's orders from the database
              build the HTML: "Hi Dara! You have 3 orders…"
        │
        ▼
 200 + HTML made just for Dara

នោះជារបៀបដែលអ្នកទទួលបានទំព័រដែល ផ្ទាល់ខ្លួន និង ទាន់សម័យ៖ inbox របស់អ្នក សមតុល្យធនាគាររបស់អ្នក ការកុម្ម៉ង់របស់អ្នក។ Browser នៅតែទទួលបាន HTML ធម្មតា — វាមិនអាចប្រាប់បានផង ថាទំព័រមួយមកពី file ឬត្រូវបានបង្កើតមុននេះមួយ millisecond។

តម្លៃដែលត្រូវបង់គឺ server មួយដែលដំណើរការជានិច្ច database មួយ និងរបស់ច្រើនទៀតដែលអាចខូច — 500 និង 502 ពីជំពូកទី 6។ ឧទាហរណ៍បុរាណគឺ PHP site ដូចជា WordPress និង framework ដូចជា Django, Ruby on Rails និង Laravel។

4. Single-Page App

Single-page app ផ្លាស់ការងារចូលទៅក្នុង browser។ Server ផ្ញើទំព័រ HTML ដែលស្ទើរតែទទេ និង JavaScript file ធំមួយ៖

<body>
  <div id="root"></div>
  <script src="/app.81d0e47f.js"></script>
</body>

បន្ទាប់មក JavaScript បង្កើតទំព័រទាំងមូលដោយខ្លួនឯង នៅក្នុង DOM។ នៅពេលវាត្រូវការទិន្នន័យ វាប្រើ fetch() (ជំពូកទី 7) ដើម្បីសុំវាពី server។ នៅពេលអ្នកចុច link មួយ វាមិន load ទំព័រថ្មីទេ — វាផ្លាស់ប្តូរ DOM ហើយធ្វើបច្ចុប្បន្នភាព address bar ដោយខ្លួនឯង។

នោះគឺជាអ្វីដែលអ្នកបានឃើញក្នុងជំពូកទី 7 នៅពេល view source និង tab Elements មើលទៅខុសគ្នាទាំងស្រុង។

SPA មានអារម្មណ៍រលូន ដូចកម្មវិធីនៅលើទូរស័ព្ទរបស់អ្នក៖ គ្មានពន្លឺសភ្លឹបភ្លែតៗរវាងទំព័រ ហើយឆ្លើយតបភ្លាមៗនឹងការចុច។ Gmail, Facebook និង Trello ដំណើរការតាមរបៀបនេះ។ តម្លៃដែលត្រូវបង់គឺការទាញយក JavaScript ធំមួយ មុនពេលអ្វីៗលេចឡើង និងទំព័រដែល search engine និង link preview ប្រហែលជាពិបាកអាន ព្រោះ HTML ដែលពួកវាទទួលបានគឺទទេ។ React បានល្បីល្បាញដោយសារការបង្កើត SPA។

5. លាយទាំងបីបញ្ចូលគ្នា

តាមការអនុវត្តជាក់ស្តែង framework សម័យថ្មីលាយទាំងបីបញ្ចូលគ្នា — សូម្បីតែមួយទំព័រម្តងក៏បាន។ ជាមួយ Next.js ដែលអ្នកនឹងជួបនៅលើ track Frontend នោះ site មួយអាចមាន៖

• Blog និងទំព័រ landing ដែលជា static បាន build ទុកជាមុន។
• ទំព័រ dashboard ដែលជា server-rendered ដែលត្រូវការទិន្នន័យថ្មីៗ។
• ទំព័រដែល load ជា HTML ជាមុនសិន ហើយបន្ទាប់មកដំណើរការដូច SPA នៅពេល JavaScript ចាប់ផ្តើមគ្រប់គ្រងនៅក្នុង browser។

នោះហើយជាមូលហេតុដែលសំណួរមិនមែនថា «មួយណាល្អបំផុត?» ទេ ប៉ុន្តែគឺ «មួយណាសមនឹង ទំព័រនេះ?»។ Portfolio ដែលផ្លាស់ប្តូរម្តងក្នុងមួយខែគួរតែជា static។ ទំព័រគណនីធនាគារត្រូវតែជា server-rendered ឬ fetch ទិន្នន័យរបស់វា។ អ្នកនឹងចាប់អារម្មណ៍បានតាមរយៈការអនុវត្ត។

6. API៖ HTTP សម្រាប់កម្មវិធី

រហូតមកដល់ពេលនេះ response គឺជា HTML៖ សម្រាប់ឲ្យ browser បង្ហាញដល់មនុស្ស។ ប៉ុន្តែ HTTP អាចដឹកទិន្នន័យប្រភេទណាក៏បាន។ នៅពេល client គឺជា កម្មវិធី — SPA មួយ mobile app មួយ ឬ server មួយទៀត — វាមិនចង់បានទំព័រ web ទេ។ វាចង់បាន ទិន្នន័យ។

API (Application Programming Interface) គឺជា server ដែលឆ្លើយ HTTP request ដោយទិន្នន័យជំនួសឲ្យទំព័រ ជាធម្មតាជា JSON៖

curl https://api.github.com/users/octocat

{
  "login": "octocat",
  "name": "The Octocat",
  "public_repos": 8,
  "followers": 21000,
  "created_at": "2011-01-25T18:44:36Z"
}

Request ដូចគ្នា response ដូចគ្នា status code ដូចគ្នា header ដូចគ្នា — គ្រាន់តែ Content-Type: application/json ជំនួសឲ្យ text/html។ អ្វីៗទាំងអស់ដែលអ្នកបានរៀនក្នុងជំពូកទី 5 និង 6 អនុវត្តបានដោយផ្ទាល់។

API ភាគច្រើនធ្វើតាមរបៀបមួយហៅថា REST ដែលប្រើ URL សម្រាប់ អ្វី និង method សម្រាប់ ត្រូវធ្វើអ្វី៖

នេះពិតជាអ្វីដែលអ្នកសាងសង់នៅក្នុង NestJS Crash Course។ ហើយ tutorial ABA PayWay និង Bakong KHQR គឺនិយាយអំពីការហៅ API របស់អ្នកដទៃ — របស់ធនាគារ — ពី server ផ្ទាល់ខ្លួនរបស់អ្នក។

Mobile app នៅលើទូរស័ព្ទរបស់អ្នក app ធនាគារ app ដឹកជញ្ជូនម្ហូប — នៅពីក្រោម ពួកវាស្ទើរតែទាំងអស់គឺជា client ដែលផ្ញើ HTTP request ទៅ API។ នោះហើយជាមូលហេតុដែលស៊េរីនេះស្ថិតនៅដើមបង្អស់នៃគ្រប់ track នៅលើផែនទីការសិក្សា។

7. CORS ដោយសង្ខេប

មិនយូរមិនឆាប់ អ្នកអភិវឌ្ឍន៍ frontend គ្រប់រូបនឹងជួប error ដូចនេះនៅក្នុង console របស់ browser៖

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:3000' has been blocked by CORS policy

នេះជាអ្វីដែលកំពុងកើតឡើង។ Origin គឺជា scheme + host + port នៃទំព័រមួយ៖ http://localhost:3000 និង https://api.example.com គឺជា origin ខុសគ្នា។ ដើម្បីសុវត្ថិភាព browser មិនអនុញ្ញាតឲ្យ JavaScript នៅលើ origin មួយអាន response ពី origin មួយទៀតទេ — បើមិនដូច្នោះទេ website ណាក៏ដោយដែលអ្នកចូលមើល អាចអាន email របស់អ្នកពី tab មួយទៀតដោយស្ងាត់ៗ ដោយប្រើ cookie របស់អ្នក។

CORS — Cross-Origin Resource Sharing — គឺជារបៀបដែល server និយាយថា «មិនអីទេ ខ្ញុំអនុញ្ញាត origin នោះ» ដោយប្រើ response header មួយ៖

Access-Control-Allow-Origin: http://localhost:3000

សម្រាប់ request ខ្លះ browser ផ្ញើ request OPTIONS (method ពីជំពូកទី 5) ជាមុនសិន — ហៅថា preflight — ដើម្បីសុំការអនុញ្ញាត មុនពេលផ្ញើ request ពិតប្រាកដ។

រឿងពីរដែលត្រូវចងចាំ៖

• CORS ត្រូវបានអនុវត្តដោយ browser មិនមែនដោយ server ទេ។ នោះហើយជាមូលហេតុដែល request ដូចគ្នាដំណើរការល្អឥតខ្ចោះនៅក្នុង curl ប៉ុន្តែបរាជ័យនៅក្នុង browser។
• ការជួសជុលគឺនៅលើ server ដែលជាម្ចាស់ API៖ វាត្រូវតែផ្ញើ header ត្រឹមត្រូវ។ អ្នកមិនអាចជួសជុល CORS error ពី frontend បានទេ។

អ្នកនឹងរៀបចំរឿងនេះដោយខ្លួនឯងនៅលើ track Backend។

8. Frontend និង Backend

ឥឡូវនេះ អ្នកអាចផ្តល់អត្ថន័យច្បាស់លាស់ដល់ពាក្យពីរ ដែលលេចឡើងនៅក្នុងការផ្សាយជ្រើសរើសបុគ្គលិកស្ទើរតែគ្រប់មួយ៖

• Frontend គឺជាអ្វីៗទាំងអស់ដែលកើតឡើង នៅក្នុង browser៖ HTML, CSS និង JavaScript ពីជំពូកទី 7 — layout អន្តរកម្ម ការហៅ API ដោយប្រើ fetch()។
• Backend គឺជាអ្វីៗទាំងអស់ដែលកើតឡើង នៅលើ server៖ ការទទួល request ការពិនិត្យ cookie ឬ token ការនិយាយជាមួយ database និងការផ្ញើ response — ជំពូកទី 5, 6 និង 8 ពីផ្នែកខាង server។

ពួកវាជួបគ្នានៅកន្លែងតែមួយគត់៖ HTTP request និង response។ អ្នកអភិវឌ្ឍន៍ frontend និងអ្នកអភិវឌ្ឍន៍ backend ដែលទាំងពីរយល់ពីស៊េរីនេះ តែងតែអាចរកឃើញថាបញ្ហានៅត្រង់ណា។ បើក Network tab រក request នោះ ហើយសួរ៖ តើ frontend បានផ្ញើរបស់ត្រឹមត្រូវទេ? តើ backend បានផ្ញើចម្លើយត្រឹមត្រូវត្រឡប់មកវិញទេ?

9. សាកល្បងដោយខ្លួនឯង

1. ហៅ API ពិតប្រាកដមួយ។ រត់៖

   curl https://api.github.com/users/<your-username>
   curl -I https://api.github.com/users/<your-username>
   

   Copy

   រកចំនួន public_repos របស់អ្នក។ នៅក្នុង header រក content-type និង header x-ratelimit-remaining។ តើអ្នកគិតថាវារាប់អ្វី? (ចាំ 429 ពីជំពូកទី 6។)

2. ទទួល 404 ពី API មួយ។ សុំ user ដែលមិនមាន ដូចជា curl -i https://api.github.com/users/this-user-does-not-exist-123 (-i បង្ហាញ header និង body)។ API ផ្ញើ error ជា JSON ដែរ។

3. ចាត់ថ្នាក់ site។ សម្រាប់ site បីដែលអ្នកប្រើ បើក view source និង tab Elements ហើយមើល filter Fetch/XHR នៅក្នុង Network tab។ តើនីមួយៗជា static, server-rendered, SPA ឬលាយគ្នា?

4. មើល app មួយប្រើ API របស់វា។ បើក site មួយដែលអ្នកបាន log in (ដូចជា GitHub ឬ YouTube) ដោយបើក filter Fetch/XHR បន្ទាប់មកចុចនេះចុចនោះ។ ចុចលើ request មួយ ហើយមើល tab Response របស់វា។ វាជា JSON — frontend កំពុងនិយាយជាមួយ backend។

5. មើល CORS header។ រត់ curl -I https://api.github.com/users/octocat ហើយរក access-control-allow-origin។ តើតម្លៃរបស់វាមានន័យដូចម្តេច?

នៅក្នុងជំពូកចុងក្រោយ យើងនឹងដាក់អ្វីៗទាំងអស់បញ្ចូលគ្នា ហើយតាមដាន URL មួយ ចាប់ពីពេលអ្នកចុច Enter រហូតដល់ពេលទំព័របង្ហាញនៅលើអេក្រង់របស់អ្នក។