Technical Mistakes Of Running 16 Products on Lovable and Supabase
Chúng tôi vận hành 16 sản phẩm tại Inithouse. Chúng tôi sử dụng Lovable và Supabase cho tất cả các sản phẩm đó. Một đội ngũ quản lý mọi thứ. Nghe có vẻ ổn cho đến khi bạn phải đối mặt với 16 tên miền tùy chỉnh (custom domains), 16 dự án Supabase và 16 bộ edge functions.
Chúng tôi đã mắc phải những sai lầm gây tốn kém thời gian. Dưới đây là 5 sai lầm kỹ thuật lớn nhất và cách chúng tôi khắc phục.
- Inconsistent database schemas
Ba sản phẩm đầu tiên của chúng tôi sử dụng các tên bảng khác nhau cho cùng một loại dữ liệu. Một dự án sử dụng page_views cho analytics. Một dự án khác lại dùng analytics_events. Điều này khiến việc viết mã dùng chung (shared code) trở nên bất khả thi. Một tác vụ đáng lẽ chỉ mất một buổi chiều đã kéo dài tới hai tuần.
Cách khắc phục: Chúng tôi đã xây dựng một shared migration template. Mọi sản phẩm mới đều có các bảng cơ bản giống nhau cho analytics, blog posts và auth. Chúng tôi đã nâng cấp (retrofit) các dự án cũ trong những tuần ít việc. Giờ đây, việc thêm một monitoring endpoint chỉ mất 20 phút thay vì cả ngày.
- Broken custom domains
Lovable cho phép bạn kết nối các tên miền tùy chỉnh. Đôi khi việc deploy thành công nhưng xác thực DNS lại thất bại. URL xem trước (preview URL) vẫn hoạt động, nhưng tên miền chính thức (live domain) lại hiển thị một trang trắng. Chúng tôi đã mất ba ngày lưu lượng truy cập (traffic) chỉ vì không kiểm tra URL thực tế.
Cách khắc phục: Chúng tôi sử dụng một danh sách kiểm tra (checklist) sau khi xuất bản. Chúng tôi mở mọi tên miền chính thức trong cửa sổ ẩn danh để xác minh. Chúng tôi cũng thêm một bước kiểm tra uptime để gửi thông báo (ping) đến Slack nếu một tên miền gặp lỗi.
- Fragmented data visibility
Chúng tôi không thể thấy được hiệu suất của toàn bộ danh mục sản phẩm (portfolio) mà không phải mở các dashboard riêng biệt cho từng sản phẩm. Chúng tôi như đang bay trong bóng tối.
Cách khắc phục: Chúng tôi đã triển khai một stats API endpoint tới mọi dự án Supabase. Mỗi sản phẩm gửi các chỉ số chính như users và signups theo một định dạng chuẩn. Một script duy nhất sẽ thu thập dữ liệu này vào một dashboard chung.
- Copy-pasting components
Chúng tôi từng sao chép các React component từ dự án này sang dự án khác. Những component này mang theo các giả định cũ. Một pricing card từ sản phẩm này bị lỗi ở sản phẩm khác vì nó mong đợi một payment flow khác. Chúng tôi đã mất nhiều ngày để gỡ lỗi (debug) những lỗi "ma" (phantom bugs) này.
Cách khắc phục: Chúng tôi đã ngừng việc copy-paste. Thay vào đó, chúng tôi duy trì một tài liệu về các component patterns. Chúng tôi yêu cầu Lovable xây dựng một component mới dựa trên các pattern này. Việc thiết lập ban đầu có thể chậm hơn nhưng việc bảo trì sẽ dễ dàng hơn nhiều.
- Using chat history as documentation
Chúng tôi từng dựa vào lịch sử chat của Lovable để ghi nhớ các quyết định kỹ thuật. Nhật ký chat (chat logs) rất lộn xộn. Chúng trộn lẫn giữa các thay đổi thành công với các nỗ lực thất bại. Việc tìm kiếm một lý do cụ thể cho một thay đổi trong một luồng hội thoại dài là rất khó khăn.
Cách khắc phục: Chúng tôi đã chuyển việc ghi chép quyết định sang Linear. Chúng tôi viết một dòng trong Linear để giải thích cái gì đã thay đổi và tại sao. Chat của Lovable là để thực thi (execution). Linear là để đưa ra quyết định (decisions).
Bài học rút ra rất đơn giản. Đừng coi 16 sản phẩm như 16 dự án riêng biệt. Hãy coi chúng như một danh mục (portfolio) duy nhất. Hãy tiêu chuẩn hóa các template của bạn và giám sát mọi thứ từ một nơi duy nhất.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi