ข้างในแอปที่สร้างด้วย AI มีอะไรบ้าง: ทัวร์สำหรับคนที่ไม่ใช่นักพัฒนา

คุณพิมพ์คำอธิบาย กดปุ่ม แล้วยี่สิบนาทีต่อมาคุณก็ได้แอปที่ใช้งานได้ เยี่ยม แต่ตอนนี้คุณคลิก “ดูไฟล์” แล้วจ้องโครงสร้างโฟลเดอร์ที่ดูเหมือนเขียนด้วยภาษาคนละภาษา package.json คืออะไร? ทำไมใน node_modules ถึงมีของตั้งสี่สิบอย่าง? “schema” หมายความว่าอะไร แล้วทำไมคุณถึงมีมัน?

บทความนี้คือทัวร์พาชม ไม่ใช่บทเรียน — เป็นทัวร์ หลังอ่านจบคุณจะยังเขียนไฟล์พวกนี้ด้วยตัวเองไม่ได้ แต่ครั้งหน้าที่มีอะไรดูแปลกๆ คุณจะรู้ว่าควรชี้ไปที่มุมไหนของแอป

ผมจะใช้สามตัวอย่างวิ่งคู่กันไปตลอดทั้งบทความ เพื่อให้ส่วนที่เป็นนามธรรมมีอะไรที่จับต้องได้ให้ยึดเกาะ:

• มายา หัวหน้าฝ่ายการตลาด ที่สร้างกระดานจัดอันดับการแนะนำเพื่อนให้ทีมของเธอ
• จอร์แดน ครูสอนโยคะ ที่สร้างเว็บจองคลาส
• แซม ที่เปิดร้านเบเกอรี และสร้างหน้า “พรีออเดอร์ครัวซองต์ของวันพรุ่งนี้”

ทั้งสามคนใช้ AI app builder ทั้งสามแอปดูแตกต่างกันโดยสิ้นเชิงในสายตาลูกค้า แต่เบื้องหลังแล้ว โครงสร้างกลับคล้ายกันอย่างน่าประหลาด

ฟรอนต์เอนด์: สิ่งที่ลูกค้าของคุณเห็นจริงๆ

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

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

ภายในโปรเจกต์ ฟรอนต์เอนด์มักอยู่ในโฟลเดอร์ชื่อประมาณ app/, pages/, หรือ src/ คุณจะเห็นไฟล์ที่ลงท้ายด้วย .tsx หรือ .jsx แต่ละไฟล์คร่าวๆ คือ “หนึ่งหน้าจอ” หรือ “หนึ่งชิ้นส่วนของหน้าจอ” แถวในกระดานจัดอันดับคือไฟล์หนึ่ง ส่วนหัวเป็นอีกไฟล์ หน้าที่ผูกทุกอย่างเข้าด้วยกันคือไฟล์ที่สาม

เมื่อคุณขอให้ AI builder “ทำให้ปุ่มมนขึ้น” หรือ “ย้ายกระดานจัดอันดับไปทางขวา” นี่คือส่วนที่เปลี่ยนแปลง

แบ็กเอนด์: ส่วนที่คอยคิด

แบ็กเอนด์คือส่วนที่ไม่มีใครเห็น แต่ทุกคนต้องพึ่งพา มันคือโค้ดที่รันอยู่ ที่อื่น — บนเซิร์ฟเวอร์ ไม่ใช่ในเบราว์เซอร์ของลูกค้า — เมื่อมีบางอย่างที่ต้องเกิดขึ้นซึ่งเราไม่ควรไว้ใจให้เบราว์เซอร์ของลูกค้าทำเองตามลำพัง

ทำไมเบราว์เซอร์ถึงทำทุกอย่างเองไม่ได้? เพราะเบราว์เซอร์คือเครื่องของลูกค้า และคุณไว้ใจมันไม่ได้ ถ้ากระดานจัดอันดับของมายาอัปเดตจำนวนการแนะนำเพื่อนในเบราว์เซอร์ล้วนๆ ใครก็ตามคลิกขวาแล้วเพิ่มการแนะนำเพื่อนให้ตัวเองอีก 9,000 ครั้งได้ ดังนั้นแบ็กเอนด์จึงเป็นที่ที่กฎต่างๆ อยู่: “คนนี้ทำอันนี้ได้ แต่ทำอันนั้นไม่ได้” “บันทึกอันนี้ลงฐานข้อมูลจริงๆ ซะ” “ส่งอีเมลฉบับนี้”

แบ็กเอนด์มักอยู่ในโฟลเดอร์ชื่อ api/, server/, หรือ app/api/ ไฟล์ในนั้นมักจะสั้น แต่ละไฟล์จัดการคำขอที่เฉพาะเจาะจง: “สร้างการจอง” “แสดงรายการครัวซองต์ของวันนี้” “เพิ่มการแนะนำเพื่อน”

เมื่อมีบางอย่างทำงานได้ในแอปของคุณ แต่ ผลลัพธ์ กลับไม่ติดอยู่ — คุณกดส่ง คุณเห็นข้อความยืนยัน แต่พอวันรุ่งขึ้นข้อมูลหายไป — แบ็กเอนด์คือที่ที่บั๊กอยู่แทบทุกครั้ง

ฐานข้อมูล: ความทรงจำของแอปคุณ

ลองนึกถึงความทรงจำของแอปคุณเป็นแถวของตู้เก็บเอกสาร แต่ละตู้มีป้ายติดอยู่ด้านหน้า ตู้หนึ่งเขียนว่า “users” อีกตู้เขียนว่า “bookings” อีกตู้เขียนว่า “croissant_orders” ในตู้แต่ละใบ ลิ้นชักแต่ละอันคือหนึ่งแถว ทุกลิ้นชักมีช่องเสียบชุดเดียวกัน: ชื่อ อีเมล วันที่สร้าง สถานะ

โครงสร้างนั้น — “มีตู้อะไรบ้าง แต่ละแถวมีช่องอะไรบ้าง” — เรียกว่า schema มันคือไฟล์ที่สำคัญที่สุดในโปรเจกต์ ถึงแม้มันน่าจะเป็นไฟล์ที่หน้าตาน่าเบื่อที่สุดด้วยเช่นกัน ลองหาไฟล์ชื่อ schema.ts, schema.prisma, หรืออะไรสักอย่างในโฟลเดอร์ชื่อ db/ หรือ migrations/ เปิดมันขึ้นมา คุณจะเห็นรายการที่สะท้อนสิ่งที่แอปของคุณจดจำเกี่ยวกับโลกนี้จริงๆ

schema ของจอร์แดนมีตาราง classes ตาราง bookings และตาราง users ของแซมมี products, orders, และ order_items ของมายามี members และ referrals รูปร่างของ schema คือรูปร่างของผลิตภัณฑ์ ซึ่งเป็นเหตุผลว่าทำไมการเปลี่ยนมันทีหลังถึงยากกว่าการเปลี่ยนหน้าตาของปุ่ม

เคล็ดลับที่มีประโยชน์: ถ้าคุณอธิบายได้ว่าแอปของคุณจดจำอะไรบ้างเป็นคำพูดธรรมดา คุณก็มักจะอธิบาย schema ได้ “ฉันจำชื่อกับอีเมลของลูกค้าแต่ละคน สำหรับลูกค้าแต่ละคน ฉันจำออเดอร์ที่เขาสั่ง สำหรับแต่ละออเดอร์ ฉันจำว่ามีขนมอบชนิดไหนและอย่างละกี่ชิ้น” ประโยคนั้นแหละ คือ schema เกือบทุกคำต่อคำ

Auth: ยามเฝ้าประตู

“Auth” คือสองคำมารวมกัน: authentication (คุณเป็นใคร?) และ authorization (คุณได้รับอนุญาตให้ทำอะไรได้บ้าง?) ทั้งสองอย่างมักถูกจัดการด้วยไฟล์ชุดเล็กๆ ในโฟลเดอร์ชื่อ auth/ หรือด้วยบริการที่คุณอาจคุ้นชื่อ: Clerk, Auth0, Supabase Auth, NextAuth

สองคำถามนี้ต่างกัน Authentication ตอบว่า: “นี่คือมายาจริงๆ ใช่ไหม?” — มักด้วยรหัสผ่าน การล็อกอินด้วย Google หรือลิงก์เวทมนตร์ที่ส่งอีเมลไปให้เธอ ส่วน Authorization ตอบว่า: “มายาได้รับอนุญาตให้ลบการแนะนำเพื่อนของคนอื่นไหม?” — และคำตอบตรงๆ สำหรับแอปที่สร้างด้วย AI ส่วนใหญ่ในสัปดาห์แรกคือ “เราลืมตรวจสอบ”

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

Integrations: สิ่งที่คุณไม่ได้สร้าง แต่ก็ใช้มันอยู่ดี

นี่คือจุดที่คนส่วนใหญ่ที่ไม่ใช่นักพัฒนาประเมินค่าต่ำไปว่าจริงๆ แล้วมีอะไรเกิดขึ้นบ้าง สิ่งที่ส่งอีเมล “ครัวซองต์ของคุณพร้อมแล้ว” ของแซมไม่ใช่โค้ด — แต่เป็นบัญชีที่ SendGrid หรือ Resend สิ่งที่ประมวลผลการชำระเงินค่าคลาสของจอร์แดนไม่ใช่โค้ด — แต่เป็น Stripe สิ่งที่เก็บภาพถ่ายบนกระดานจัดอันดับของมายาไม่ใช่โค้ด — แต่เป็นบริการจัดเก็บอย่าง S3 หรือ Cloudinary

integration แต่ละตัวจะปรากฏอยู่สองที่ มีโค้ดชิ้นเล็กๆ ในแบ็กเอนด์ที่บอกว่า “เฮ้ Stripe เก็บเงินจากบัตรนี้ที” และมีคีย์ — สตริงลับยาวๆ — เก็บไว้ในที่ปลอดภัยที่ไหนสักแห่ง (มักเป็นไฟล์ชื่อ .env ที่ไม่ควรมีใคร commit เด็ดขาด) ซึ่งเป็นเครื่องพิสูจน์ต่อ Stripe ว่าคำขอนี้มาจากร้านเบเกอรีของแซม ไม่ใช่จากคนแปลกหน้า

ถ้าคุณเคยสงสัยว่าทำไมแอปของคุณจู่ๆ เลิกส่งอีเมลหรือเลิกรับการชำระเงิน สาเหตุแทบทุกครั้งคือหนึ่งในนี้: คีย์หมดอายุ ถึงขีดจำกัดการใช้งาน หรือนโยบายของ integration เปลี่ยนไป โค้ดไม่ได้พัง แต่การจับมือกันต่างหากที่พัง

การดีพลอย: มันไปถึงอินเทอร์เน็ตได้อย่างไร

ชิ้นสุดท้ายคือส่วนที่เปลี่ยนโฟลเดอร์บนดิสก์ของคุณให้กลายเป็นสิ่งที่ลูกค้าเข้าชมได้ผ่าน URL ส่วนนี้มักหมายถึงของสามอย่างเล็กๆ ที่ทำงานร่วมกัน:

• โฮสต์: บริการอย่าง Vercel, Netlify, Fly, หรือ Render ที่รันแบ็กเอนด์และเสิร์ฟฟรอนต์เอนด์ของคุณ
• โดเมน: ชื่ออย่าง mayas-leaderboard.com ที่ชี้ไปที่โฮสต์ของคุณ
• การบิลด์: สูตรที่หยิบไฟล์ต้นฉบับที่รกๆ ของคุณมาแล้วเปลี่ยนเป็นเวอร์ชันที่เพรียวกว่า เร็วกว่า ซึ่งรันได้จริง

เมื่อมีบางอย่างทำงานได้ ในเครื่อง แต่กลับพัง ตอนใช้งานจริง ปัญหามักอยู่ตรงนี้ คีย์ที่ตั้งไว้บนแล็ปท็อปของคุณแต่ไม่ได้ตั้งบนโฮสต์ ไลบรารีที่ติดตั้งในตอนพัฒนาแต่ไม่ได้ติดตั้งตอนใช้งานจริง ฐานข้อมูลที่มีอยู่ในเบราว์เซอร์ของคุณแต่ไม่มีบนเว็บไซต์จริง

นิสัยห้านาทีที่คุ้มค่าในตัวมันเอง

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

มายาทำแบบนี้ทุกบ่ายวันศุกร์ เธอพิมพ์ว่า: “สัปดาห์นี้ schema มีอะไรเปลี่ยนไปบ้าง และทำไม?” และ: “มี integration ใหม่ในแอปนี้ที่ฉันไม่ได้ขอบ้างไหม?” คำตอบเกือบทุกครั้งทำให้สบายใจ ส่วนไม่กี่ครั้งที่ไม่สบายใจ เธอก็จับปัญหาได้ตั้งแต่ตอนที่มันยังเล็กอยู่

นั่นแหละคือจุดมุ่งหมายทั้งหมดของการเข้าใจส่วนต่างๆ ไม่ใช่เพื่อมาเป็นนักพัฒนา แค่เพื่อให้ถามคำถามได้ดีขึ้น

ไปต่อที่ไหนดี

ถ้าทัวร์นี้ช่วยได้ บทความต่อเนื่องสองชิ้นนี้คุ้มค่าแก่เวลาของคุณ บั๊กแบบ ‘ดูปกติดี’ ครอบคลุมว่าต้องทำอย่างไรเมื่อหนึ่งในส่วนเหล่านี้พังเงียบๆ และ พร้อมเดโมกับพร้อมใช้งานจริง ครอบคลุมวิธีดูว่าแอปของคุณขยับจากขั้นแรกมาสู่ขั้นที่สองแล้วหรือยัง แผนที่เดียวกัน แต่ใช้คนละแบบ