Project 2: Waitlist App ที่เริ่มมี Database | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand
$ cat 07-project-waitlist-supabase.md บทที่ 7
Project 2: Waitlist App ที่เริ่มมี Database แก่นของบทนี้
บทที่แล้วเราสร้าง landing page ที่ยังไม่ต้องมี database จริง
บทนี้เราจะเพิ่มความจริงขึ้นอีกหนึ่งขั้น:
user กรอกฟอร์ม → ข้อมูลถูกเก็บใน Supabase คัดลอก นี่คือจุดที่ vibe coding เริ่มมีความเสี่ยงมากขึ้น
เพราะเราไม่ได้แค่ทำหน้าเว็บแล้ว
เราเริ่มเก็บข้อมูลคนจริง
ดังนั้นบทนี้จะเน้น 3 เรื่อง:
เก็บข้อมูลให้น้อยที่สุด
ใช้ key ให้ถูกประเภท
เปิด database access เท่าที่จำเป็น
เป้าหมายไม่ใช่ทำระบบหลังบ้านสมบูรณ์
เป้าหมายคือทำ waitlist app version แรกที่เล็กพอ ตรวจได้ และไม่ประมาทเรื่องข้อมูล
ถ้าจะลงมือทำจริง ให้เปิด Appendix E — Supabase Waitlist Playbook คู่กับบทนี้ เพราะบทนี้อธิบายหลักคิด ส่วน Appendix E ลงรายละเอียด checklist, RLS, key และ production test
Project ที่เราจะสร้าง
เราจะต่อยอดจาก landing page เดิม
เพิ่ม form ที่เก็บข้อมูลลง Supabase
Version แรกมีแค่นี้:
form สำหรับ waitlist
field พื้นฐาน
submit ไป Supabase
success state
error state
manual test checklist
ยังไม่ทำ:
login
admin dashboard
email automation
payment
export CSV
user account
role permission ซับซ้อน
จำไว้ว่า:
แค่เก็บ lead ได้อย่างปลอดภัยพอสำหรับ version แรก ก็ถือว่า project นี้สำเร็จแล้ว
ข้อมูลที่ควรเก็บให้น้อยที่สุด ก่อนสร้าง table ให้ถามก่อนว่า “จำเป็นต้องเก็บอะไรจริง ๆ”
สำหรับ waitlist ส่วนใหญ่ เริ่มจาก field แบบนี้พอ:
name email company main_problem created_at คัดลอก เบอร์โทร งบประมาณละเอียด เอกสารบริษัท ข้อมูลลูกค้าเขา รหัสผ่าน ข้อมูลบัตรเครดิต คัดลอก ข้อมูลที่ไม่เก็บ ไม่มีวันหลุดจากระบบคุณ
นี่คือ security ที่ง่ายที่สุดสำหรับ non-coder
Spec สำหรับ Waitlist version แรก # Spec: Waitlist Form with Supabase ## Goal ให้ผู้สนใจบริการ AI Workflow Audit กรอกข้อมูลเพื่อ join waitlist หรือขอนัด consult ## Target user เจ้าของธุรกิจ SME ที่สนใจใช้ AI ลดงานซ้ำ ## Version 1 scope - เพิ่ม waitlist form บน landing page - เก็บข้อมูลลง Supabase table - แสดง success message เมื่อส่งสำเร็จ - แสดง error message เมื่อส่งไม่สำเร็จ - Validate required fields เบื้องต้น ## Out of scope - No login - No payment - No admin dashboard - No email automation - No file upload - No sensitive documents ## Data fields - name: required text - email: required text, basic email validation - company: optional text - main_problem: optional text - created_at: auto timestamp ## Acceptance criteria - Form submit แล้ว row ใหม่ถูกสร้างใน Supabase - ถ้าไม่กรอก name/email ต้องแสดง error - ถ้า email format ผิด ต้องแสดง error - ถ้า Supabase insert fail ต้องแสดง error ที่ user เข้าใจได้ - ไม่มี secret key อยู่ใน frontend code - ไม่มี `.env` หรือ `.env.local` ถูก commit - Claude สรุป manual test steps หลังทำเสร็จ คัดลอก Spec นี้เล็กพอสำหรับเริ่ม
อย่าเพิ่ม dashboard จนกว่าคุณจะมั่นใจว่าเก็บข้อมูลได้ถูกและปลอดภัยพอ
เข้าใจ Supabase แบบ non-coder สำหรับบทนี้ ให้เข้าใจ Supabase ง่าย ๆ ว่าเป็นบริการที่ช่วยให้เรามี:
database API auth storage คัดลอก แต่ project นี้ใช้แค่ database/API พื้นฐาน
ยังไม่ใช้ function ซับซ้อน
API key มีหลายประเภท อย่าสับสน เส้นแบ่งระหว่าง publishable key กับ secret key publishable key ใช้ฝั่ง browser ได้ แต่ secret/service_role ต้องไม่อยู่ใน frontend หรือ public repo
Supabase official docs แยก key หลัก ๆ เป็น publishable key และ secret key
สำหรับ non-coder ให้จำแบบนี้:
Publishable key ใช้กับส่วนที่อยู่ฝั่ง browser ได้
เช่นหน้าเว็บที่ user เปิด
มันไม่ได้เป็น “ความลับ” แบบ password
แต่การใช้ publishable key ต้องพึ่ง database policy/RLS ให้ถูก
Secret key / service role ใช้เฉพาะฝั่ง server หรือ backend ที่ปลอดภัยกว่า
ห้ามส่งใน chat แบบไม่ระวัง
ห้ามใช้ใน browser แม้จะเป็น localhost
ถ้าคุณไม่แน่ใจว่า key ไหนคืออะไร ให้หยุดและถามก่อน
Key นี้ควรอยู่ฝั่ง browser ได้ไหม หรือเป็น secret/server-only key? ถ้าเอาไปใส่ frontend จะเสี่ยงอะไร? คัดลอก
key ที่มีสิทธิ์สูง ห้ามอยู่ใน code ที่ user เปิดดูได้
Red line สำหรับ non-coder:
ถ้า Claude เสนอให้ใช้ secret key หรือ service_role เพื่อให้ form ทำงานง่ายขึ้น ให้หยุดทันที และถามหาวิธีที่ใช้ publishable key + RLS/policy ที่ถูกต้องแทน คัดลอก
Environment variables คืออะไร Environment variables แยก local กับ production .env.local อยู่ในเครื่อง ส่วน production ต้องตั้งค่าใน platform deploy และไม่ควร commit ค่า secret
เวลา app ต้องใช้ค่าอย่าง Supabase URL หรือ key เรามักเก็บใน environment variables
NEXT_PUBLIC_SUPABASE_URL= NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY= คัดลอก สำหรับ frontend บาง framework คำที่ขึ้นต้นด้วย NEXT_PUBLIC_ หมายถึงค่าที่ถูกส่งไป browser ได้
ดังนั้นอย่าใส่ secret key ในตัวแปรที่ public
ไฟล์ที่มักใช้เก็บค่าเหล่านี้คือ:
แต่ไฟล์นี้ไม่ควรถูก commit ขึ้น GitHub
ที่มีชื่อ variable แต่ไม่มีค่าจริง
NEXT_PUBLIC_SUPABASE_URL=your-project-url NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your-publishable-key คัดลอก
RLS คืออะไรแบบภาษาคน RLS สำหรับ waitlist แบบ insert-only สำหรับ waitlist แรก คนทั่วไปควร submit ได้ แต่ไม่ควรอ่าน แก้ หรือลบ lead ของคนอื่น
RLS ย่อมาจาก Row Level Security
ให้คิดว่าเป็นกติกาที่บอกว่า:
ใครอ่าน row ไหนได้ ใครเพิ่ม row ได้ ใครแก้ row ได้ ใครลบ row ได้ คัดลอก Supabase docs ระบุว่า RLS ควรเปิดบน table ที่อยู่ใน exposed schema เช่น public
สำหรับ waitlist form ที่ user ไม่ login เราอาจต้องการแค่:
anon insert ได้ anon select ไม่ได้ anon update ไม่ได้ anon delete ไม่ได้ คัดลอก
คนทั่วไปส่งข้อมูลเข้ามาได้ แต่ไม่ควรอ่านรายชื่อ lead ทั้งหมดได้
ถ้าเผลอเปิด read public คุณอาจทำให้ใครก็ได้อ่านรายชื่อ lead ได้
ขอให้ Claude อธิบาย policy ก่อนสร้าง อย่าให้ Claude สร้าง SQL policy แบบคุณไม่เข้าใจ
ฉันต้องการสร้าง Supabase table สำหรับ waitlist ผู้ใช้ทั่วไปควร submit form ได้ แต่ไม่ควรอ่าน แก้ หรือลบข้อมูลของคนอื่น ช่วยเสนอ schema และ RLS policy ก่อน กติกา: - อย่าเพิ่งรัน SQL - อธิบายเป็นภาษาคนว่า policy แต่ละอันอนุญาตอะไร - แยกสิ่งที่จำเป็นกับ optional - ถ้ามีความเสี่ยง ให้เตือน คัดลอก ถ้าคุณอ่าน policy ไม่เข้าใจ ให้ถามต่อ:
ช่วยอธิบาย policy นี้เหมือนอธิบายให้เจ้าของธุรกิจที่ไม่รู้ SQL ใครทำอะไรได้ และใครทำอะไรไม่ได้? คัดลอก อย่า approve database change ที่คุณอธิบายเองไม่ได้เลย
Step 1: สร้าง table แบบเล็กที่สุด Waitlist table schema ที่เล็กพอ เริ่มจาก field เท่าที่จำเป็นก่อน ยิ่งเก็บน้อย ยิ่งตรวจและปกป้องง่าย
Table สำหรับ version แรกอาจมีแค่นี้:
waitlist_submissions - id - name - email - company - main_problem - created_at คัดลอก ให้ Claude ช่วยเสนอ SQL ได้ แต่ให้มันอธิบายก่อน
ช่วยเสนอ SQL สำหรับ Supabase table ชื่อ waitlist_submissions fields: - id - name required - email required - company optional - main_problem optional - created_at timestamp ต้องการให้ user จากหน้าเว็บ insert ได้ แต่ไม่สามารถ select/update/delete rows ได้ กติกา: - อย่าเพิ่งรัน SQL - เสนอ SQL พร้อมคำอธิบายทีละส่วน - อธิบาย RLS policy เป็นภาษาคน - ชี้จุดที่ฉันควรตรวจใน Supabase dashboard คัดลอก ถ้า SQL ดูยาวหรือซับซ้อนเกินไป ให้ถามว่า:
มีเวอร์ชันที่ง่ายและปลอดภัยพอสำหรับ waitlist version แรกไหม? คัดลอก
หลัง table พร้อมแล้ว ค่อยให้ Claude Code ต่อ frontend
นี่คือ spec และ Supabase table ที่เตรียมไว้: [paste spec/table summary] ช่วยต่อ waitlist form ให้ submit ไป Supabase กติกา: - ใช้ publishable key เท่านั้นใน frontend - ห้ามใช้ secret key หรือ service role key ใน browser - ห้าม commit .env หรือ .env.local - ถ้าต้องเพิ่ม package ใหม่ ให้ถามก่อน - หลังทำเสร็จให้สรุปไฟล์ที่แก้และวิธี test คัดลอก ถ้า Claude ขอ key ให้คุณอย่า paste secret ลง chat แบบไม่คิด
ให้ใส่ค่าใน .env.local เอง หรือให้ Claude บอกชื่อ variable ที่ต้องใช้
Step 3: Test submit จริง Test submit จริงต้องเช็กทั้งหน้าเว็บและ Supabase การ test waitlist ต้องเช็กทั้ง state บนหน้าเว็บและ row ที่เข้า database จริง
หลังต่อ form แล้ว ให้ test แบบนี้
ให้ Claude ช่วยสร้าง manual test plan:
ช่วยสร้าง manual test plan สำหรับ waitlist form นี้ แยกเป็น: 1. happy path 2. validation errors 3. Supabase/network error 4. security checks 5. สิ่งที่ต้องดูใน Supabase dashboard คัดลอก
Step 4: ตรวจว่า secret ไม่หลุด ก่อน commit และ deploy ให้ตรวจเรื่อง secret
ช่วยตรวจ project นี้ว่ามีโอกาส secret หลุดไหม โฟกัสที่: - .env หรือ .env.local ถูก track ไหม - มี API key hard-code ใน source code ไหม - มี Supabase secret/service_role key อยู่ใน frontend ไหม - .env.example มีเฉพาะ placeholder ไหม อย่าแสดงค่าของ secret ซ้ำในคำตอบ ให้บอกแค่ว่าพบหรือไม่พบ และควรแก้อะไร คัดลอก คำว่า “อย่าแสดงค่าของ secret ซ้ำ” สำคัญ
ถ้ามี secret โผล่ใน output คุณอาจทำให้มันกระจายไปอีกที่โดยไม่ตั้งใจ
GitHub มี secret scanning เพื่อช่วยตรวจ secret leaks แต่คุณไม่ควรพึ่งระบบ scan อย่างเดียว
นิสัยที่ดีที่สุดคืออย่า commit secret ตั้งแต่แรก
Step 5: Deploy แล้ว test production ก่อน deploy จริง ให้เปิด Appendix E — Supabase Waitlist Playbook และ Appendix D — Vercel Deploy Playbook เพื่อเช็ก env var, RLS และ production test แบบไม่ข้ามขั้น
เมื่อทุกอย่างผ่านในเครื่องแล้ว ค่อย deploy
ถ้าใช้ Vercel ต้องใส่ environment variables ใน Vercel ด้วย
อย่าคิดว่าใช้ได้ในเครื่อง = ใช้ได้บน production
environment บน Vercel อาจต่างจากเครื่องคุณ
Step 6: Launch note สำหรับ waitlist หลัง deploy ให้เขียน note สั้น ๆ
# Launch Note: Waitlist v1 ## URL [production URL] ## What shipped - Waitlist form - Supabase insert - Success and error states ## Data collected - name - email - company - main_problem - created_at ## Not included - No login - No payment - No admin dashboard - No email automation ## Security assumptions - Uses publishable key in frontend - Secret/service role key is not used in browser - RLS enabled - Public users can insert only ## Manual tests done - required fields - invalid email - successful submit - production submit - mobile layout ## Known issues - [ ถ้ามี ] คัดลอก Launch note นี้ทำให้คุณรู้ว่า version นี้เก็บข้อมูลอะไรและยังไม่ทำอะไร
สำคัญมากเมื่อ project เริ่มมี data จริง
Prompt รวมท้ายบท ใช้ prompt นี้เมื่อต้องการให้ Claude Code ทำ waitlist app
ฉันต้องการเพิ่ม waitlist form ที่เก็บข้อมูลลง Supabase Spec: [paste spec] กติกาสำคัญ: - ทำเฉพาะ version 1 - ไม่มี login, payment, admin dashboard, email automation หรือ file upload - เก็บข้อมูลเท่าที่จำเป็นเท่านั้น - ใช้ publishable key ใน frontend เท่านั้น - ห้ามใช้ secret key หรือ service_role key ใน browser - ห้าม commit .env หรือ .env.local - ถ้าต้องสร้าง/แก้ RLS policy ให้เสนอและอธิบายก่อน อย่ารันเองทันที - ก่อนแก้ไฟล์ ให้เสนอ implementation plan - หลังแก้ไฟล์ ให้สรุป diff และ manual test plan Acceptance criteria: - Submit สำเร็จแล้ว row เข้า Supabase - Required fields มี validation - Error state เข้าใจง่าย - RLS เปิดและ public user อ่านข้อมูล lead ทั้งหมดไม่ได้ - ไม่มี secret หลุดใน source code คัดลอก หลังทำเสร็จ ใช้ prompt review:
ช่วย review waitlist implementation นี้ก่อน deploy ตรวจเฉพาะสิ่งสำคัญ: 1. ตรง spec ไหม 2. มี feature เกิน scope ไหม 3. เก็บข้อมูลเกินจำเป็นไหม 4. ใช้ key ถูกประเภทไหม 5. มี secret หลุดไหม 6. RLS/policy อนุญาตอะไรบ้าง อธิบายเป็นภาษาคน 7. manual test ก่อน deploy ต้องทำอะไร 8. มี risk อะไรที่ควรรู้ก่อนเปิดให้คนจริงใช้ อย่าแก้ไฟล์ก่อน รายงานก่อน คัดลอก
สรุป Waitlist app คือก้าวแรกจากหน้าเว็บธรรมดาไปสู่ app ที่มี data จริง
นั่นทำให้มันมีประโยชน์ขึ้น แต่ก็เสี่ยงขึ้น
เก็บข้อมูลให้น้อยที่สุด
แยก publishable key กับ secret key ให้ชัด
อย่า commit .env หรือ .env.local
เปิด RLS และให้สิทธิ์เท่าที่จำเป็น
Test ทั้ง local และ production
เขียน launch note ว่าเก็บอะไรและไม่ทำอะไร
บทต่อไปเป็น optional/bonus: เราจะต่อยอดจากข้อมูลที่เก็บได้ไปเป็น internal dashboard ขนาดเล็ก ถ้าคุณยังไม่มั่นใจเรื่อง auth, permission หรือ RLS ให้ข้ามบทนั้นชั่วคราวได้
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย