บทเรียน 11 — เลือกบริการ Cloudflare ให้เหมาะกับเว็บไซต์
สถานะ: บทอ่าน/ฝึกเสริมหลังชั้นเรียน ไม่เพิ่มจากหลักสูตร 2 วัน × วันละ 4 ชั่วโมง
เวลาแนะนำ: 60–90 นาที · ตรวจข้อมูลทางการ: 11 กันยายน 2026
เว็บไม่ได้ดีขึ้นเพราะเปิดทุกบริการของ Cloudflare เป้าหมายของบทนี้คือเลือกเพียงสิ่งที่ตอบโจทย์ผู้ใช้ ข้อมูล และการปฏิบัติการของเว็บเราได้จริง แล้วเขียนเหตุผลกับหลักฐานว่าจะตรวจอย่างไร บท 08 คือเส้นทาง deploy Worker + Static Assets + D1 ของโปรเจกต์หลัก; บทนี้เป็นแผนที่ก่อนตัดสินใจเพิ่มความสามารถ
ผลลัพธ์การเรียนรู้
เมื่อจบ ผู้เรียนสามารถ
- เลือก starting stack ที่เล็กที่สุดสำหรับเว็บบริษัท เว็บ catalog/เช่า และแอปที่ต้อง login
- แยก D1, KV, R2 และ Durable Objects ตามชนิดข้อมูลและความสอดคล้องที่ต้องการ
- แยกการป้องกัน form, back office และ edge security ว่าแก้คนละปัญหา
- วางงานนอก request ด้วย Queue, Cron หรือ Workflow โดยไม่เรียกมันว่า “เร็วขึ้น” โดยไม่มีหลักฐาน
เริ่มจาก service พื้นฐาน ไม่ใช่จาก product catalog
| ต้องการของเว็บไซต์ | เริ่มต้นที่ | ใช้เมื่อ | ยังไม่ต้องเพิ่มเมื่อ |
|---|---|---|---|
| ชื่อโดเมน, DNS, HTTPS | DNS + SSL/TLS | จะใช้ custom domain | ยังไม่มี domain หรือกำลังทำ local prototype |
| หน้า static, SPA หรือ API/SSR เล็ก ๆ | Workers Static Assets + Workers | เว็บใหม่ทุกแบบที่ต้อง deploy | หน้า static ไม่ต้องเขียน Worker script เพียงตั้ง assets.directory ก็ได้ |
| ไฟล์ CSS/JS/ภาพที่ public | Static Assets + Cache/CDN | build ได้ dist/ |
ไม่ต้องตั้ง Cache Rule เองก่อนรู้ว่า response ใด public/immutable |
| ข้อมูลตารางสัมพันธ์กัน | D1 | product, order, booking, form submissions | เป็น config/read cache หรือ file binary |
| config ที่อ่านบ่อย | KV | feature setting, locale, cached read model | ต้อง update+read ทันทีหรือ atomic counter |
| อัปโหลด, PDF, original image | R2 | เก็บ object/file แยกจาก database | ต้อง resize/serve image variants สำเร็จรูป |
| คนหลายคนแก้ state เดียวกัน | Durable Objects | ห้องแชต, cart ต่อคน, stock/slot ต่อ resource | CRUD ปกติที่ D1 ดูแลได้ |
Cloudflare แนะนำ Workers Static Assets สำหรับ static site, SPA และ full-stack app ที่เริ่มใหม่; assets และ code deploy เป็น operation เดียวและมี cache สำหรับ static asset ให้. Workers best practices · Static Assets
Cloudflare Pages ยังใช้งานได้และมี Git integration กับ preview deployment แต่เอกสาร Pages ปัจจุบันระบุให้เริ่มโปรเจกต์ใหม่ด้วย Workers เพราะ feature ใหม่เน้นที่ Workers. จึงอย่าย้าย Pages ที่ทำงานอยู่เพียงเพื่อให้ “ใหม่” และอย่าเริ่มบริการทั้งสองสำหรับเว็บเดียวโดยไม่มีเหตุผล. Pages getting started
รากฐานของ public website
DNS ทำให้ hostname ชี้ไปยังบริการที่ถูกต้อง; SSL/TLS เข้ารหัส traffic ระหว่างผู้ชมกับเว็บไซต์. Universal SSL ออก certificate ที่ edge ให้โดยอัตโนมัติ แต่สำหรับเว็บที่มี origin เองยังต้องตรวจ encryption mode และ certificate ฝั่ง origin ด้วย. DNSSEC, redirect to HTTPS และ cache rules เป็นการตั้งค่าที่มีผลต่อ public traffic จึงต้องอ่าน current record/owner และมีแผน rollback ก่อนแก้. DNS · SSL/TLS · Cache/CDN
เลือกที่เก็บข้อมูลจากพฤติกรรม ไม่ใช่จากชื่อ
D1 เป็น managed serverless SQL ที่ใช้ SQLite semantics และเชื่อมจาก Worker ผ่าน binding. เริ่มด้วย schema และ migration หากข้อมูลมี relation เช่น product → order หรือ equipment → reservation; ใช้ prepared statements และตรวจ input ก่อนเขียน. D1 overview · D1 query guidance
KV เหมาะกับค่าที่อ่านมากและเปลี่ยนน้อย เช่น site configuration, language preference หรือ cache. KV เป็น eventually consistent: ค่าที่เพิ่งเปลี่ยนอาจใช้ 60 วินาทีหรือมากกว่านั้นจึงเห็นใน location อื่น จึงห้ามใช้เป็นหลักฐานว่า stock ยังเหลือหรือการจองสำเร็จ. How KV works
R2 เก็บ object เช่น รูปต้นฉบับ, PDF และไฟล์ upload; operations ของ object และ listing มี strong consistency. นั่นไม่ทำให้ R2 เป็น relational database: เก็บ metadata/สิทธิ์/ความสัมพันธ์ใน D1 แล้วให้ Worker ตรวจสิทธิ์ก่อนส่ง object ที่ไม่ public. R2 consistency
Durable Objects (DO) มี compute กับ storage ที่ transactional/strongly consistent ต่อ object เดียว เหมาะเมื่อหลาย request ต้องประสาน state เดียวกัน เช่น slot การเช่าต่ออุปกรณ์, room chat หรือ cart ต่อ session. อย่าเพิ่ม DO เพียงเพราะทุกโปรเจกต์มี “real time”; เริ่ม D1 ถ้าโจทย์เป็น CRUD ปกติ และพิสูจน์ concurrency requirement ก่อน. What are Durable Objects?
งานที่ไม่ควรทำค้างใน HTTP request
| สถานการณ์ | เลือก | ตัวอย่าง | ต้องออกแบบเพิ่ม |
|---|---|---|---|
| ส่ง event แล้วให้ทำทีหลัง | Queues | contact accepted → ส่งแจ้งทีม/สร้าง thumbnail | retry, idempotency, dead-letter และการมองเห็น failure |
| งานหลายขั้นที่ต้องพักหรือรอ approval | Workflows | upload → scan → ขออนุมัติ → publish | state/compensation และ UI บอกสถานะผู้ใช้ |
| งานซ้ำตามเวลา UTC | Cron Trigger | cleanup demo data, refresh catalog | เวลา UTC, handler ที่ idempotent และการตรวจ propagation |
Queues รองรับ batch/retry/delay/dead-letter queues; Workflows เก็บ state ของหลาย step และ retry/pause ได้; Cron เรียก scheduled() ตาม UTC และการแก้ trigger อาจใช้เวลาสักพักก่อนกระจายทั่ว network. Queues · Workflows · Cron Triggers
Media, email และ AI เป็นความสามารถเสริมตามงาน
ใช้ Cloudflare Images เมื่อเว็บต้อง serve ภาพหลายขนาด/format และจัดการ variant; ใช้ R2 เมื่อเป็น file/object ทั่วไปหรือคุณต้องสร้าง policy เอง; ใช้ Stream เมื่อรับ/encode/deliver วิดีโอ. อย่าใส่ video หรือ image ต้นฉบับขนาดใหญ่ใน repository/build bundle. Images · R2 · Stream
Email Routing คือ inbound mail: ส่ง mail ไป verified address หรือ Worker. Email Sending คือ outbound transactional email, อยู่ในสถานะ Beta และต้องใช้ Workers Paid plan ตามเอกสารปัจจุบัน. แยกสองงานนี้ออกจากกัน และตรวจ plan, sending domain, limits กับเอกสารล่าสุดก่อนเปิด production; credential และ API key ต้องอยู่ใน secret binding ไม่ใช่ prompt, Git หรือ browser log. Email Service · Email Routing
Workers AI, Vectorize และ AI Gateway ใช้ได้เมื่อเว็บมี use case ชัด เช่น assistant ที่ตอบจากเอกสารที่อนุญาต, semantic search หรือควบคุม/สังเกตการเรียก model หลาย provider. มันไม่ใช่ requirement ของเว็บบริษัททุกเว็บ: ระบุ source of truth, สิทธิ์เข้าถึง, fallback เมื่อ AI ผิด และตรวจ pricing/limits ก่อนเปิดใช้. Workers AI · Vectorize · AI Gateway
| บริการ AI | ทำหน้าที่อะไรในเว็บ | ตัวอย่าง |
|---|---|---|
| Workers AI | เรียกใช้โมเดล AI ที่ Cloudflare ให้บริการ | สร้างคำตอบหรือ embedding ตามโมเดลที่เลือก |
| Vectorize | เก็บและค้นหา vector เพื่อหาข้อมูลที่มีความหมายใกล้กัน | ค้นย่อหน้าในคู่มือสินค้าก่อนให้โมเดลตอบ |
| AI Gateway | เป็นทางผ่านเพื่อจัดการและติดตามการเรียก AI provider | ตรวจ usage/error และกำหนด cache หรือ rate limit ของการเรียกโมเดล |
การใช้ GPT Image ผ่าน Codex ใน Lab RW Web เป็นขั้นสร้าง asset ระหว่างพัฒนาเว็บ ส่วน Cloudflare Images ช่วยจัดการและส่งภาพไปยังผู้ชมเมื่อเว็บไซต์ทำงาน ภาพที่สร้างและปรับขนาดไว้แล้วสามารถเริ่มจาก Static Assets ได้โดยไม่ต้องเปิดบริการ AI ในเว็บไซต์
ความปลอดภัย: เลือก control ให้ตรงภัยคุกคาม
| สิ่งที่ป้องกัน | เครื่องมือ | ข้อจำกัดที่ต้องจำ |
|---|---|---|
| SQL injection, invalid booking, price tampering | validation + authorization ใน Worker และ D1 constraints | WAF/Turnstile ไม่รู้ business rule แทน code ของเรา |
| bot/spam form | Turnstile + server-side Siteverify + rate policy | token browser ต้อง validate ที่ server และไม่ควร log token/form body |
| exploit/web attack pattern | WAF | review rule/false positive และอย่าเปิด rule โดยไม่ทดสอบ route สำคัญ |
| volumetric DDoS | DDoS protection ที่ edge | ไม่แก้ logic bug หรือ authorization ที่ผิด |
| admin, CMS, preview สำหรับทีม | Cloudflare Access | เป็น gateway identity-aware; ไม่แทน authorization ต่อ resource ของ user ใน app public |
Turnstile กำหนดให้ server-side validation; Access เหมาะกับการกันหน้า back office/preview แบบ deny-by-default policy. WAF และ DDoS เป็นชั้นเสริมที่ edge. อ่าน implementation จริงและสร้าง credential ตาม Lab Wrangler authentication; Access service token ไม่ใช่ API token สำหรับ deploy. Turnstile Siteverify · WAF · DDoS protection · Access HTTP apps
สี่ architecture เริ่มต้น
| เว็บ | Stack เริ่มต้น | เพิ่มเมื่อมีหลักฐาน | ยังไม่ต้องใช้ |
|---|---|---|---|
| บริษัท/portfolio | Workers Static Assets, DNS/SSL เมื่อมี domain, Web Analytics | Turnstile เมื่อมี form, Images เมื่อมีภาพหลาย variant | D1, queue, AI, login ถ้าไม่มี user task รองรับ |
| catalog/สินค้าแต่ยังไม่ checkout | Static Assets เมื่อข้อมูลอยู่ใน content files ของเว็บ | Worker API + D1 เมื่อมี admin/ข้อมูลที่แก้ระหว่างใช้งาน/รายการถาวร; R2/Images เมื่อมี upload หรือ image variants | database สำหรับ catalog ที่ build จากไฟล์ได้; DO และ payment จนมี transaction requirement |
| เช่า/booking | Static Assets + Worker + D1 | DO ต่อ resource เมื่อพิสูจน์ race/concurrency, Queue สำหรับ notification | KV เป็น authority ของ availability |
| แอปสมาชิก/back office | Worker + D1 + Access สำหรับ staff area | R2 uploads, Queue/Workflow สำหรับงานยาว, Observability | Access เป็นสิทธิ์ลูกค้าต่อ record; ต้องมี app authorization เพิ่ม |
วัดผลและดูแลหลัง deploy
เปิด Web Analytics เพื่อดู performance ที่ผู้เยี่ยมชมพบและ Core Web Vitals โดยเน้น privacy. สำหรับ backend ใช้ Workers Observability เพื่อดู metrics, errors, logs และ real-time debug; log เฉพาะ request ID/route/status/error code ห้ามบันทึก token, cookie, secret หรือ PII โดยไม่จำเป็น. Web Analytics · Workers Observability
ก่อนเปิดบริการแบบมีค่าใช้จ่ายหรือ quota ให้เปิดหน้า Pricing และ Limits ของ service นั้นในวัน deploy, ตรวจ plan/account/permission, แล้วบันทึกวันที่และสิ่งที่ตรวจไว้ใน handoff. เอกสารนี้ไม่ fix ราคาและโควตา เพราะเปลี่ยนได้. การผ่าน wrangler deploy --dry-run ยังไม่พิสูจน์ DNS, custom domain, TLS, database binding หรือ public user flow; ทำตาม release evidence ใน บท 08 และ บท 09.
Lab สั้น: ออกแบบก่อนเปิด service
เริ่มด้วย prompt แบบอ่านอย่างเดียวนี้ ยังไม่ login, deploy, สร้าง resource หรือเปลี่ยน DNS:
อ่าน brief, sitemap, data model, wrangler config และผลทดสอบของเว็บไซต์นี้
สร้าง docs/cloudflare-service-decision.md ที่มีตาราง requirement → Cloudflare service (หรือ “ไม่ต้องใช้”) → เหตุผล → data/consistency ที่ต้องการ → security/permission → วิธีทดสอบ → cost/limit page ที่ต้องตรวจในวัน deploy
เสนอ starting stack ที่เล็กที่สุด และทางเลือกเมื่อ traffic, upload, concurrency หรือ background job เกิดขึ้นจริง
ห้ามสร้าง Cloudflare resource, login, deploy, แก้ DNS/route/domain, อ่านหรือแสดง secret/token
รายงานข้อเท็จจริงที่ยังขาดเป็นคำถาม/assumption แยกจากข้อเสนอ
เมื่อ requirements ชัดและเจ้าของ account อนุญาตการเปลี่ยนแปลง ใช้ prompt implementation นี้:
จาก docs/cloudflare-service-decision.md ให้ทำเฉพาะ service ที่มี requirement และ acceptance test รองรับ
ก่อนเปลี่ยน remote resource ให้แสดง target: account, Worker/project, zone, hostname, existing bindings/records และผลกระทบ
สร้าง/แก้เฉพาะ config, migration, binding และ test ที่จำเป็น; เก็บ secret ด้วย Wrangler secret workflow ไม่พิมพ์ค่า
ห้ามเพิ่ม service เพียงเพื่อความครบ, ห้ามแก้ record/domain ของเว็บไซต์อื่น, และหยุดถ้า account/zone/owner ไม่ตรง
หลัง deploy ตรวจ HTTPS, expected content และ flow ที่เกี่ยวข้อง พร้อมบันทึก URL, version, เวลา, output ที่ redact แล้ว และสิ่งที่ยังไม่พิสูจน์
สิ่งที่ส่ง
cloudflare-service-decision.mdที่มี starting stack และสิ่งที่เลือกไม่ใช้พร้อมเหตุผล- architecture หนึ่งแบบจากตารางข้างต้น พร้อม data authority และ security boundary
- acceptance check อย่างน้อย 5 ข้อ เช่น HTTPS/content, invalid form ไม่เขียน D1, upload authorization, queue retry หรือ Access allowed/denied ตามสิ่งที่เลือก
- pricing/limits/permission snapshot ที่ระบุวันที่ตรวจ โดยไม่มี token, account secret หรือ PII
คู่มือแหล่งข้อมูล
ใช้ research: Cloudflare website services เพื่ออ่านหลักฐานฉบับย่อและลิงก์ทางการทั้งหมด. ข้อมูล product/plan/limits เปลี่ยนได้ จึงใช้หน้านี้เป็นแผนที่และตรวจ docs ทางการอีกครั้งก่อน implementation หรือ production deployment.