แอป Full-Stack คืออะไร คำอธิบายง่าย ๆ

แอป full-stack คือแอปที่มีทุกชั้นที่จำเป็นต่อการทำงาน ได้แก่ frontend ที่ผู้คนเห็นและคลิก backend ที่ทำงานบนเซิร์ฟเวอร์และบังคับใช้กฎ และฐานข้อมูลที่จดจำทุกอย่าง รายการสิ่งที่ต้องทำที่บันทึกงานของคุณ ให้คุณล็อกอินจากอุปกรณ์ใดก็ได้ และไม่แสดงรายการของคุณให้คนอื่นเห็น ถือเป็น full-stack ส่วนหน้าเดียวที่แสดงเฉพาะเวลาทำการของร้านไม่ใช่

คำว่า “stack” หมายถึงชั้นของเทคโนโลยีที่วางซ้อนกัน ส่วนคำว่า “full” หมายความว่าครบทุกชั้น

ทำไมเรื่องนี้สำคัญเมื่อสร้างด้วย AI

เมื่อคุณอธิบายแอปให้ตัวสร้างด้วย AI ฟัง คำที่คุณใช้เป็นตัวกำหนดว่ามันจะสร้างชั้นใดบ้าง “ทำหน้าที่แสดงเมนูของเรา” ให้ frontend “ให้ลูกค้าสั่งอาหารจากเมนูของเรา และให้ครัวเห็นออเดอร์ใหม่” ต้องใช้ครบทั้งสามชั้น เพราะออเดอร์ต้องถูกบันทึก แชร์ระหว่างผู้ใช้สองประเภท และเก็บเป็นความลับ

การรู้ความแตกต่างนี้ช่วยคุณได้สามทาง:

• คุณขอสิ่งที่ถูกต้อง ถ้าคุณต้องการให้ข้อมูลถูกบันทึก ให้บอกไปตรง ๆ ตัวสร้างที่สร้างแค่ frontend จะดูเสร็จสมบูรณ์ แต่จะลืมทุกอย่างเมื่อรีเฟรช
• คุณจับความสมบูรณ์ปลอม ๆ ได้ เดโมที่ใช้ข้อมูลตัวอย่างอาจดูเหมือนแอปที่ใช้งานได้จริงทุกประการ การรู้ชั้นต่าง ๆ ช่วยให้คุณตรวจได้ว่าข้อมูลถูกส่งไปยังที่ที่ควรไปจริง
• คุณเข้าใจค่าใช้จ่ายในการรัน frontend อย่างเดียวสามารถให้บริการเป็นไฟล์สแตติกได้ แต่ backend และฐานข้อมูลเป็นโปรแกรมที่รันบนเซิร์ฟเวอร์ ซึ่งเป็นที่มาของค่า โฮสติ้ง ส่วนใหญ่

ตัวอย่างใกล้ตัว: ร้านอาหาร

ลองนึกถึงร้านอาหาร

• ห้องอาหารคือ frontend มีเมนู โต๊ะ และสมุดจดของพนักงานเสิร์ฟ เป็นสิ่งที่แขกเห็น และควรน่าอยู่และใช้ง่าย
• ครัวคือ backend แขกไม่เข้าไป ครัวรับออเดอร์ ตรวจว่าอาหารมีพร้อมหรือไม่ ปรุง และปฏิเสธคำขอแปลก ๆ กฎอยู่ที่นี่
• ห้องเก็บของและสมุดออเดอร์คือฐานข้อมูล เก็บสิ่งที่มีและสิ่งที่ถูกสั่ง เพื่อไม่ให้ลืมอะไรเมื่อกะเปลี่ยน

ร้านอาหารที่มีแค่ห้องอาหารสามารถแสดงเมนูสวย ๆ ให้คุณดูได้ แต่คุณไม่ได้กินอะไรเลย นั่นคือแอปที่มีแค่ frontend ซึ่งแกล้งทำเป็น full-stack

สามชั้นโดยละเอียด

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

ลำดับนั้นคือแนวคิดด้านความปลอดภัยที่สำคัญที่สุดของทั้งสแตก สิ่งใดก็ตามในฝั่ง frontend ผู้เข้าชมสามารถอ่านและเปลี่ยนแปลงได้ เพราะมันทำงานบนอุปกรณ์ของเขา ดังนั้นกฎ เช่น “เฉพาะเจ้าของเท่านั้นที่เห็นใบแจ้งหนี้นี้” หรือ “คูปองใช้ได้ครั้งเดียว” ต้องถูกบังคับใช้ที่ backend สำหรับการแบ่งหน้าที่ระหว่างสองฝั่ง ดู frontend กับ backend

ตัวอย่างจริง: แอปจองคลาสเรียนโยคะ

สมมติว่าคุณเปิดสตูดิโอโยคะและอยากให้คนจองคลาสออนไลน์ได้

สิ่งที่ผู้เข้าชมทำ: เปิดเว็บไซต์ เห็นคลาสของสัปดาห์นี้ แตะคลาสหนึ่ง ล็อกอิน และจองที่นั่ง

สิ่งที่เกิดขึ้นเบื้องหลัง:

1. frontend แสดงตารางเวลา เพื่อเติมข้อมูล มันถาม backend ว่า “มีคลาสอะไรบ้างในสัปดาห์นี้ และยังเหลือที่นั่งกี่ที่”
2. backend ถาม database เรื่องคลาสและนับการจองของแต่ละคลาส แล้วตอบกลับ
3. ผู้เข้าชมแตะ จอง frontend ส่ง “จองคลาสที่ 42 ให้คนที่ล็อกอินอยู่นี้”
4. backend ตรวจ: คนนี้ล็อกอินจริงหรือไม่ คลาสเต็มหรือยัง เขาจองคลาสนี้ไปแล้วหรือเปล่า เฉพาะเมื่อทุกอย่างถูกต้องเท่านั้นมันจึงเขียนแถวการจองใหม่ลงฐานข้อมูล
5. backend ตอบ “จองแล้ว” และ frontend แสดงการยืนยัน
6. ต่อมา เจ้าของสตูดิโอล็อกอินและเห็นรายการคลาส backend ตรวจว่าเธอเป็นแอดมินก่อนแสดงชื่อทุกคน

ลองนึกภาพว่าสิ่งนี้ถูกสร้างเป็น frontend อย่างเดียว ตารางเวลาอาจแสดงผลได้ และปุ่มจองอาจแสดงเครื่องหมายถูกสวย ๆ แต่การจองจะหายไปเมื่อรีเฟรช ตัวเลข “ที่นั่งที่เหลือ” จะผิดสำหรับคนอื่น และเจ้าของจะไม่เห็นมันเลย ขั้นตอนที่ 4 ซึ่งเป็นการตรวจสอบ จะหายไปทั้งหมด นั่นคือความแตกต่างในทางปฏิบัติ

คำศัพท์สำคัญ

• Frontend (ฝั่ง client): ส่วนที่ทำงานในเบราว์เซอร์
• Backend (ฝั่ง server): ส่วนที่ทำงานบนเซิร์ฟเวอร์ เรียกอีกอย่างว่า API server
• Database: ที่เก็บข้อมูลอย่างมีระบบ ดู ฐานข้อมูลคืออะไร
• API: รายการคำขอที่ backend ยอมรับจาก frontend หรือโปรแกรมอื่น
• Authentication: การตรวจสอบว่าใครเป็นใคร (การล็อกอิน) Authorisation: การตรวจสอบว่าเขามีสิทธิ์ทำอะไรได้บ้าง
• Deployment: การนำทุกชั้นขึ้นเซิร์ฟเวอร์เพื่อให้สาธารณะใช้งานได้
• Monolith กับ services: โปรแกรมเดียวที่ทำทุกอย่าง กับโปรแกรมย่อยหลายตัว (เช่น เว็บไซต์และ API แยกกัน) ทั้งสองแบบเป็น full-stack ได้

ความเข้าใจผิดและข้อผิดพลาดที่พบบ่อย

• “มันดูเสร็จแล้ว ก็คือเสร็จแล้ว” ข้อมูลตัวอย่างและปุ่มที่ดูเหมือนใช้งานได้ไม่เท่ากับข้อมูลที่ถูกบันทึก ให้รีเฟรชหน้า เปิดในหน้าต่างส่วนตัว และตรวจว่าข้อมูลยังอยู่
• ใส่กฎไว้ใน frontend การซ่อนปุ่มไม่ใช่ความปลอดภัย ถ้า backend ไม่ตรวจ ใครก็ตามที่รู้คำขอนั้นสามารถส่งคำขอได้
• ใส่คีย์ลับไว้ใน frontend คีย์ของผู้ให้บริการด้านการชำระเงินหรือ AI ที่อยู่ในโค้ดเบราว์เซอร์ ผู้เข้าชมทุกคนอ่านได้ คีย์ต้องอยู่ที่ backend ในตัวแปรสภาพแวดล้อม ดู ตัวแปรสภาพแวดล้อมและความลับ
• คิดว่า full-stack หมายถึงซับซ้อน แอป full-stack ขนาดเล็กอาจมีแค่ไม่กี่หน้าจอ route ของ backend เล็กน้อย และตารางฐานข้อมูลสามตาราง มันคือคำอธิบายของชั้น ไม่ใช่ขนาด
• คิดว่าต้องเลือกเทคโนโลยีทุกตัวเอง สแตกที่เป็นที่นิยมและเชื่อถือได้ใช้ได้ดีสำหรับเวอร์ชันแรก สิ่งที่สำคัญกว่าคือคำอธิบายที่ชัดเจนของข้อมูลและกฎ

สิ่งที่ควรขอจากตัวสร้างแอปด้วย AI

อธิบายแอปโดยใช้ทั้งสามชั้น แม้คุณจะไม่เรียกชื่อมันก็ตาม:

• ข้อมูล: “บันทึกคลาส (ชื่อ เวลา ความจุ) และการจอง (คลาส คนที่จอง เวลาที่จอง) ในฐานข้อมูล”
• กฎ: “ไม่สามารถจองคลาสเกินความจุได้ คนหนึ่งคนจองคลาสเดียวกันได้เพียงครั้งเดียว มีเพียงแอดมินเท่านั้นที่เห็นว่าใครจองบ้าง”
• หน้าจอ: “ตารางเวลารายสัปดาห์ การยืนยันการจอง และหน้าแอดมินที่แสดงรายการการจองแยกตามคลาส”
• การตรวจสอบ: “บังคับใช้กฎเหล่านี้บนเซิร์ฟเวอร์ ไม่ใช่แค่ในหน้าเว็บ และเก็บ API key ไว้บนเซิร์ฟเวอร์”

จากนั้นทดสอบแบบคนขี้สงสัย รีเฟรช ล็อกอินเป็นคนสองคนที่ต่างกัน และลองดูข้อมูลที่คุณไม่ควรเห็น คู่มือการสร้างแอปด้วย AI อธิบายวงจรนี้ตั้งแต่ต้นจนจบ

แอป Full-Stack บน Mythex

Mythex สร้างแอปเว็บ full-stack จากคำอธิบายในแชต โดยค่าเริ่มต้นแอปใหม่จะได้ frontend ที่ใช้ React และ TypeScript เมื่อแอปต้องบันทึกข้อมูล Mythex จะเพิ่มฐานข้อมูล Postgres เฉพาะให้กับโปรเจกต์ และคุณขอให้มี API server แยกต่างหาก (เช่น Python, Node, C# หรือ Java) ควบคู่กับเว็บไซต์ได้ ทุกอย่างรันร่วมกันในพรีวิวสด และเผยแพร่ไปยัง URL สาธารณะ หน้าเอกสารแอปหลายบริการ แสดงวิธีที่เว็บไซต์และ API ถูกพรีวิวและเผยแพร่ร่วมกัน และหน้าตัวสร้างแอป full-stack มีจุดเริ่มต้นให้เลือกใช้

คำถาม