ข้อผิดพลาดทางเทคนิคจากการรัน 16 ผลิตภัณฑ์บน Lovable และ Supabase
ที่ Inithouse เราดูแลผลิตภัณฑ์ถึง 16 อย่าง โดยใช้ Lovable และ Supabase สำหรับทุกผลิตภัณฑ์ และมีทีมเพียงทีมเดียวที่จัดการทุกอย่าง ฟังดูเหมือนจะเป็นเรื่องดี จนกระทั่งคุณต้องเผชิญกับ 16 custom domains, 16 โปรเจกต์ Supabase และ edge functions อีก 16 ชุด
เราเคยทำพลาดจนทำให้เสียเวลาไปมาก และนี่คือ 5 ข้อผิดพลาดทางเทคนิคที่ใหญ่ที่สุดพร้อมวิธีแก้ไขของเรา
- Inconsistent database schemas
ผลิตภัณฑ์ 3 อย่างแรกของเราใช้ชื่อตารางที่แตกต่างกันสำหรับข้อมูลประเภทเดียวกัน โปรเจกต์หนึ่งใช้ page_views สำหรับ analytics แต่อีกโปรเจกต์กลับใช้ analytics_events สิ่งนี้ทำให้เราไม่สามารถเขียนโค้ดที่ใช้ร่วมกันได้ งานที่ควรจะเสร็จภายในบ่ายวันเดียวกลับต้องใช้เวลาถึงสองสัปดาห์
The fix: เราสร้าง shared migration template ขึ้นมา โดยผลิตภัณฑ์ใหม่ทุกตัวจะมี base tables ชุดเดียวกันสำหรับ analytics, blog posts และ auth เราทำการปรับปรุงโปรเจกต์เก่าในช่วงสัปดาห์ที่งานไม่ยุ่ง ตอนนี้การเพิ่ม monitoring endpoint จึงใช้เวลาเพียง 20 นาที แทนที่จะเป็นทั้งวัน
- Broken custom domains
Lovable ช่วยให้คุณเชื่อมต่อ custom domains ได้ แต่บางครั้งการ deploy สำเร็จแต่การตรวจสอบ DNS กลับล้มเหลว URL ตัวอย่าง (preview URL) ใช้งานได้ปกติ แต่โดเมนจริงกลับแสดงหน้าว่างเปล่า เราต้องเสียโอกาสในการเข้าชม (traffic) ไปถึง 3 วัน เพียงเพราะเราไม่ได้ตรวจสอบ URL ที่ใช้งานจริง
The fix: เราใช้ post-publish checklist โดยเราจะเปิดทุกโดเมนจริงในหน้าต่าง incognito เพื่อตรวจสอบความถูกต้อง นอกจากนี้เรายังเพิ่ม uptime check ที่จะส่งการแจ้งเตือนไปยัง Slack หากโดเมนมีปัญหา
- Fragmented data visibility
เราไม่สามารถดูภาพรวมผลประกอบการของผลิตภัณฑ์ทั้งหมดในพอร์ตโฟลิโอได้ โดยไม่ต้องเปิด dashboard แยกกันสำหรับทุกผลิตภัณฑ์ ทำให้เราเหมือนกำลังทำงานโดยไม่มีข้อมูลประกอบการตัดสินใจ (flying blind)
The fix: เราได้ติดตั้ง stats API endpoint ไว้ในทุกโปรเจกต์ Supabase โดยแต่ละผลิตภัณฑ์จะส่งข้อมูลสำคัญ (key metrics) เช่น users และ signups ในรูปแบบมาตรฐาน จากนั้นเราใช้สคริปต์เพียงตัวเดียวในการดึงข้อมูลทั้งหมดมารวมไว้ใน dashboard เดียว
- Copy-pasting components
เมื่อก่อนเรามักจะคัดลอก React components จากโปรเจกต์หนึ่งไปยังอีกโปรเจกต์หนึ่ง ซึ่งคอมโพเนนต์เหล่านี้มักจะติดเงื่อนไขเดิมๆ มาด้วย เช่น pricing card จากผลิตภัณฑ์หนึ่งอาจใช้งานไม่ได้ในอีกผลิตภัณฑ์หนึ่ง เพราะมันถูกออกแบบมาให้รองรับ payment flow ที่ต่างกัน เราต้องเสียเวลาหลายวันในการไล่แก้บั๊กที่หาสาเหตุได้ยาก (phantom bugs) เหล่านี้
The fix: เราเลิกใช้วิธีคัดลอกและวาง แต่เปลี่ยนมาทำเอกสารรวบรวม component patterns แทน เราจะสั่งให้ Lovable สร้างคอมโพเนนต์ใหม่ขึ้นมาโดยอ้างอิงจากรูปแบบเหล่านี้ แม้การตั้งค่าจะช้ากว่า แต่ก็ช่วยให้ดูแลรักษาได้ง่ายกว่ามาก
- Using chat history as documentation
เราเคยพึ่งพาประวัติการแชทใน Lovable เพื่อจดจำการตัดสินใจทางเทคนิค แต่ประวัติการแชทนั้นค่อนข้างวุ่นวาย เพราะมันปนกันระหว่างการเปลี่ยนแปลงที่สำเร็จและสิ่งที่ล้มเหลว การจะหาเหตุผลเฉพาะเจาะจงสำหรับการเปลี่ยนแปลงบางอย่างในเธรดที่ยาวเหยียดจึงเป็นเรื่องยาก
The fix: เราย้ายการบันทึกการตัดสินใจไปไว้ใน Linear แทน โดยเราจะเขียนเพียงบรรทัดเดียวใน Linear เพื่ออธิบายว่าอะไรเปลี่ยนไปและเพราะอะไร Lovable chat มีไว้สำหรับการลงมือทำ (execution) ส่วน Linear มีไว้สำหรับการตัดสินใจ (decisions)
บทเรียนนี้เรียบง่ายมาก อย่าปฏิบัติกับผลิตภัณฑ์ 16 อย่างเหมือนเป็น 16 โปรเจกต์ที่แยกจากกัน แต่ให้ปฏิบัติเหมือนเป็นพอร์ตโฟลิโอเดียว จงทำให้เทมเพลตเป็นมาตรฐานเดียวกัน และตรวจสอบทุกอย่างจากที่เดียว
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi