ข้อผิดพลาดทางเทคนิคจากการรัน 16 ผลิตภัณฑ์บน Lovable และ Supabase

ที่ Inithouse เราดูแลผลิตภัณฑ์ถึง 16 อย่าง โดยใช้ Lovable และ Supabase สำหรับทุกผลิตภัณฑ์ และมีเพียงทีมเดียวที่จัดการทุกอย่าง

การจัดการ 16 ผลิตภัณฑ์หมายถึงการต้องดูแล 16 custom domains, 16 โปรเจกต์ Supabase และ edge functions อีก 16 ชุด ซึ่งขนาดที่ใหญ่ขนาดนี้ก็นำไปสู่ข้อผิดพลาดซ้ำๆ

และนี่คือข้อผิดพลาดทางเทคนิค 5 ประการที่เราเคยทำพลาด และวิธีที่เราแก้ไขมัน

1. Database Schemas ที่ไม่สอดคล้องกัน

ผลิตภัณฑ์ 3 อย่างแรกของเราใช้ชื่อที่แตกต่างกันสำหรับข้อมูลประเภทเดียวกัน โปรเจกต์หนึ่งใช้ page_views สำหรับ analytics ในขณะที่อีกโปรเจกต์ใช้ analytics_events

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

วิธีแก้ไข: เราสร้าง shared migration template ขึ้นมา โดยผลิตภัณฑ์ใหม่ทุกตัวจะใช้ base tables ชุดเดียวกันสำหรับ analytics, blog posts และ auth

2. ความล้มเหลวของ Domain ที่ไม่แจ้งเตือน

Lovable ช่วยให้คุณเชื่อมต่อ custom domains ได้ แต่บางครั้งการ deploy สำเร็จแต่การตรวจสอบ DNS กลับล้มเหลว ผลคือ preview URL ใช้งานได้ปกติ แต่ live domain กลับแสดงหน้าว่างเปล่า

เราเสียโอกาสในการเข้าชม (traffic) ของผลิตภัณฑ์หนึ่งไปถึงสามวันกว่าจะรู้ตัว

วิธีแก้ไข: เราใช้ post-publish checklist โดยเราจะเปิด live domain ในหน้าต่าง incognito เพื่อตรวจสอบ และยังใช้ cron job เพื่อ ping ไปยัง domain ทุกๆ 5 นาทีด้วย

3. การมองเห็นข้อมูลที่กระจัดกระจาย

ในการดูประสิทธิภาพของผลิตภัณฑ์ เราต้องเปิดทั้ง Supabase dashboards และ GA4 properties แยกกัน ทำให้เราเหมือนกำลังทำงานโดยมองไม่เห็นภาพรวม (flying blind)

วิธีแก้ไข: เราได้ deploy stats API endpoint ไปยังทุกโปรเจกต์ Supabase โดยแต่ละผลิตภัณฑ์จะใช้ edge function เพื่อส่งค่า key metrics กลับมาในรูปแบบเดียวกัน จากนั้นเราใช้สคริปต์ง่ายๆ ดึงข้อมูลจากทั้ง 16 endpoints มารวมไว้ใน dashboard เดียว

4. การคัดลอกและวาง Component

เมื่อก่อนเรามักจะคัดลอก React components จากโปรเจกต์หนึ่งไปอีกโปรเจกต์หนึ่ง ซึ่งทำให้เกิดบั๊ก เช่น pricing card จากโปรเจกต์หนึ่งถูกออกแบบมาสำหรับการชำระเงินครั้งเดียว แต่พอเรานำไปวางในโปรเจกต์แบบสมัครสมาชิก (subscription) มันกลับทำให้ระบบ Stripe พัง

วิธีแก้ไข: เราเลิกใช้วิธีคัดลอกและวางโค้ด แต่เปลี่ยนมาทำเอกสารรวบรวม component patterns แทน แล้วเราจะบอกให้ Lovable สร้าง component ใหม่ขึ้นมาโดยอิงจาก pattern เหล่านั้น วิธีนี้ช่วยป้องกันบั๊กที่เกิดจากสมมติฐานเก่าๆ ได้

5. การใช้ Chat เป็นเอกสารประกอบ

เราเคยใช้ประวัติการแชทใน Lovable เป็นเอกสารประกอบ (documentation) แต่การค้นหาการตัดสินใจทางเทคนิคเฉพาะเจาะจงในเธรดแชทที่ยาวเหยียดนั้นทำได้ยากและล่าช้า

วิธีแก้ไข: เราย้ายการบันทึกการตัดสินใจ (decision logging) ไปไว้ใน Linear โดยทุกการเปลี่ยนแปลงทางเทคนิคที่สำคัญจะต้องมีการคอมเมนต์ใน Linear เพื่ออธิบายว่าเปลี่ยนอะไรและทำไม ส่วน Lovable chat จะใช้สำหรับการสั่งงาน (execution) และ Linear จะใช้สำหรับการตัดสินใจ (decisions)

บทเรียนที่ได้รับ: อย่ามองว่าผลิตภัณฑ์ 16 อย่างคือ 16 โปรเจกต์ที่แยกจากกัน แต่ให้มองว่าเป็นพอร์ตโฟลิโอ (portfolio) เดียวกัน จงทำให้ template เป็นมาตรฐาน และตรวจสอบทุกอย่างจากส่วนกลาง

Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh