Full-Stack Tiered Architecture & HTTP Lifecycle

ข้อสอบเน้น flow ทั้งระบบ ไม่ใช่ syntax เดี่ยว ๆ — ต้องตอบได้ว่าเมื่อผู้ใช้กดปุ่มหนึ่งครั้ง ข้อมูลวิ่งผ่านชั้นไหนบ้าง แต่ละชั้นทำอะไร และตอบกลับด้วย status อะไร

4 ส่วนของระบบ e-commerce

ส่วนเปรียบเทียบทำหน้าที่เทคโนโลยี
User Interface (Frontend)หน้าร้านให้ลูกค้าโต้ตอบกับสินค้าHTML, CSS, JavaScript
Backendสมอง / ผู้จัดการจัดการ logic ความปลอดภัย และการสื่อสารNode.js, Express
Databaseความจำ / คลังสินค้าเก็บข้อมูลถาวร เช่น สต็อก บัญชีผู้ใช้SQLite
APIคนส่งสารให้ frontend คุยกับ backendJSON, HTTP

3 Tier และหน้าที่ของแต่ละชั้น

Presentation Tier สิ่งที่ผู้ใช้เห็น — HTML / CSS / JS / Bootstrap "What the user sees" HTTP request HTTP response Logic / Application Tier ตรวจข้อมูล คำนวณยอด จัดการสิทธิ์ — Node.js / Express "What the app does" SQL query rows Persistence / Data Tier เก็บข้อมูลถาวร — SQLite / JSON files "What the app remembers" แยกชั้นแล้วเปลี่ยนหน้าตา (ชั้นบน) ได้โดยไม่กระทบข้อมูล (ชั้นล่าง)

การแยกชั้นทำให้แต่ละชั้นเปลี่ยนแปลงได้อิสระ และสลับ client ได้ (เว็บ / มือถือ ใช้ backend เดียวกัน)

LayerResponsibilityTools
Presentation LayerWhat the user sees — layout, design, การโต้ตอบHTML, CSS, JavaScript, Bootstrap
Logic LayerWhat the app does — validate ข้อมูล คำนวณยอด สื่อสารระหว่าง serviceNode.js, Express
Persistence LayerWhat the app remembers — เก็บโปรไฟล์ สินค้า ประวัติคำสั่งซื้อSQLite, JSON files
กับดักข้อสอบ: การ validate ที่ Presentation layer เป็นเรื่อง UX เท่านั้น ความถูกต้องจริงต้องตรวจซ้ำที่ Logic layer เสมอ เพราะผู้ใช้แก้ค่าใน DevTools ได้

Client–Server

Request : Client ขอทรัพยากร  เช่น "ขอ index.html" หรือ "เช็ค login"  ผ่าน HTTP/HTTPS
Response: Server ส่งทรัพยากรกลับ หรือส่ง error เช่น "200 OK" หรือ "404 Not Found"

HTTP Lifecycle 7 ขั้นตอน

Client Browser DNS Server Server middleware + logic Database 1. DNS lookup → IP 2. TCP/TLS handshake ~100ms 3. HTTP request (method, URL, headers, body) 4. processing 5-6. response (status + headers + body) 7. render ทุก request เป็นอิสระต่อกัน — server ไม่จำว่าใครเคยขออะไรมาก่อน (stateless)

1 DNS · 2 TCP/TLS · 3 ส่ง request · 4 server ประมวลผล · 5 สร้าง response · 6 ส่งกลับ · 7 เบราว์เซอร์ render

  1. Initiation & DNS Lookup — เบราว์เซอร์แปลงชื่อโดเมนเป็น IP
  2. TCP/TLS Handshake — สร้างการเชื่อมต่อที่ปลอดภัย ใช้เวลาราว 100ms
  3. Sending the Request — ส่ง method, URL, headers และ body (ถ้ามี)
  4. Server Processing — ผ่าน middleware (auth / logging) แล้วเข้า application layer
  5. Generating the Response — สร้าง status code + headers + content
  6. Sending the Response — ส่งกลับผ่านการเชื่อมต่อเดิม
  7. Rendering — เบราว์เซอร์ parse HTML/CSS/JS แล้ววาดหน้าจอ

HTTP Methods

Methodความหมายตัวอย่างมี body ไหม
GETอ่านข้อมูล (Read)GET /api/productsไม่มี
POSTสร้างข้อมูลใหม่ (Create)POST /api/checkoutมี
PUT / PATCHแก้ข้อมูลเดิม (Update)PATCH /api/products/1มี
DELETEลบข้อมูล (Destroy)DELETE /api/cart/5ปกติไม่มี
PUT vs PATCH: PUT แทนที่ทรัพยากรทั้งชิ้น ส่วน PATCH แก้เฉพาะบางฟิลด์

Status Codes

กลุ่มความหมายตัวที่ต้องจำ
2xxสำเร็จ200 OK, 201 Created
3xxเปลี่ยนเส้นทาง301, 302
4xxฝั่ง client ผิด400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xxฝั่ง server ผิด500 Internal Server Error
ข้อสอบชอบถาม: ส่งข้อมูลไม่ครบ/ผิดรูปแบบ → 400 · ไม่ได้ล็อกอินหรือ token ไม่ถูกต้อง → 401 · ล็อกอินแล้วแต่ไม่มีสิทธิ์ → 403 · ไม่มีทรัพยากรนั้น → 404 · โค้ดฝั่ง server พัง → 500

โครงสร้าง Request / Response

ทุกข้อความมี 2 ส่วน: Header (ข้อมูลกำกับ เช่น "ฉันคือใคร" "อยากได้รูปแบบไหน") และ Body (ข้อมูลจริง)

REQUEST                              RESPONSE
--------------------------------     --------------------------------
Method   : GET                       Status  : 200 OK
Endpoint : /api/products             Headers : Content-Type: application/json
Headers  : Accept: application/json  Body    : [{"id":1,"name":"Laptop","price":999}, ...]
Body     : (ว่าง สำหรับ GET)
ตารางนี้เรียกว่า "Contract" Table — เป็นข้อตกลงระหว่าง frontend กับ backend ที่ต้องเขียนก่อนลงมือโค้ด

กระบวนการพัฒนา 4 ขั้น

  1. Requirements & Prerequisites — กำหนดกฎธุรกิจ เช่น "ผู้ใช้ต้องล็อกอินก่อนถึงจะ checkout ได้"
  2. Logical Design — วาด flowchart หรือ sequence diagram ให้เห็นเส้นทางข้อมูลจากปุ่ม "Buy" ถึง database ก่อนเขียนโค้ด
  3. Construction — สร้างแบบแยกส่วน (modular / microservices) เพื่อให้ขยายระบบได้
  4. Validation & Deployment — ทดสอบว่า logic ทำงานตามที่ตั้งใจ แล้ว deploy เช่นขึ้น GitHub Pages
AI เป็น "ผู้ช่วย" แต่ UML คือ "ผู้จัดการ" — ถ้าไดอะแกรมผิด AI จะเขียนโค้ดที่ "สมบูรณ์แบบ" ให้กับโจทย์ที่ผิด

Git & Conventional Commits

คำความหมาย
Repositoryโฟลเดอร์ดิจิทัลที่เก็บไฟล์โปรเจกต์พร้อมประวัติทั้งหมด
Commit"ภาพนิ่ง" ของโค้ด ณ เวลาหนึ่ง พร้อมข้อความอธิบายว่าเพิ่ม logic อะไร
Pushส่งงานจากเครื่องตัวเองขึ้น remote server (GitHub)
 
รูปแบบ:  type(optional-scope): description

feat     : ฟีเจอร์ใหม่สำหรับผู้ใช้
fix      : แก้บั๊ก
docs     : แก้เอกสารอย่างเดียว
style    : เปลี่ยนที่ไม่กระทบความหมายของโค้ด (เว้นวรรค จัดรูปแบบ)
refactor : ปรับโครงสร้างโค้ด ไม่ใช่ทั้งแก้บั๊กและไม่ใช่ฟีเจอร์ใหม่
test     : เพิ่มหรือแก้เทสต์

เหตุผลที่ใช้รูปแบบนี้: ทำ automated versioning, สร้าง changelog ที่มีความหมาย และ review โค้ดได้เร็วขึ้น

แนวข้อสอบอัตนัย

โจทย์: ผู้ใช้แก้ราคาสินค้าเป็น $0 ใน Browser Console แล้วกด "Buy" ระบบบันทึกคำสั่งซื้อราคา $0 สำเร็จ จงอธิบายปัญหา สาเหตุทางเทคนิค ผลกระทบ และวิธีแก้เชิงสถาปัตยกรรม

โครงคำตอบ 4 ขั้น

  1. ปัญหา — ระบบเชื่อราคาที่ client ส่งมา ทำให้สั่งซื้อของราคา $0 ได้
  2. สาเหตุทางเทคนิค — validation ทำอยู่แค่ Presentation tier ซึ่งผู้ใช้แก้ได้ทั้งหมดผ่าน DevTools ส่วน Logic tier รับ req.body.price มาใช้คำนวณตรง ๆ โดยไม่ตรวจซ้ำ
  3. ผลกระทบ — สูญเสียรายได้โดยตรง ข้อมูลยอดขายผิด สต็อกถูกตัดโดยไม่ได้เงิน และเป็นช่องให้ทำซ้ำเป็นวงกว้าง
  4. วิธีแก้เชิงสถาปัตยกรรม — Logic tier ต้องไม่รับราคาจาก client เลย ให้ส่งมาแค่ productId และ quantity แล้ว server ดึงราคาจริงจาก Persistence tier มาคำนวณเอง พร้อมตรวจสต็อกและตอบ 400 เมื่อข้อมูลไม่สมเหตุสมผล
← หน้าแรก หัวข้อถัดไป: UML →