ข
ติวสอบภาค ข
PRO
กลับไปทำข้อสอบวิชานี้

ความรู้เกี่ยวกับการพัฒนาโปรแกรมระบบงานในลักษณะ Web Application

ครบวงจรจากต้นฉบับตรงวิชาและชุดข้อมูลเดิม 150 ข้อ เสริมมาตรฐานปัจจุบัน: HTTP RFC 9110, OWASP Top 10:2025 และ WCAG 2.2

18 หัวข้อ · อ่านประมาณ 192 นาที

อ่านฟรีได้ 2 จาก 18 หัวข้อ11%
สารบัญ18 หัวข้อหลัก
  1. 1.บทนำ — ขอบเขตวิชาและมาตรฐานอ้างอิงที่ตรวจแล้ว
  2. 2.REST/API Contract ที่ใช้งานจริง
  3. 3.Design Principles และ Code Quality
  4. 4.พื้นฐาน Web Application และสถาปัตยกรรมระบบ — หลักการทำงานของ HTTP/HTTPS Protocol
  5. 5.พื้นฐาน Web Application และสถาปัตยกรรมระบบ — โครงสร้างของ Web Server และ Application Server
  6. 6.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application › ส่วนที่ 1: Front-end — ส่วนที่ผู้ใช้มองเห็น — JavaScript พื้นฐานและ ES6+
  7. 7.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application › ส่วนที่ 2: Back-end — เครื่องยนต์เบื้องหลัง — Framework ฝั่ง Back-end
  8. 8.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application › ส่วนที่ 4: การจัดการ Authentication และ Session — Session และ Cookie
  9. 9.เทคโนโลยีและภาษาที่ใช้พัฒนา Web Application — สรุปประเด็นสำคัญประจำบท
  10. 10.ฐานข้อมูลและการจัดการข้อมูลใน Web Application — การเขียน SQL พื้นฐาน
  11. 11.ฐานข้อมูลและการจัดการข้อมูลใน Web Application › การเชื่อมต่อฐานข้อมูลด้วย ORM — แนวคิดของ ORM (Object-Relational Mapping)
  12. 12.ฐานข้อมูลและการจัดการข้อมูลใน Web Application — Database Connection Pooling
  13. 13.ฐานข้อมูลและการจัดการข้อมูลใน Web Application › การออกแบบ Index เพื่อเพิ่มประสิทธิภาพ — Index คืออะไรและทำงานอย่างไร
  14. 14.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application › OWASP Top 10 และช่องโหว่ความปลอดภัยที่พบบ่อย — XSS (Cross-Site Scripting)
  15. 15.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — การเข้ารหัสข้อมูลด้วย SSL/TLS และ HTTPS
  16. 16.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — มาตรฐาน WCAG สำหรับ Accessibility
  17. 17.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — กระบวนการ SDLC และ Agile/Scrum
  18. 18.ความมั่นคงปลอดภัย (Security) และมาตรฐานการพัฒนา Web Application — การ Deploy และ CI/CD Pipeline
หัวข้อ 1

บทนำ — ขอบเขตวิชาและมาตรฐานอ้างอิงที่ตรวจแล้ว

Web Application คือระบบซอฟต์แวร์ที่ผู้ใช้เข้าถึงผ่าน Web user agent โดยอาศัยมาตรฐานเว็บและมักมีการประมวลผล/สถานะ/ข้อมูลฝั่ง Server หรือ Service ขอบเขตการพัฒนาจึงครอบ Requirement, UX/accessibility, frontend, backend/API, data, security, testing, deployment และ operation ไม่ใช่เพียงเขียนหน้า HTML

ขอบเขตวิชาและมาตรฐานอ้างอิงที่ตรวจแล้ว
แหล่งมาตรฐานหลักรุ่น/สถานะที่ใช้ในสรุปสิ่งที่ยึด
IETF RFC 9110HTTP Semantics, Internet StandardResource, method, safe/idempotent, status code และ HTTP semantics ร่วมทุกเวอร์ชัน
OWASP Top 10รุ่นเผยแพร่ 202510 หมวดความเสี่ยงล่าสุด; แยกจากชื่อหมวดรุ่น 2021 ในข้อมูลเดิม
W3C WCAGWCAG 2.2 Recommendation ฉบับ 12 ธันวาคม 2024หลัก POUR, Success Criteria และระดับ A/AA/AAA
HTML/CSS/ECMAScript/Web APIsLiving standards/มาตรฐานที่เปลี่ยนได้ตอบหลักเชิงแนวคิดและตรวจ compatibility ก่อนใช้ feature
OAuth 2.0 และ OpenID ConnectAuthorization framework กับ identity layerห้ามใช้คำสองคำนี้แทนกัน
เอกสารต้นฉบับตรงวิชาebooks-final ลำดับ 060พื้นฐาน เทคโนโลยี ฐานข้อมูล ความปลอดภัย SDLC และตารางทบทวนประเด็น

คำว่า “ล่าสุด” ในตารางเทคโนโลยีเปลี่ยนตามเวลา เนื้อหาจึงเน้น semantics และ trade-off ที่คงทน ส่วนชื่อ framework/ผลิตภัณฑ์เป็นตัวอย่าง ไม่ใช่ข้อสรุปสากล

Web site, Web Application, SPA, PWA และ Native app
Static site
ลักษณะเด่น: ส่งไฟล์ที่สร้างไว้ล่วงหน้า; อาจมี JavaScript/CDN/form ภายนอก; สิ่งที่ไม่ควรเหมารวม: Static ไม่ได้แปลว่าไม่มี interaction หรือไม่ปลอดภัยโดยอัตโนมัติ
Dynamic web
ลักษณะเด่น: Response/ข้อมูลเปลี่ยนตาม request, user, time หรือ backend; สิ่งที่ไม่ควรเหมารวม: อาจ render ที่ server หรือ client ก็ได้
Web Application
ลักษณะเด่น: มี workflow/state/business rule เช่น งานทะเบียนหรืออนุมัติ; สิ่งที่ไม่ควรเหมารวม: ไม่จำเป็นต้องเป็น SPA
SPA
ลักษณะเด่น: shell หน้าเดียวและเปลี่ยน view ด้วย client routing/data fetch; สิ่งที่ไม่ควรเหมารวม: URL, history, accessibility, SEO และ initial load ยังต้องออกแบบ
MPA
ลักษณะเด่น: navigation โหลด document ใหม่เป็นหลัก; สิ่งที่ไม่ควรเหมารวม: ไม่แปลว่าช้าหรือเก่า; progressive enhancement ทำ UX ดีได้
PWA
ลักษณะเด่น: ใช้ Web App Manifest, service worker และความสามารถติดตั้ง/ทำงานบางส่วนแบบ offline; สิ่งที่ไม่ควรเหมารวม: HTTPS และ service-worker lifecycle/cache invalidation เป็นประเด็นสำคัญ
Native mobile/desktop
ลักษณะเด่น: ติดตั้งและใช้ platform API โดยตรง; สิ่งที่ไม่ควรเหมารวม: แลก distribution, update, codebase และ capability กับเว็บ
Hybrid/cross-platform
ลักษณะเด่น: Web view หรือ runtime กลางห่อ application; สิ่งที่ไม่ควรเหมารวม: ประสิทธิภาพ/UX/permission ขึ้นกับสถาปัตยกรรมจริง

เลือกแนวทางจาก user journey, latency/offline, device capability, accessibility, SEO/discoverability, security, team skill, lifecycle และต้นทุนรวม ไม่เลือกจากคำว่า “modern”

ส่วนประกอบและเส้นทาง Request แบบ End-to-end

  1. 1ผู้ใช้/Browser สร้าง URL และตรวจ cache/service worker
  2. 2DNS resolve ชื่อเป็นปลายทาง
  3. 3สร้าง transport และ TLS สำหรับ HTTPS
  4. 4CDN/reverse proxy/WAF/load balancer รับ request
  5. 5Web/app server ตรวจ route, authn/authz, validation และ business rule
  6. 6cache/database/queue/external service ทำงาน
  7. 7สร้าง response/status/header/body
  8. 8Browser parse/render/execute และส่ง telemetry ตามนโยบาย
DNS
หน้าที่: Name resolution, TTL, routing บางแบบ; Failure/สิ่งที่ต้องสังเกต: NXDOMAIN, stale cache, propagation
TLS
หน้าที่: Confidentiality, integrity, server authentication ตาม certificate; Failure/สิ่งที่ต้องสังเกต: certificate/hostname/expiry/chain, downgrade/config
CDN/edge cache
หน้าที่: เสิร์ฟ content ใกล้ผู้ใช้และลด origin load; Failure/สิ่งที่ต้องสังเกต: cache key ผิด, stale/private data leak
Reverse proxy/gateway
หน้าที่: routing, TLS termination, policy, rate limit; Failure/สิ่งที่ต้องสังเกต: header trust, body/time limits, single point
Application
หน้าที่: business logic/orchestration; Failure/สิ่งที่ต้องสังเกต: exception, resource leak, race, dependency failure
Database/cache
หน้าที่: state/query/transaction; Failure/สิ่งที่ต้องสังเกต: contention, stale data, pool exhaustion
Queue/worker
หน้าที่: async work และ load leveling; Failure/สิ่งที่ต้องสังเกต: duplicate, poison message, backlog
Browser
หน้าที่: DOM/CSSOM/render/event/storage; Failure/สิ่งที่ต้องสังเกต: compatibility, XSS, performance, accessibility

HTTP เป็น stateless ในระดับ protocol แต่ application สร้าง state ได้ผ่าน cookie/session/token/database ห้ามสรุปว่า stateless เท่ากับไม่มี login หรือไม่มีข้อมูลสถานะ

Architecture: Layer, Tier และรูปแบบการติดตั้ง
Layer
ความหมาย: การแบ่งความรับผิดเชิงตรรกะใน code; ตัวอย่าง: presentation, application/use case, domain, data/infrastructure
Tier
ความหมาย: การแบ่งหน่วย deploy/process/machine เชิงกายภาพ; ตัวอย่าง: browser, app server, database server
Client–server
ความหมาย: client ขอ service; server ตอบตาม interface; ตัวอย่าง: browser ↔ web/API server
2-tier
ความหมาย: client ติดต่อ data/service โดยตรงมาก; ตัวอย่าง: desktop client ↔ DB; coupling/security สูงกว่า
3-tier
ความหมาย: presentation ↔ application ↔ data; ตัวอย่าง: UI ไม่เปิด DB credential โดยตรง
N-tier
ความหมาย: เพิ่ม gateway/service/cache/queue/integration ตามเหตุผล; ตัวอย่าง: จำนวน tier มากไม่เท่ากับคุณภาพดีกว่า
MVC
ความหมาย: Model–View–Controller แยก state/domain, presentation และ input coordination; ตัวอย่าง: รายละเอียด flow ต่างตาม framework
Clean/Hexagonal
ความหมาย: business rule อยู่แกนกลาง; dependency ชี้เข้า; adapter ต่อโลกภายนอก; ตัวอย่าง: ช่วย test/replace infrastructure แต่มี abstraction cost

ชั้น Presentation อาจมี presentation logic และ client validation ได้ แต่กฎธุรกิจที่ต้องเชื่อถือควรถูกบังคับฝั่ง Server/domain ด้วย การบอกว่า UI “ไม่มี logic เลย” จึงเป็นคำจำที่กว้างเกินจริง

Monolith, Modular monolith, Microservices และ Event-driven
Monolith
จุดแข็ง: deploy/test/transaction/trace ง่ายในช่วงต้น; ต้นทุน/เงื่อนไข: coupling และ release ใหญ่เมื่อ boundary ไม่ดี
Modular monolith
จุดแข็ง: process เดียวแต่ module/boundary ชัด; refactor/deploy ยังง่าย; ต้นทุน/เงื่อนไข: ต้องบังคับ dependency และ ownership จริง
Microservices
จุดแข็ง: deploy/scale/ownership แยกตาม business capability; ต้นทุน/เงื่อนไข: network failure, eventual consistency, observability, platform และ team coordination
Serverless/function style
จุดแข็ง: scale/operation บางส่วนเป็นภาระ platform; จ่ายตามรูปแบบใช้; ต้นทุน/เงื่อนไข: latency, limits, state/external connection, portability ตามผู้ให้บริการ
Event-driven
จุดแข็ง: decouple เวลาและ absorb burst; ต้นทุน/เงื่อนไข: ordering, duplicate, schema evolution, replay และ debugging
Micro-frontend
จุดแข็ง: ทีม/UI deploy แยก; ต้นทุน/เงื่อนไข: UX consistency, bundle/duplicate dependency, cross-app state/routing

เกณฑ์แยก service คือ bounded context, ownership, independent change/scale/failure—not จำนวนตารางหรือฟังก์ชัน เริ่มจาก boundary ที่เข้าใจและวัดปัญหาก่อน; distributed system เพิ่ม failure mode โดยธรรมชาติ

HTTP Semantics: Safe, Idempotent และ Cacheable
GET
เจตนามาตรฐาน: ขอ representation ของ resource; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: ผลตอบอาจเปลี่ยนตามเวลา; idempotent ไม่ได้แปลว่า response เท่าเดิม
HEAD
เจตนามาตรฐาน: เหมือน GET แต่ไม่มี response content; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: ใช้ดู metadata/condition โดยไม่รับ body
POST
เจตนามาตรฐาน: ให้ resource ประมวล representation ตาม semantics ของมัน; Safe: ไม่; Idempotent: ไม่โดยทั่วไป; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: อาจสร้าง/สั่งงาน; ทำ idempotency key ได้ระดับ application
PUT
เจตนามาตรฐาน: สร้างหรือแทน state ของ target resource ด้วย representation; Safe: ไม่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: retry ผลที่ตั้งใจเท่าเดิม แม้ log/time/response อาจต่าง
PATCH
เจตนามาตรฐาน: ใช้ชุดการเปลี่ยนแปลงบางส่วน; Safe: ไม่; Idempotent: ไม่รับประกัน; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: รูปแบบ patch อาจออกแบบให้ idempotent ได้
DELETE
เจตนามาตรฐาน: ขอให้ลบ association ของ target URI; Safe: ไม่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: เรียกซ้ำยังมี intended effect เดิม แต่ status อาจต่าง
OPTIONS
เจตนามาตรฐาน: ขอ communication options; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: ใช้กับ CORS preflight บางกรณี
CONNECT
เจตนามาตรฐาน: สร้าง tunnel; Safe: ไม่; Idempotent: ไม่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: proxy/tunnel use case
TRACE
เจตนามาตรฐาน: loop-back diagnostic; Safe: ใช่; Idempotent: ใช่; ประเด็นเป็นประเด็นสำคัญ/ออกแบบ: มักปิดใน production เพื่อลด attack surface

Safe หมายถึง client ไม่ได้ร้องขอให้เปลี่ยน state ไม่ใช่ไม่มี side effect เลย เช่น logging/metrics ทำได้ Idempotent หมายถึงผลที่ตั้งใจบน server จากคำขอเหมือนกันหลายครั้งเทียบครั้งเดียว ไม่ได้แปลว่า response bytes เท่ากัน

HTTP Request, Response, Headers และ Status
Method + target
ตัวอย่าง/หน้าที่: เจตนาและ URI/path/query ของ resource
Header
ตัวอย่าง/หน้าที่: Host, Accept, Content-Type, Authorization, Cookie, conditional/cache/tracing metadata
Content
ตัวอย่าง/หน้าที่: representation ที่ส่ง; semantics ขึ้นกับ method/content type
Origin/context
ตัวอย่าง/หน้าที่: scheme/host/port และ security context ของ browser
1xx
ความหมาย: informational/interim; ตัวอย่างที่ต้องแยก: 100 Continue, 101 Switching Protocols
2xx
ความหมาย: สำเร็จตาม semantics; ตัวอย่างที่ต้องแยก: 200 OK, 201 Created, 202 Accepted ยังไม่เสร็จ, 204 No Content
3xx
ความหมาย: redirect/cache choice; ตัวอย่างที่ต้องแยก: 301/308 permanent; 302/303/307 semantics method ต่าง; 304 ใช้ cached representation
4xx
ความหมาย: request/client context ทำให้ดำเนินไม่ได้; ตัวอย่างที่ต้องแยก: 400 syntax/validation ทั่วไป, 401 ต้องมี authentication challenge/credentials, 403 ไม่อนุญาต, 404 ไม่พบหรืออาจซ่อน, 409 conflict, 412 precondition, 422 content เข้าใจแต่ process ไม่ได้, 429 rate limit
5xx
ความหมาย: server ไม่ทำ request ที่ดู valid สำเร็จ; ตัวอย่างที่ต้องแยก: 500 unexpected, 502 upstream response, 503 unavailable, 504 upstream timeout

Status code เป็นส่วนหนึ่งของ contract แต่ error body ควรมี code เชิงโดเมน ข้อความปลอดภัย correlation/trace ID และรายละเอียด field ที่ validate ไม่ผ่านโดยไม่รั่ว stack trace/secret

HTTP/1.1, HTTP/2, HTTP/3 และ TLS
HTTP semantics
แก่น: method/status/header/cache/resource; จึงต้องแยก: semantics ร่วมข้าม HTTP/1.1, 2 และ 3
HTTP/1.1
แก่น: ข้อความบน TCP, persistent connection, request ordering ตาม connection; จึงต้องแยก: หลาย connection/keep-alive ไม่ใช่ multiplex แบบ HTTP/2
HTTP/2
แก่น: binary framing, multiplex streams, header compression บน connection; จึงต้องแยก: ยังมี TCP-level head-of-line เมื่อ packet loss
HTTP/3
แก่น: HTTP บน QUIC ซึ่งใช้ UDP transport และ TLS ใน QUIC; จึงต้องแยก: UDP ไม่ได้แปลว่าไม่มี reliability/security; QUIC จัดให้
HTTPS
แก่น: HTTP ผ่านช่องทางที่ authenticate/encrypt/integrity-protect ด้วย TLS; จึงต้องแยก: ไม่ได้รับประกันว่า server/app ปลอดช่องโหว่หรือเนื้อหาน่าเชื่อถือ
Certificate
แก่น: ผูก public key/identity ภายใต้ trust chain และ hostname/time validation; จึงต้องแยก: แม่กุญแจบอก secure transport ไม่ใช่ความซื่อสัตย์ของเจ้าของเนื้อหา

SSL เป็นโปรโตคอลรุ่นเก่าที่เลิกใช้ในการออกแบบสมัยใหม่ คำว่า SSL certificate มักเป็นภาษาพูด แต่การเชื่อมต่อจริงควรเป็น TLS ที่ตั้งค่าเหมาะสม

HTTP Caching, Validation และ CDN
Cache-Control
หน้าที่: กำหนด freshness/storage/revalidation เช่น max-age, no-store, private/public; ข้อควรระวัง: no-cache หมายถึงต้อง revalidate ไม่ใช่ห้ามเก็บ; no-store จึงต่าง
ETag + If-None-Match
หน้าที่: validator เชิง identifier ของ representation; ข้อควรระวัง: strong/weak semantics ต่าง; 304 ไม่มี representation ใหม่
Last-Modified + If-Modified-Since
หน้าที่: validator ตามเวลาแก้ไข; ข้อควรระวัง: ความละเอียดเวลา/clock ทำให้ไม่แม่นเท่า entity tag บางกรณี
Vary
หน้าที่: บอก request fields ที่เปลี่ยน representation/cache key; ข้อควรระวัง: ขาด Vary อาจเสิร์ฟภาษา/encoding/user variant ผิด
CDN
หน้าที่: shared cache/reverse proxy ใกล้ผู้ใช้; ข้อควรระวัง: ห้าม cache personalized response ด้วย key ไม่ครบ
Invalidation/versioning
หน้าที่: purge/tag หรือ immutable fingerprinted asset; ข้อควรระวัง: cache invalidation เป็น consistency problem
Service worker cache
หน้าที่: programmable browser-side offline/cache; ข้อควรระวัง: stale shell/data และ lifecycle update ต้องออกแบบ

Cache มีหลายชั้น: browser, service worker, CDN/proxy, application cache และ database cache ต้องรู้ owner, key, TTL, invalidation, stampede protection และ privacy ของแต่ละชั้น

URL, URI, Origin, Same-origin Policy และ CORS
URI
แก่น: ตัวระบุ resource; URL เป็น URI ที่ระบุตำแหน่ง/วิธีเข้าถึงตาม scheme
URL components
แก่น: scheme://userinfo@host:port/path?query#fragment; fragment ไม่ถูกส่งใน HTTP request ตามปกติ
Origin
แก่น: tuple ของ scheme + host + port; path ไม่ใช่ส่วน origin
Same-origin Policy
แก่น: browser จำกัด script จาก origin หนึ่งอ่าน/จัดการ resource ของอีก origin
CORS
แก่น: กลไก response headers ให้ server opt in ว่า origin ใดอ่าน response ผ่าน browser ได้
Simple request
แก่น: บาง method/header/content type ส่งตรงและตรวจ CORS ที่ response
Preflight
แก่น: browser ส่ง OPTIONS ถาม permission ก่อน request บางชนิด
Credentials
แก่น: cookie/client credential ต้องตั้งทั้งฝั่ง request และ server อย่างเจาะจง; wildcard origin ใช้ร่วม credential ไม่ได้ตามรูปแบบทั่วไป

CORS ไม่ใช่ authentication, authorization, firewall หรือการป้องกัน server-to-server request ผู้โจมตียังเรียก API นอก browser ได้ Server ต้องตรวจสิทธิ์ทุก request เอง

HTML Semantics, DOM, Forms และ Progressive enhancement
Semantic HTML
หลักที่ถูกต้อง: เลือก heading, nav, main, button, form, label, table ตามความหมายก่อน ARIA
DOM
หลักที่ถูกต้อง: tree/object model ของ document ที่ script และ accessibility API ใช้ ไม่ใช่ source HTML เพียงอย่างเดียว
Form
หลักที่ถูกต้อง: label เชื่อม control, name ใช้ส่งค่า, type/autocomplete ช่วย input; server validation ยังจำเป็น
Button vs link
หลักที่ถูกต้อง: button ทำ action; link นำทางไป resource/URL
Progressive enhancement
หลักที่ถูกต้อง: core content/action ใช้ได้ก่อน แล้วเพิ่ม CSS/JavaScript capability
Responsive
หลักที่ถูกต้อง: layout/media/container query และ fluid sizing ตามพื้นที่ ไม่ใช่ทำเฉพาะ device รุ่นหนึ่ง
Media
หลักที่ถูกต้อง: responsive images, dimensions, lazy loading ตามเหมาะสม, alt text ตามหน้าที่
ARIA
หลักที่ถูกต้อง: เสริม semantics/state เมื่อ native element ไม่พอ; ARIA ที่ผิดอาจแย่กว่าการไม่ใส่

Client validation เพิ่ม UX แต่เชื่อถือไม่ได้เพราะ bypass ได้ ข้อมูลทุกช่องทาง—form, JSON, header, file, message—ต้อง validate ตาม schema/business rule ที่ trust boundary

CSS, Layout และ Responsive design
Cascade
คำอธิบาย/ข้อควรระวัง: origin, importance, layer, specificity และ source order ร่วมตัดสินค่า
Box model
คำอธิบาย/ข้อควรระวัง: content + padding + border + margin; box-sizing เปลี่ยนการคิดขนาด declared box
Normal flow
คำอธิบาย/ข้อควรระวัง: block/inline formatting เป็นฐานก่อน position/flex/grid
Flexbox
คำอธิบาย/ข้อควรระวัง: layout หนึ่งมิติและกระจาย/จัดแนว item
Grid
คำอธิบาย/ข้อควรระวัง: layout สองมิติ row/column และพื้นที่
Position
คำอธิบาย/ข้อควรระวัง: static/relative/absolute/fixed/sticky มี containing block/stacking context
Responsive units
คำอธิบาย/ข้อควรระวัง: %, rem/em, viewport/container units เลือกตามความสัมพันธ์ที่ต้องการ
Media/container query
คำอธิบาย/ข้อควรระวัง: ปรับตาม viewport/media capability หรือขนาด container
Design tokens
คำอธิบาย/ข้อควรระวัง: ชื่อเชิง semantic ของ color/spacing/type ช่วย consistency/theming
Reduced motion/contrast
คำอธิบาย/ข้อควรระวัง: เคารพ preference และรักษา focus/contrast/zoom

อย่าแก้ responsive ด้วย breakpoint จำนวนมากก่อนจัด content hierarchy และ intrinsic layout; ทดสอบ keyboard, zoom, long text, localization และหน้าจอหลายขนาด

JavaScript Runtime, Event loop และ Async
Call stack
แก่น: รัน JavaScript job ตามลำดับใน execution context
Heap
แก่น: พื้นที่ object/memory ที่ garbage collector จัดการ
Web/host APIs
แก่น: timer, network, DOM, storage ไม่ใช่ทุกอย่างในภาษา ECMAScript เอง
Task/macrotask
แก่น: เช่น event/timer บางชนิดเข้าสู่ task queue
Microtask
แก่น: promise reaction/queueMicrotask ถูก drain ก่อน render/next task ตาม event-loop rules
Promise
แก่น: ตัวแทน eventual completion/failure; ไม่ทำให้ CPU work ขนานเอง
async/await
แก่น: syntax บน Promise; await yield continuation ไม่ block thread ทั้ง process
Race condition
แก่น: ผลขึ้นกับ timing ของงาน async/shared state
Abort/cancellation
แก่น: ยกเลิก fetch/work เมื่อไม่ต้องการ ลด stale response/resource waste
Web Worker
แก่น: แยก thread/context สำหรับ CPU work; สื่อสารด้วย message/transfer

ข้อผิดพลาดที่พบบ่อยคือ await แบบอนุกรมโดยไม่จำเป็น, Promise ไม่ catch, update state หลัง component ถูกทิ้ง, stale closure, งาน CPU หนักค้าง main thread และ retry โดยไม่มีขอบเขต

Rendering: CSR, SSR, SSG, Hydration และ Streaming
CSR
เกิดอะไร: browser fetch JS/data แล้วสร้าง UI; เหมาะ/ข้อแลกเปลี่ยน: interaction สูง; initial JS/SEO/accessibility/loading state ต้องดู
SSR
เกิดอะไร: server render HTML ต่อ request; เหมาะ/ข้อแลกเปลี่ยน: personalized/fresh; server cost/cache/latency/hydration
SSG
เกิดอะไร: render ล่วงหน้าตอน build; เหมาะ/ข้อแลกเปลี่ยน: เนื้อหาคงที่/เสิร์ฟเร็ว; freshness/build scale
Incremental regeneration
เกิดอะไร: rebuild/revalidate บาง page หลัง deploy; เหมาะ/ข้อแลกเปลี่ยน: สมดุล freshness กับ static delivery; stale window
Hydration
เกิดอะไร: ผูก behavior/client state เข้ากับ server-rendered markup; เหมาะ/ข้อแลกเปลี่ยน: markup/state/time ไม่ตรงทำ mismatch
Streaming SSR
เกิดอะไร: ส่ง UI/HTML เป็นส่วนเมื่อพร้อม; เหมาะ/ข้อแลกเปลี่ยน: ลดเวลารอส่วนแรก; error/loading boundary/cache ซับซ้อน
Islands/partial hydration
เกิดอะไร: hydrate เฉพาะ interactive islands; เหมาะ/ข้อแลกเปลี่ยน: ลด JS แต่ boundary/data flow ต้องชัด
Server component pattern
เกิดอะไร: บาง component render/fetch ฝั่ง server และไม่ส่ง runtime JS ของส่วนนั้น; เหมาะ/ข้อแลกเปลี่ยน: serialization, boundary, framework semantics

เลือก rendering ต่อ route/segment ไม่จำเป็นต้องแบบเดียวทั้งระบบ วัด real-user performance, freshness, personalization, cacheability, development complexity และ failure behavior

API Styles: REST, RPC, GraphQL, SOAP, WebSocket และ SSE
RESTful HTTP
จุดเด่น: resource + uniform HTTP semantics + representation/cache; ความเสี่ยง/เหมาะ: boundary/resource/error/version ให้สม่ำเสมอ
RPC
จุดเด่น: operation/action ชัดและ generate contract ได้; ความเสี่ยง/เหมาะ: coupling กับ method/schema; HTTP semantics อาจถูกซ่อน
GraphQL
จุดเด่น: client เลือก field ผ่าน typed schema endpoint; ความเสี่ยง/เหมาะ: authorization ต่อ field, query cost/N+1/cache complexity
SOAP
จุดเด่น: XML envelope, WSDL/contract และ WS-* ecosystem; ความเสี่ยง/เหมาะ: พิธีการ/ขนาดสูงแต่เหมาะ integration ที่ต้อง formal standard
WebSocket
จุดเด่น: full-duplex connection ยาว; ความเสี่ยง/เหมาะ: connection state, auth refresh, scaling/backpressure/reconnect
SSE
จุดเด่น: server→browser event stream ผ่าน HTTP; ความเสี่ยง/เหมาะ: ทิศเดียว; reconnect/event ID; proxy timeout
Webhook
จุดเด่น: provider callback เมื่อ event เกิด; ความเสี่ยง/เหมาะ: signature, replay protection, retry, idempotent receiver
Message/queue API
จุดเด่น: async durable integration; ความเสี่ยง/เหมาะ: eventual consistency, duplicate/order/schema evolution

REST เป็น architectural style ไม่ใช่ protocol และไม่เท่ากับ “JSON over HTTP” ทุก API ส่วน SOAP เป็น protocol/message framework ที่มักมี formal contract

หัวข้อ 2

REST/API Contract ที่ใช้งานจริง

Resource URI
แนวทาง: ใช้ noun/identity/hierarchy เท่าที่มีความหมาย ไม่ใส่ verb โดยไม่จำเป็น
Method/status
แนวทาง: ตรง semantics และแยก sync success จาก accepted async work
Representation
แนวทาง: Content-Type/Accept, schema, required/optional/null และ date/number semantics ชัด
Validation error
แนวทาง: stable machine code, field/path, safe message และ trace/correlation ID
Pagination
แนวทาง: offset/limit ง่ายแต่ drift; cursor/keyset เหมาะชุดใหญ่/เปลี่ยนเร็ว
Filtering/sorting
แนวทาง: allowlist field/operator และจำกัด query cost
Versioning
แนวทาง: prefer additive compatible change; breaking change มี policy/deprecation/migration
Concurrency control
แนวทาง: ETag/If-Match หรือ version field ป้องกัน lost update
Idempotency
แนวทาง: dedup key + request fingerprint + result/expiry/atomic record สำหรับ create/payment/retry
Rate limiting
แนวทาง: ต่อ principal/resource/risk; ตอบ 429 และ guidance โดยไม่เป็น authorization substitute
Documentation
แนวทาง: contract/examples/error/security/SLO/change log; contract test เทียบ implementation

API gateway รวม cross-cutting policy ได้ แต่ business authorization/invariant ยังต้องอยู่ใน service ที่เป็นเจ้าของข้อมูล ห้ามเชื่อ header identity จาก client โดยไม่ผ่าน trusted proxy contract

Reliability: Timeout, Retry, Idempotency และ Resilience
Timeout/deadline
หลักใช้: จำกัดเวลาทุก network call และส่ง budget ต่อ dependency; ข้อควรระวัง: default ยาว/ไม่มี timeout ทำ resource ค้าง
Retry
หลักใช้: เฉพาะ transient + safe/idempotent operation; exponential backoff + jitter + cap; ข้อควรระวัง: retry storm, duplicate side effect, deadline เกิน
Circuit breaker
หลักใช้: หยุดเรียก dependency ที่ล้มชั่วคราวและ probe recovery; ข้อควรระวัง: ไม่แทน timeout/fallback/monitoring
Bulkhead
หลักใช้: แยก pool/queue/resource ลด blast radius; ข้อควรระวัง: partition capacity ต้องเหมาะ
Backpressure
หลักใช้: ชะลอ/ปฏิเสธ/queue เมื่อ downstream รับไม่ไหว; ข้อควรระวัง: queue ไร้ขอบเขตเพียงย้ายจุดล้ม
Load shedding
หลักใช้: ตัดงาน priority ต่ำเมื่อ overload; ข้อควรระวัง: ต้องรักษาความถูกต้องและส่งสถานะชัด
Fallback
หลักใช้: ผล degraded/cached/default ที่ยอมรับได้; ข้อควรระวัง: ห้ามคืนข้อมูลผิด/เก่าโดยไม่บอกในงานเสี่ยงสูง
Health checks
หลักใช้: liveness แยก readiness; dependency check พอดี; ข้อควรระวัง: check หนักทำระบบพังเพิ่ม
Idempotent consumer
หลักใช้: บันทึก processed event/key atomic กับ side effect; ข้อควรระวัง: at-least-once delivery ทำ duplicate ได้

ข้อสรุป “retry ทุก error” ผิด ต้องจำแนก permanent/transient, operation semantics, deadline, attempt budget และ observability

Authentication, Authorization, Session, OAuth และ OIDC
Identification
ตอบให้ตรง: ผู้ใช้กล่าวว่าเป็น principal ใด
Authentication (AuthN)
ตอบให้ตรง: พิสูจน์ identity/credential
Authorization (AuthZ)
ตอบให้ตรง: ตัดสินว่า principal ทำ action กับ resource/context นี้ได้หรือไม่
Accounting/Audit
ตอบให้ตรง: บันทึกกิจกรรมที่เพียงพอและตรวจสอบได้ตามนโยบาย
Session
ตอบให้ตรง: server-side หรือ distributed state ผูก opaque session ID กับ login/context
JWT
ตอบให้ตรง: รูป token format แบบ signed/encrypted ตาม JOSE; payload ของ signed JWT อ่านได้ ไม่ใช่ encryption
OAuth 2.0
ตอบให้ตรง: framework สำหรับ delegated authorization/access token
OpenID Connect
ตอบให้ตรง: identity layer บน OAuth 2.0 สำหรับ authentication และ ID token/user info
SAML
ตอบให้ตรง: XML-based federation assertion ใน enterprise/SSO หลายระบบ
MFA
ตอบให้ตรง: ใช้ปัจจัยต่างประเภทมากกว่าหนึ่ง ลดผล credential เดี่ยวถูกขโมย
RBAC
ตอบให้ตรง: สิทธิผ่าน role; จัดการง่ายแต่ role explosion ได้
ABAC/policy-based
ตอบให้ตรง: ตัดสินจาก subject/resource/action/environment attributes; ยืดหยุ่นแต่ policy/test ซับซ้อน

Authentication สำเร็จไม่แปลว่ามีสิทธิ์ Server ต้องทำ object/function/field-level authorization ทุก request และตรวจ tenant/ownership จาก trusted identity—not ID ที่ client เปลี่ยนได้

Cookie, Session และ Token Storage อย่างปลอดภัย
Session ID
แนวทางและเหตุผล: สุ่มคาดเดายาก, rotate หลัง login/privilege change, revoke/expire และไม่ใส่ข้อมูลลับใน ID
Secure
แนวทางและเหตุผล: ส่ง cookie เฉพาะช่องทาง secure
HttpOnly
แนวทางและเหตุผล: script อ่าน cookie ไม่ได้ ลดการขโมย token ผ่าน XSS แต่ XSS ยังสั่ง request ใน browser ได้
SameSite
แนวทางและเหตุผล: ควบคุม cross-site cookie context ช่วยลด CSRF; เลือก Lax/Strict/None ตาม flow และ Secure เมื่อกำหนด None
Domain/Path
แนวทางและเหตุผล: ลด scope เท่าที่ทำได้; ไม่ใช่ security boundary ที่แทน host isolation ทั้งหมด
CSRF defense
แนวทางและเหตุผล: SameSite + anti-CSRF token/origin validation ตาม architecture; state-changing GET ผิด semantics
Browser storage
แนวทางและเหตุผล: localStorage อ่านได้ด้วย script origin; หลีกเลี่ยง long-lived bearer secret เมื่อ XSS risk สูง
Access token
แนวทางและเหตุผล: สั้น, audience/scope จำกัด, validate issuer/signature/time/algorithm และไม่ log
Refresh token
แนวทางและเหตุผล: ปกป้องสูง, rotate/reuse detection/revoke ตาม client type
Logout
แนวทางและเหตุผล: ยุติ session/revoke credential ที่เกี่ยว; ลบ client value อย่างเดียวอาจไม่พอ

JWT ไม่ได้ “ปลอดภัยกว่า session” โดยตัวมันเอง และ stateless verification อาจทำ revocation/permission freshness ยากขึ้น เลือกตาม trust boundary, client type, scale, revocation และ threat model

OWASP Top 10:2025 — รายการล่าสุดที่ต้องแยกจากปี 2021
A01
หมวด: Broken Access Control; แก่นปัญหา: บังคับ policy/ownership/tenant/function/object ไม่ครบ; รวม SSRF ใน mapping รุ่นนี้; Control หลัก: deny by default, server-side authorization ทุก request, trusted identity, network/URL egress control, test matrix
A02
หมวด: Security Misconfiguration; แก่นปัญหา: default/debug/permission/header/cloud/service/config ไม่ปลอดภัยหรือไม่สม่ำเสมอ; Control หลัก: harden baseline, minimal feature, config-as-code, automated check, secret separation, patch
A03
หมวด: Software Supply Chain Failures; แก่นปัญหา: dependency/build/registry/artifact/update pipeline ถูกแทรกแซงหรือตรวจไม่ครบ; Control หลัก: inventory/SBOM, pin/verify provenance-signature, protect CI, review dependency, rapid remediation
A04
หมวด: Cryptographic Failures; แก่นปัญหา: ไม่เข้ารหัส/เลือก algorithm-key-protocol/lifecycle ผิด; Control หลัก: data classification, modern vetted crypto, TLS, key management/rotation, password hashing, no secret in URL/log
A05
หมวด: Injection; แก่นปัญหา: ข้อมูลไม่เชื่อถือถูก interpreter มองเป็น command/query/template; Control หลัก: parameterization, context-aware output encoding, allowlist/schema, separate code/data, least privilege
A06
หมวด: Insecure Design; แก่นปัญหา: ขาด security requirements, threat model, abuse-case และ control เชิงออกแบบ; Control หลัก: secure design pattern, trust boundary, misuse case, risk review, invariant/rate/resource limit
A07
หมวด: Authentication Failures; แก่นปัญหา: credential/session/recovery/MFA/login control อ่อน; Control หลัก: standard identity, MFA, secure session, rate/credential-stuffing defense, safe recovery, no default credential
A08
หมวด: Software or Data Integrity Failures; แก่นปัญหา: เชื่อ code/data/update/deserialization โดยไม่ verify integrity/trust boundary; Control หลัก: signature/hash/provenance, trusted repository, safe serialization, protected CI/CD, review auto-update
A09
หมวด: Security Logging and Alerting Failures; แก่นปัญหา: event สำคัญไม่ถูก log/normalize/protect/alert/respond; Control หลัก: security event model, tamper resistance, correlation, alert with owner/runbook, retention/privacy และ exercise
A10
หมวด: Mishandling of Exceptional Conditions; แก่นปัญหา: error/edge/resource exhaustion/fail-open/logical condition จัดการผิด; Control หลัก: fail secure, centralized exception boundary, exhaustive state/limit/timeout, rollback/cleanup, chaos/negative test

OWASP Top 10 เป็น awareness document จัดลำดับหมวดความเสี่ยง ไม่ใช่ checklist ที่ทำครบแล้วรับรองความปลอดภัย ใช้คู่ threat modeling, ASVS/ข้อกำหนด, secure SDLC, testing และ operation controls. ข้อมูลเดิมอาจถาม OWASP Top 10:2021 ซึ่งลำดับคือ Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, SSRF ต้องดู “ปี” ในกรณีศึกษาก่อนตอบ

Web Vulnerabilities: แยก Source, Sink และ Control ให้ตรงบริบท
SQL/NoSQL/OS/LDAP Injection
เกิดเมื่อ: untrusted input ประกอบภาษาคำสั่ง; การป้องกันหลัก: parameterized API/structured query, allowlist, least privilege; escaping อย่างเดียวเปราะ
Stored/Reflected XSS
เกิดเมื่อ: ข้อมูลไม่เชื่อถือออกสู่ HTML/attribute/URL/JS context; การป้องกันหลัก: framework auto-escape + context-aware encoding, sanitize เฉพาะ rich HTML, CSP defense-in-depth
DOM XSS
เกิดเมื่อ: client source ไหลเข้าสู่ DOM/code sink เช่น innerHTML/eval; การป้องกันหลัก: safe DOM API, avoid dangerous sink, sanitize Trusted Types/CSP ตามระบบ
CSRF
เกิดเมื่อ: browser แนบ ambient credential กับ request ที่ attacker ชักนำ; การป้องกันหลัก: anti-CSRF token, SameSite, origin checks, no unsafe GET, re-auth high risk
IDOR/BOLA
เกิดเมื่อ: ใช้ object ID จาก client โดยไม่ตรวจสิทธิ์ resource instance; การป้องกันหลัก: object-level authorization + tenant/ownership filter every access
SSRF
เกิดเมื่อ: server fetch URL/host ที่ผู้ใช้ควบคุม; การป้องกันหลัก: destination allowlist, resolve/redirect/IP validation, egress network policy, block metadata/internal ranges
Path traversal
เกิดเมื่อ: input ประกอบ filesystem path แล้วหนีฐาน; การป้องกันหลัก: server-generated mapping, canonicalize แล้วตรวจ base, allowlist, least filesystem privilege
Unsafe deserialization
เกิดเมื่อ: deserialize type/object graph ที่ไม่เชื่อถือ; การป้องกันหลัก: simple schema formats, type allowlist, integrity, no native object deserialization จาก untrusted
Command execution/template injection
เกิดเมื่อ: input เข้าสู่ shell/eval/template expression; การป้องกันหลัก: ไม่เรียก shell, fixed command+arg API, sandbox/allowlist, no dynamic evaluation
Open redirect
เกิดเมื่อ: redirect target จาก input ไม่ตรวจ; การป้องกันหลัก: relative target/allowlist, server mapping, warning external link
Clickjacking
เกิดเมื่อ: หน้า sensitive ถูก frame หลอก click; การป้องกันหลัก: CSP frame-ancestors และ UI confirmation ตามความเสี่ยง
Mass assignment
เกิดเมื่อ: bind request ทุก field เข้าสู่ model; การป้องกันหลัก: DTO/allowlist writable fields + server-owned value
Race/business logic abuse
เกิดเมื่อ: หลาย request/replay ข้าม invariant/limit; การป้องกันหลัก: transaction/unique constraint/idempotency/locking/rate/state machine

Input validation ตรวจว่าข้อมูลอยู่ใน domain; output encoding ทำให้ข้อมูลไม่กลายเป็น code ใน output context; sanitization ยอมให้ subset ของ markup; parameterization แยก query code กับ values—ไม่ใช่คำเดียวแทนกัน

Security Headers, TLS, Secrets และ Data Protection
Content-Security-Policy
หน้าที่/ข้อควรจำ: จำกัดแหล่ง content/script/connect/frame; nonce/hash และลด unsafe-inline; report ช่วย tune แต่ CSP ไม่แทนแก้ XSS
Strict-Transport-Security
หน้าที่/ข้อควรจำ: บอก browser ใช้ HTTPS ต่อ host ตามเวลา; deploy/subdomain/preload ต้องวางแผน
X-Content-Type-Options: nosniff
หน้าที่/ข้อควรจำ: ลด MIME sniffing บางบริบท
frame-ancestors
หน้าที่/ข้อควรจำ: CSP directive คุมว่าใคร frame หน้าได้; ทดแทน/เหนือกว่า X-Frame-Options ในแนวทางปัจจุบัน
Referrer-Policy
หน้าที่/ข้อควรจำ: จำกัดข้อมูล URL/referrer ที่ส่งข้ามปลายทาง
Permissions-Policy
หน้าที่/ข้อควรจำ: จำกัด browser features/embedded origins
CORS headers
หน้าที่/ข้อควรจำ: อนุญาต browser origin อ่าน response; กำหนดแคบและ Vary: Origin เมื่อ dynamic
Secret management
หน้าที่/ข้อควรจำ: ไม่ฝังใน source/image/client bundle/log; ใช้ secret store, short-lived identity, rotate/audit
Encryption in transit
หน้าที่/ข้อควรจำ: TLS ระหว่างทุก trust boundary ตาม threat; validate peer/hostname
Encryption at rest
หน้าที่/ข้อควรจำ: disk/database/object/key ตาม classification; key แยกและ lifecycle ชัด
Password storage
หน้าที่/ข้อควรจำ: salted adaptive password hashing เช่น Argon2id/bcrypt/scrypt ตาม policy—not reversible encryption หรือ plain hash
Sensitive data
หน้าที่/ข้อควรจำ: เก็บเท่าจำเป็น, retention/delete, mask log, minimize response/cache, privacy access

Frontend bundle และ environment ที่ฝังตอน build ถูกผู้ใช้ดาวน์โหลดได้ จึงไม่มี “secret ฝั่ง frontend” API key ที่เปิดเผยต้องถูกออกแบบเป็น public identifier พร้อม restriction ไม่ใช่ credential ที่เชื่อถือ

File Upload, Download และ Content Handling
Size/count/time
แนวทาง: จำกัดหลายชั้นและ stream แทนโหลดทั้งไฟล์เข้าหน่วยความจำ
Filename/path
แนวทาง: สร้างชื่อ storage เอง; เก็บ original เป็น metadata ที่ encode; ป้องกัน traversal/overwrite
Type
แนวทาง: allowlist extension + inspect signature/content; Content-Type จาก client เชื่อไม่ได้
Malware/active content
แนวทาง: scan/sandbox/quarantine; แยก domain/storage; หลีกเลี่ยง inline execution
Image/document transform
แนวทาง: ใช้ patched parser, resource limit และ strip metadata ตาม policy
Authorization
แนวทาง: ตรวจ upload/read/delete ต่อ owner/tenant; signed URL อายุสั้นและ scope จำกัด
Serving headers
แนวทาง: Content-Disposition, correct Content-Type, nosniff และ CSP/sandbox ตามชนิด
Archive
แนวทาง: จำกัด expanded size/file count/path และ recursion ป้องกัน zip bomb/slip
Cleanup
แนวทาง: จัดการ partial/orphan/temp และ retention ด้วย job ที่ idempotent
Audit
แนวทาง: บันทึก actor/object/result โดยไม่เก็บ sensitive content ใน log

การเปลี่ยนชื่อไฟล์อย่างเดียวไม่ทำให้ไฟล์ปลอดภัย และ antivirus อย่างเดียวไม่ครอบ parser exploit, active HTML/SVG, authorization หรือ resource exhaustion

Software Supply Chain และ Secure SDLC

  1. 1กำหนด security/privacy requirements และ data classification
  2. 2ทำ threat model/abuse case ที่ architecture
  3. 3เลือก/ตรวจ dependency และ provenance
  4. 4secure coding + review + secret scanning
  5. 5SAST/SCA/IaC/container/DAST ตามชั้น
  6. 6signed/immutable artifact และ protected pipeline
  7. 7deploy แบบ least privilege + policy
  8. 8monitor/alert/patch/incident response
  9. 9เรียนรู้และปรับ control
Dependency
ใช้เท่าจำเป็น, pin/lock, update ที่ทดสอบ, track transitive และ vulnerability reachability
SBOM
บัญชี component/version/provenance ช่วยตอบ incident; ไม่รับรองว่าปลอดภัย
CI identity
short-lived scoped credential; branch/review protection และแยก untrusted build
Artifact
build reproducible เท่าที่ทำได้, hash/sign/attest และ promote artifact เดิม
Environment
แยก dev/test/prod account/data/secret/network; production change audit
Patch
inventory + severity/exposure/exploitability + owner/SLA + verify remediation
Third party script
ลดจำนวน, CSP/SRI เมื่อเหมาะ, consent/privacy และ outage/failure behavior
Incident readiness
runbook, contact, backup/forensic logs, revoke/rotate และ tabletop exercise
WCAG 2.2 และ Accessibility
Perceivable
ความหมาย: ผู้ใช้รับรู้ข้อมูลได้หลายรูปแบบ; ตัวอย่าง: text alternative, captions, contrast, reflow/zoom
Operable
ความหมาย: ควบคุมได้รวม keyboard/assistive input; ตัวอย่าง: focus visible/order, no keyboard trap, target size, timing control
Understandable
ความหมาย: เนื้อหา/navigation/input คาดเดาและแก้ผิดได้; ตัวอย่าง: label/instruction, consistent navigation, error identification/suggestion
Robust
ความหมาย: markup/name-role-value ทำงานกับ user agents/assistive tech; ตัวอย่าง: semantic HTML, valid relationships, status message
ระดับความหมายในการอ้าง conformity
Aเกณฑ์พื้นฐานที่ต้องผ่านทั้งหมดสำหรับระดับ A
AAผ่าน A และ AA; เป้าหมายนโยบายที่ใช้บ่อยแต่ต้องดูข้อกำหนดจริง
AAAผ่าน A+AA+AAA; W3C ไม่แนะนำให้บังคับ AAA ทั้งไซต์เป็นนโยบายทั่วไปเพราะบาง content ทำไม่ได้
  • ใช้ native semantic element และ accessible name ที่ถูกก่อน ARIA
  • ทดสอบ keyboard-only, focus, screen reader อย่างน้อยชุดตัวแทน, zoom/reflow, contrast และ automated scan
  • Automated tool จับได้เพียงบางปัญหา ต้องมี manual/user testing
  • Placeholder ไม่แทน label และสีอย่างเดียวไม่ควรเป็นสัญญาณเดียว
  • Dynamic update ต้องจัด focus/status announcement อย่างเหมาะสม
  • Accessibility เป็น requirement ตั้งแต่ design system/content/code/test ไม่ใช่งานท้ายโครงการ
Performance: วัดก่อนแก้และมองทั้ง User journey
Network
สิ่งที่วัด/แก้: DNS/TLS/TTFB, compression, cache, request count/priority และ payload
Loading
สิ่งที่วัด/แก้: critical resources, image/font strategy, code splitting, lazy load ตาม viewport/intent
Main thread
สิ่งที่วัด/แก้: long task, JS parse/execute, render/layout/paint และ third-party script
Responsiveness
สิ่งที่วัด/แก้: input/event handler, async work, scheduler, worker และ optimistic UI พร้อม rollback
Visual stability
สิ่งที่วัด/แก้: จองขนาด media/ad/dynamic content และหลีกเลี่ยงแทรกเหนือ content
Backend
สิ่งที่วัด/แก้: latency percentile, query/N+1, connection pool, cache hit, queue/dependency
Capacity
สิ่งที่วัด/แก้: throughput/concurrency/resource saturation และ overload behavior
Real user
สิ่งที่วัด/แก้: distribution ตาม device/network/region/route—not ค่าเฉลี่ย lab อย่างเดียว
Budget
สิ่งที่วัด/แก้: กำหนด budget ขนาด/เวลา/error และตรวจใน CI/monitoring ตามเหตุผล

Optimization ที่ถูกต้องเริ่มจาก user-impacting bottleneck และ profile/traces ก่อน เช่น ลด N+1 อาจคุ้มกว่าบีบ CSS เล็กน้อย ขณะที่ cache ที่ผิดอาจเร็วแต่คืนข้อมูลผิดหรือรั่ว

Testing Strategy และ Test pyramid ที่ไม่ตายตัว
Static/type/lint
ตรวจอะไร: syntax/type/rule/unsafe pattern เร็ว; ข้อจำกัด: ไม่พิสูจน์ runtime/integration ทั้งหมด
Unit
ตรวจอะไร: function/class/domain rule แยก dependency; ข้อจำกัด: mock มากอาจพิสูจน์ implementation ไม่ใช่ behavior
Component
ตรวจอะไร: UI/component + interaction/accessibility ในขอบเขต; ข้อจำกัด: browser/layout/network จริงอาจต่าง
Integration
ตรวจอะไร: module + DB/queue/service adapter จริง; ข้อจำกัด: setup/data/isolation ช้ากว่า
Contract
ตรวจอะไร: consumer-provider/schema/compatibility; ข้อจำกัด: ไม่แทน end-to-end/business journey
End-to-end
ตรวจอะไร: critical journey ผ่านระบบ; ข้อจำกัด: ช้า/flaky/diagnose ยาก จึงเลือก critical flow
Security
ตรวจอะไร: threat test, SAST/SCA/DAST/manual/penetration ตามความเสี่ยง; ข้อจำกัด: tool เดียวไม่ครอบ business logic
Performance
ตรวจอะไร: load/stress/spike/soak/capacity และ SLO; ข้อจำกัด: environment/data/workload ต้องสมจริง
Resilience
ตรวจอะไร: dependency failure, timeout, retry, failover/chaos; ข้อจำกัด: ต้องมี guardrail และ recovery
Accessibility
ตรวจอะไร: automated + keyboard + assistive technology + user test; ข้อจำกัด: automation alone ไม่พอ

Test pyramid เป็น heuristic: มี test เร็ว/เสถียรฐานกว้างและ end-to-end เฉพาะคุณค่า แต่สัดส่วนขึ้นกับ architecture/risk หลีกเลี่ยง ice-cream cone ที่ manual/E2E แพงและ feedback ช้า

องค์ประกอบ Test ที่เชื่อถือได้

  • deterministic เท่าที่ทำได้
  • data/environment แยก
  • assert behavior/contract
  • failure message วินิจฉัยได้
  • ไม่ใช้ sleep แทน condition
  • เก็บ artifact/log/trace เมื่อ fail
  • flaky test มี owner และแก้ ไม่กด rerun จนผ่าน
Observability, Logging และการวินิจฉัย
Metrics
ตอบคำถาม: แนวโน้ม/อัตรา/การกระจายเป็นอย่างไร; หลักออกแบบ: counter/gauge/histogram, label cardinality จำกัด, RED/USE ตามชั้น
Logs
ตอบคำถาม: เกิด event/decision อะไรพร้อม context; หลักออกแบบ: structured, timestamp, level, service/version, request/trace ID; redact secret/PII
Traces
ตอบคำถาม: request ข้าม service ใช้เวลาที่ไหน; หลักออกแบบ: propagate context, span boundary/attributes/error และ sampling
Events/audit
ตอบคำถาม: ใครทำอะไรกับ resource เมื่อใดและผลอะไร; หลักออกแบบ: tamper-aware, retention/access และแยกจาก debug log
Profiles
ตอบคำถาม: CPU/memory/allocation/lock hotspot อยู่ไหน; หลักออกแบบ: เก็บอย่างปลอดภัยและสัมพันธ์เวอร์ชัน/workload
Real-user telemetry
ตอบคำถาม: ผู้ใช้จริงเจอ latency/error/UX ใด; หลักออกแบบ: privacy/consent/sampling และ session correlation ตามนโยบาย
SLI
ความหมาย: ตัวชี้วัดบริการ เช่น success rate/latency/freshness/correctness
SLO
ความหมาย: เป้าหมายระดับบริการในช่วงเวลา
SLA
ความหมาย: ข้อตกลงที่อาจมีผลทางธุรกิจ/กฎหมาย ไม่เท่ากับ SLO
Error budget
ความหมาย: ส่วนความไม่น่าเชื่อถือที่ยอมได้จาก SLO ใช้คุมสมดุล change/reliability
Alert
ความหมาย: แจ้งอาการที่ต้อง action โดยมี owner/severity/runbook; หลีกเลี่ยง alert noise
Incident
ความหมาย: detect→triage→contain→mitigate/recover→communicate→learn
Post-incident review
ความหมาย: blameless เชิงระบบ พร้อม action/owner/due/verification

Log ที่ดีไม่ควรบันทึกรหัสผ่าน token session ID เต็ม ข้อมูลส่วนบุคคลเกินจำเป็น หรือ stack trace ต่อผู้ใช้ การ mask ต้องทำก่อนออกจาก trust boundary

CI/CD, Deployment และ Database Change

  1. 1commit ผ่าน review/policy
  2. 2build ครั้งเดียวใน clean environment
  3. 3unit/static/security/dependency test
  4. 4package immutable artifact + provenance
  5. 5integration/contract/E2E ตาม risk
  6. 6deploy พร้อม config/secret แยก
  7. 7health/smoke/telemetry/guardrail
  8. 8promote/canary/rollback หรือ roll-forward
  9. 9บันทึก release และเรียนรู้
Rolling
แก่น/ข้อควรระวัง: แทน instance ทีละส่วน; ต้อง backward-compatible ระหว่างหลายเวอร์ชัน
Blue–green
แก่น/ข้อควรระวัง: สอง environment สลับ traffic; rollback เร็วแต่ data/schema state ยังต้องคิด
Canary
แก่น/ข้อควรระวัง: ส่ง traffic ส่วนน้อยแล้ววัด guardrail ก่อนขยาย
Feature flag
แก่น/ข้อควรระวัง: แยก deploy จาก release และทดลองกลุ่ม
Shadow
แก่น/ข้อควรระวัง: สำเนา traffic ให้ระบบใหม่โดยไม่ตอบผู้ใช้
Rollback
แก่น/ข้อควรระวัง: ย้อน artifact/config ได้
Roll-forward
แก่น/ข้อควรระวัง: แก้ version ใหม่เมื่อ rollback เสี่ยง
Expand
ตัวอย่าง: เพิ่ม schema/API แบบ compatible เช่น nullable column/dual-read support
Migrate
ตัวอย่าง: deploy code ที่รองรับสองแบบ, backfill/dual-write อย่างระวัง, verify
Contract
ตัวอย่าง: หลังทุก consumer ย้าย จึงลบ field/table/old path
หลัก
ตัวอย่าง: migration idempotent/resumable, lock/time/resource limit, backup/recovery และ monitoring
Container, Cloud และ Shared Responsibility
Image
ความหมาย/หลัก: immutable filesystem/package template; scan/minimize/pin base และไม่ใส่ secret
Container
ความหมาย/หลัก: process isolation บน host kernel—not VM เต็ม; ตั้ง non-root, resource limit, read-only ตามได้
Orchestrator
ความหมาย/หลัก: schedule, service discovery, rollout, health, autoscale/config secret integration
VM
ความหมาย/หลัก: virtualized machine/OS แยกกว่าแต่หนักกว่า
IaaS
ความหมาย/หลัก: ผู้ใช้ดู OS/runtime/app/data มาก; provider ดู physical/virtual infrastructure
PaaS
ความหมาย/หลัก: provider ดู OS/runtime/platform มากขึ้น; ผู้ใช้ยังดู app/config/data/identity
SaaS
ความหมาย/หลัก: provider ดำเนิน application; ลูกค้ายังรับผิด account/access/config/data use/integration
Managed database/cache/queue
ความหมาย/หลัก: ลดงาน operation บางส่วน ไม่ย้าย ownership ของ schema/query/access/backup objective ทั้งหมด
Autoscaling
ความหมาย/หลัก: เพิ่ม/ลด instance ตาม signal; ไม่แก้ slow dependency/data contention และมี lag/cost
Infrastructure as Code
ความหมาย/หลัก: version/review/repeatable environment; ต้อง scan drift/secret/state และ protect apply

Cloud ไม่ทำให้ระบบ secure/highly available อัตโนมัติ ต้องออกแบบ region/zone/failure domain, identity/network/data protection, backup/restore, quota/cost และ exit/recovery ตาม requirement

อ่านสรุปฉบับเต็มทุกหัวข้อ
สมาชิก PRO ระบบจะจำหัวข้อที่อ่านค้างไว้ให้ด้วย
PRO 99 บาท/เดือน

เนื้อหาสรุปนี้จัดทำขึ้นเพื่อการศึกษาส่วนบุคคล ห้ามคัดลอก ทำซ้ำ หรือนำไปใช้เพื่อวัตถุประสงค์ทางการค้าโดยไม่ได้รับอนุญาต