פיתוח מוצרים בכלי no-code קצת גורמים לזה להרגיש קל מדי. כותבים prompt, מקבלים UI, מחברים Supabase, ו"יש מוצר".
המרחק בין דמו למוצר שאפשר לסמוך עליו נקבע על ידי 3 דברים:
Authentication
מודל נתונים
הרשאות (RLS)
משתפת אתכם בתובנות שלי מתהליך העבודה שלי על הפלטפורמה שבניתי:
1. Authentication ≠ Login. זה החלטת מוצר
הטעות: לחשוב ש-auth זה "Magic link או סיסמה".
האמת: זו החלטה שמשנה הרבה ומשפיעה על אחוזי ההרשמה.
מה לעשות מהיום הראשון:
הפרידו בין זהות טכנית לזהות מוצרית:
auth.users= זהות טכנית (Supabase מנהל)profiles= זהות מוצרית (שם, role, plan, preferences)
למה זה קריטי: כשתרצו להוסיף תוכניות תשלום, ארגונים, או הרשאות - תעשו את זה ב-profiles בלי לגעת ב-auth layer.
דוגמה מהשטח:
התחלתי עם הרשמה עם אימייל, מהר מאוד גיליתי שיוזרים מעדיפים Google OAuth. כדאי לתכנן את זה מראש.
2. מודל נתונים: 3-5 טבלאות > טבלה אחת ענקית
הטעות הקלאסית: "נעשה טבלה אחת גדולה שמכילה הכל, זה יותר מהיר."
המחיר: אי אפשר למדוד, אי אפשר להגדיל סקייל, אי אפשר להוסיף הרשאות.
המינימום שעובד:
profiles - משתמש מוצרי
projects/challenges - מה שהמשתמש יוצר/פותר
memberships - מי שייך למה + role
events (optional) - מדידה, דיבוג, אנליטיקס
למה חשוב להתייחס לזה כבר בשלבי הבנייה: גם אם היום יש רק "משתמש אחד בודד", כשתרצו להוסיף:
Teams
Reviewers
B2B plans
הטבלה הזאת היא מה שיאפשר לכם לעשות את זה בלי לשבור הכל.
3. RLS = Trust Feature, לא סתם Security
Row Level Security הוא לא משהו ש"נחמד להוסיף". זה המנגנון שקובע אם המוצר שלך מוכן לצאת החוצה.
RLS: איך לוודא שמשתמש A לא רואה את הנתונים של משתמש B
מה זה בכלל RLS?
Row Level Security זה כלל פשוט: כל שורה בטבלה יודעת למי היא שייכת.
במקום שהקוד שלך יבדוק "האם המשתמש הזה רשאי לראות את הנתונים?" - המסד נתונים עושה את זה בשבילך, אוטומטית.
דוגמה פשוטה: אפליקציית משימות
יש לך אפליקציה עם טבלת tasks. כל משתמש רואה רק את המשימות שלו.
בלי RLS:
הקוד שלך צריך לזכור לפלטר בכל מקום:
"הצג לי משימות WHERE user_id = המשתמש המחובר"שכחת פעם אחת? כל המשתמשים רואים את המשימות של כולם.
עם RLS:
המסד נתונים פשוט לא מחזיר שורות שלא שייכות למשתמש. גם אם מישהו ינסה לרמות דרך Developer Console - הוא יקבל 0 תוצאות.
למה זה קריטי?
תארו לעצמכם:
משתמש פותח את Developer Console
הוא משנה פרמטר בקריאת API
בלי RLS: הוא רואה נתונים של כולם
עם RLS: המסד נתונים מחזיר ריק, גם אם ניסה לרמות
זה ההבדל בין "פרויקט אישי" ל"מוצר שאפשר להשיק".
2 טיפים מעשיים: איך לגרום ל-Lovable לעשות את זה נכון
טיפ 1: בקשו במפורש RLS בכל טבלה חדשה
במקום לכתוב:
"צור טבלה users_documents"
כתבו:
"צור טבלה users_documents עם RLS enabled. כל משתמש יכול לראות ולערוך רק את המסמכים שלו. הוסף policies מתאימות."
למה זה עובד:
Lovable יודע ליצור RLS policies, אבל רק אם תבקשו במפורש. אחרת הוא מניח שתעשו את זה בעצמכם.
טיפ 2: בקשו "secure by default" בהתחלה
בפרומפט הראשוני של הפרוייקט, הוסיפו:
"כל טבלה שיוצרים צריכה להיות secure by default:
RLS enabled אוטומטית
Policies שמאפשרות למשתמש לגשת רק לנתונים שלו
אף פעם לא להשתמש ב-service_role בצד הקליינט"
התוצאה:
Lovable יזכור את זה לאורך כל הפרויקט. כל טבלה חדשה תיווצר עם ברירת מחדל מאובטחת.
כלל הזהב שלי
אם יש בטבלה user_id, owner_id, או created_by:
✅ חובה RLS
✅ חובה להזכיר את זה בפרומפט
❌ לעולם לא
service_role_keyבצד הקליינט
אחרת: כל משתמש יכול לראות/לשנות/למחוק נתונים של אחרים.
צעדים נכונים יביאו למוצר יציב ומאובטח.
בהצלחה!