Backend สำหรับคน Vibe Coding: Database, Auth และ Storage

Plants.work · · upskilling
Backend สำหรับคน Vibe Coding: Database, Auth และ Storage

เข้าใจสามส่วนหลักของ backend ผ่านตัวอย่าง Supabase พร้อมเรื่อง Row Level Security และ key ที่ห้ามหลุด ก่อนแอปของคุณมีผู้ใช้จริง

แอปที่คุณ vibe coding มาอาจดูสมบูรณ์บนหน้าจอ แต่พอรีเฟรชหน้า ข้อมูลที่กรอกไว้หายหมด หรือเพื่อนเปิดลิงก์จากเครื่องอื่นแล้วไม่เห็นอะไรเลย นี่คือสัญญาณว่าแอปของคุณยังมีแค่ "หน้าบ้าน" ยังไม่มี "หลังบ้าน" บทความนี้อธิบายสามส่วนหลักของ backend ที่คนทำ vibe coding ต้องเข้าใจ โดยใช้ Supabase เป็นตัวอย่าง เพราะเป็นบริการที่เครื่องมือ vibe coding หลายตัวเชื่อมต่อได้

Backend คืออะไร

Backend คือส่วนที่ทำงานอยู่บนเซิร์ฟเวอร์ ผู้ใช้มองไม่เห็น ทำหน้าที่ เก็บข้อมูล ตรวจว่าใครเป็นใคร และตัดสินว่าใครทำอะไรได้ ส่วน frontend คือหน้าจอที่รันในเบราว์เซอร์ของผู้ใช้ จุดสำคัญคือ ทุกอย่างที่อยู่ใน frontend ผู้ใช้ที่ตั้งใจจะดูก็ดูได้ทั้งหมด การตัดสินใจเรื่องสิทธิ์จึงต้องอยู่ที่ backend เสมอ

หน้า Features ของ Supabase อธิบายว่าทุกโปรเจกต์คือฐานข้อมูล Postgres เต็มรูปแบบ พร้อมบริการ Auth, Storage, Edge Functions, Realtime และอื่นๆ อยู่ในที่เดียว Lovable ก็ระบุว่ามี native Supabase integration สำหรับเพิ่ม login ฐานข้อมูล และการเก็บไฟล์ ส่วน Bolt รองรับการเชื่อม Supabase เช่นกัน

ส่วนที่ 1: Database เก็บข้อมูลเป็นตาราง

คิดแบบตาราง Excel ที่เชื่อมกันได้

ฐานข้อมูลแบบ Postgres เก็บข้อมูลเป็นตาราง แต่ละตารางมีคอลัมน์ชัดเจน และเชื่อมกันผ่าน ID เช่น ตาราง "นักเรียน" กับตาราง "การบ้านที่ส่ง" เชื่อมกันด้วยรหัสนักเรียน

สิ่งที่ควรสั่ง AI

ส่วนที่ 2: Auth รู้ว่าใครเป็นใคร

Auth (Authentication) คือระบบ login หน้า Features ของ Supabase ระบุว่ารองรับทั้งอีเมล เบอร์โทร social login, SSO และ MFA เมื่อผู้ใช้ login แล้ว ระบบจะรู้ว่าคำขอแต่ละครั้งมาจากใคร ข้อมูลนี้คือพื้นฐานของการกำหนดสิทธิ์ในส่วนถัดไป

อย่าสับสนระหว่าง Authentication (คุณคือใคร) กับ Authorization (คุณทำอะไรได้บ้าง) แอปจำนวนมากมี login แต่ลืมจำกัดว่าคนที่ login แล้วเห็นข้อมูลของคนอื่นได้หรือไม่

ส่วนที่ 3: Storage เก็บไฟล์

รูป PDF หรือไฟล์แนบไม่ควรเก็บในตารางโดยตรง แต่เก็บใน Storage ซึ่งเป็นพื้นที่เก็บไฟล์ แล้วตารางเก็บแค่ที่อยู่ของไฟล์ สิ่งที่ต้องตัดสินใจคือ bucket ไหนเป็นสาธารณะ (เช่น รูปสินค้า) และ bucket ไหนต้องเป็นส่วนตัว (เช่น สลิป เอกสารสมัครงาน)

กุญแจสำคัญ: Row Level Security

คู่มือ "Securing your data" ของ Supabase อธิบายว่า Row Level Security (RLS) คือกลไกที่ควบคุมว่าผู้ใช้อ่านหรือแก้ แถวไหน ในตารางได้ และแนะนำให้เปิด RLS ในทุกตารางที่เข้าถึงผ่าน Data API แล้วเขียน policy ให้สิทธิ์เท่าที่จำเป็น เช่น "นักเรียนเห็นเฉพาะการบ้านของตัวเอง" หรือ "ครูเห็นการบ้านของทุกคนในห้องที่ตัวเองสอน"

เอกสารเดียวกันอธิบายเรื่อง key สองแบบ: publishable key (หรือ anon key ในโปรเจกต์รุ่นเก่า) ใส่ใน frontend ได้ เพราะทุกคำขอจะถูกตรวจด้วย RLS ส่วน service role key หรือ secret key ข้าม RLS ได้ทั้งหมด จึงต้องเก็บไว้ฝั่ง backend เท่านั้น ห้ามอยู่ในโค้ดหน้าเว็บเด็ดขาด ถ้าต้องมี logic ฝั่งเซิร์ฟเวอร์ที่ใช้ secret ให้ใส่ใน Edge Functions

ตัวอย่าง: โรงเรียนกวดวิชาในนครปฐม

ครูเจ้าของโรงเรียนอยากให้นักเรียนส่งการบ้านเป็นรูปถ่ายผ่านเว็บ เธอวางโครงไว้ว่า ตาราง students, classes และ submissions ใช้ Auth ให้นักเรียนและครู login ด้วยอีเมล เก็บรูปการบ้านใน bucket ส่วนตัว แล้วสั่ง AI ว่า "เปิด RLS ทุกตาราง นักเรียนเห็นและส่งได้เฉพาะงานของตัวเอง ครูเห็นงานของห้องที่สอน" ก่อนเปิดใช้ เธอสร้างบัญชีนักเรียนทดสอบสองบัญชี แล้วลองให้บัญชีหนึ่งเปิดดูงานของอีกบัญชี ผลคือมองไม่เห็น นี่คือการทดสอบที่สำคัญที่สุด

Login บอกว่าคุณเป็นใคร แต่ RLS คือสิ่งที่บอกว่าคุณเห็นอะไรได้

ข้อควรระวัง

เริ่มต้นยังไง

  1. เขียนรายการข้อมูลที่แอปต้องเก็บ และบทบาทผู้ใช้ทั้งหมด
  2. เขียนกติกาสิทธิ์เป็นภาษาคน เช่น "ใครเห็นอะไร ใครแก้อะไรได้"
  3. ให้ AI สร้างตาราง เปิด RLS และเขียน policy ตามกติกานั้น
  4. สร้างบัญชีทดสอบอย่างน้อยสองบัญชี แล้วลองเข้าถึงข้อมูลข้ามกัน

ถ้าอยากเห็นภาพรวมการสร้างแอปตั้งแต่ต้น อ่าน จาก PRD สู่แอป หรือลงมือทำแอปที่มีฐานข้อมูลจริงกับคอร์ส สร้างแอปจัดการสต๊อกด้วย Lovable บน Plants.work