הדרך של אפליקציית Base44 לפרודקשן מתחילה בהבנת הפלטפורמה.

מה Base44 בונה בשבילכם, ומה נשאר בפלטפורמה

Base44 מייצרת מתוך שיחה את צד הלקוח, ה-backend, מסד הנתונים, ההזדהות והאירוח של האפליקציה, ולכן היא כל כך מהירה לגרסה ראשונה. Wix רכשה את Base44 ביוני 2025. לפי תיעוד המפתחים של Base44, צד הלקוח הוא אפליקציית React סטנדרטית שנבנית עם Vite ומדברת עם ה-backend דרך ה-SDK של Base44. הנתונים מוגדרים כ-entities עם JSON schema ונשמרים במסד NoSQL תואם MongoDB, והלוגיקה בצד השרת רצה כפונקציות serverless מבוססות Deno שנכתבות ב-TypeScript.

ההבדל המהותי הוא ה-backend. התיעוד של Base44 מתאר אותו כפלטפורמה מנוהלת לנתונים, הזדהות, פונקציות ואירוח, וכותב שמשאבי ה-backend עולים לתשתית של Base44. אפשר לארח את צד הלקוח במקום אחר ולהמשיך לעבוד מול ה-backend של Base44, אבל האירוח של Base44 עצמה תומך רק ב-SPA, בלי רינדור בצד השרת. זה לא פגם. זו פשרה שקונה מהירות, ונכון לתכנן את הפרודקשן ממנה במקום לגלות אותה מאוחר.

סנכרון GitHub דו-כיווני זמין מתוכנית Builder ומעלה. שינויים ב-Base44 נדחפים ל-GitHub אוטומטית, שינויים מקומיים מגיעים ל-Base44 אחרי merge ל-main, ו-Publish נפרד מעלה אותם לאוויר. במסגרת הסנכרון הזה ה-entities מנוהלים ב-Base44 ולא נמצאים בריפו המקומי, כך שהריפו הוא לא עותק מלא של המערכת. מגדירים מקום אחד שבו עושים שינויים ומגנים על main.

הרשאות, secrets וסיכון ברמת הפלטפורמה

ב-entities של Base44 יש Row Level Security, שקובע לאילו רשומות משתמש יכול לגשת, ו-Field Level Security, שקובע אילו שדות ברשומה הוא יכול לראות או לשנות. הרשאה יכולה לאפשר לכולם, לחסום את כולם או לחול לפי תנאי, למשל התאמה ליוצר הרשומה או לתפקיד של המשתמש. הכללים האלה הם גבול האבטחה האמיתי: הסתרה של כפתור בממשק לא עוצרת קריאה ישירה ל-API. פונקציות backend שעובדות עם הרשאות service role צריכות בדיקות הרשאה משלהן, כי התיעוד מטיל את האחריות הזאת על הפונקציה.

סריקת האבטחה של Base44 זמינה בכל התוכניות ובודקת, בין השאר, הרשאות נתונים, secrets חשופים, פונקציות backend בלי הזדהות ותלויות פגיעות. את ה-secrets שומרים בכספת המוצפנת, שלפי Base44 נגישה רק מה-backend. Base44 גם כותבת במפורש שהאחריות על הגדרות האבטחה של האפליקציה היא שלכם.

חלק מהסיכונים נמצאים בפלטפורמה עצמה. ביולי 2025 פרסמה Wiz Research חולשה שבה אפשר היה, בעזרת מזהה אפליקציה שאינו סודי ו-endpoints לא מתועדים של הרשמה ואימות, ליצור חשבון מאומת באפליקציות פרטיות ב-Base44 ולעקוף SSO. Wix תיקנה אותה בפחות מ-24 שעות ומסרה שלא נמצאה עדות לניצול. המסקנה היא לא להתרחק מהפלטפורמה, אלא לבנות אפליקציות רגישות בשכבות: מינימום נתונים, בדיקות בצד השרת, audit log וניטור שנמצא בשליטתכם.

• RLS ו-FLS מוגדרים בכל entity ונבדקים מול תפקידי משתמש אמיתיים
• כל פונקציית backend נבדקת להזדהות ולהרשאות
• Secrets רק בכספת, ומוחלפים אם הופיעו פעם בפרומפט או בקוד

סביבות, שחרורים ושחזור

מתוכנית Builder ומעלה, Base44 מאפשרת להחזיק נתוני בדיקה נפרדים לגמרי מנתוני הפרודקשן, ולשתף testing link שבו אחרים בודקים שינויים שלא פורסמו מול מסד הבדיקות. האפליקציה שפורסמה תמיד עובדת מול נתוני הפרודקשן. שימו לב שהרצה מקומית של צד הלקוח מול ה-backend המתארח במצב remote כותבת לנתוני הפרודקשן של האפליקציה החיה. לא מצאנו בתיעוד סביבת staging מעבר לנתוני הבדיקה, ולכן כדאי לברר אם זה מספיק לתהליך השחרור שלכם.

בונים את תהליך השחרור סביב זה: review ב-GitHub, בדיקה מול נתוני בדיקה, Publish מכוון ותיעוד של מה שעלה. מכיוון שמודל הנתונים יושב ב-entities של Base44 ולא בקבצי מיגרציה, מנהלים יומן כתוב של שינויי סכמה ובודקים אחרי כל שינוי שהרשומות הקיימות עדיין מתאימות. את הבדיקות האוטומטיות מתחילים מהתהליכים שהכי יכאב אם יישברו: הרשמה, הרשאות ותשלומים.

לפי התיעוד של Base44, גיבויים זמינים בתוכנית Elite עם שמירה ל-7 ימים, ובתוכנית Enterprise עם שמירה ל-30 יום. שמות התוכניות והמגבלות משתנים, אז כדאי לבדוק את עמוד התמחור העדכני. הגיבויים כוללים רק את נתוני הטבלאות; קבצים שהועלו ומשתמשי האפליקציה נשמרים בנפרד ולא נכללים. אם בתוכנית שלכם אין גיבויים, או שחלון השמירה קצר מדי, צריך export קבוע משלכם ושחזור שתורגל בפועל.

תפעול, עלויות והתלות בפלטפורמה

פרודקשן צריך נראות שנמצאת בשליטתכם: error tracking בצד הלקוח ובפונקציות ה-backend, לוגים לאירועים עסקיים חשובים, בדיקות זמינות והתראות שמגיעות לאדם אמיתי. עוקבים אחרי ביצועים ככל שה-entities גדלים, ובודקים איך השימוש מתורגם למגבלות ולקרדיטים של התוכנית, כדי שהעלות לא תפתיע.

אחר כך הופכים את התלות למפורשת. צד הלקוח שבריפו נייד, אבל ה-entities, ההזדהות, הפונקציות והנתונים רצים על התשתית של Base44. פקודת eject יוצרת פרויקט חדש עם backend חדש ב-Base44, ומעתיקה את ה-schemas של ה-entities בלי הנתונים. מלבד שרת פיתוח מקומי, לא מצאנו בתיעוד דרך להריץ את ה-backend מחוץ ל-Base44, ולכן מעבר מלא כדאי לתכנן כמימוש מחדש של ה-backend יחד עם העברת נתונים, ולוודא מול Base44 מה האפשרויות העדכניות. גם להישאר יכולה להיות החלטה נכונה, כל עוד היא מודעת.

פרטיות ורגולציה הולכות אחרי הנתונים. צריך לדעת איפה נשמר מידע אישי, אילו ספקים מעבדים אותו, האם התוכנית שלכם מאפשרת שימוש בנתונים לאימון מודלים ואילו הסכמים חלים. את התשובות בודקים ישירות מול Base44, יחד עם התנאים העדכניים לגבי בעלות על הקוד והתוכן שנוצרים.

מסלול מעשי: בודקים, מאבטחים, מייצבים ואז מגדילים

הסדר חשוב. כל פיצ'ר שנבנה על בסיס שלא נבדק מייקר את התיקונים שיבואו אחריו, ולכן מתחילים בהבנה ובחיזוק של מה שכבר קיים.

• בודקים: מחברים GitHub, ממפים entities, הרשאות, פונקציות, אינטגרציות, secrets ואוטומציות, ומסמנים אילו תהליכים עסקיים נשענים על כל אחד מהם.
• מאבטחים: מגדירים ובודקים RLS ו-FLS בכל entity, מוסיפים בדיקות הרשאה לפונקציות ה-backend, מעבירים secrets לכספת ומריצים את סריקת האבטחה.
• מייצבים: מפעילים נתוני בדיקה, מגדירים תהליך שחרור מבוקר, מוסיפים בדיקות לתהליכים הקריטיים, error tracking, התראות ושגרת גיבוי או export ששוחזרה ממנה בפועל.
• מגדילים: משפרים ביצועים ועלויות, מחליטים במודע מה נשאר ב-Base44 ומה עובר, וממשיכים לפתח על בסיס יציב.

שאלות לשאול לפני השקה

אם התשובה לאחת מהן לא ברורה, זו עבודה שצריך לתזמן לפני שמגיעים משתמשים אמיתיים ונתונים אמיתיים.

• למי שייך ריפו ה-GitHub, ולמי מותר לעשות Publish?
• האם משתמש אחד יכול לקרוא או לשנות רשומות של משתמש אחר דרך ה-API, ולא רק דרך הממשק?
• אילו פונקציות backend רצות בלי הזדהות, והאם זה מכוון?
• איפה נשמרים ה-secrets, והאם מישהו מהם נכתב פעם בפרומפט או בקוד?
• האם התוכנית שלנו כוללת גיבויים שמכסים את צורכי השחזור, כולל קבצים ומשתמשים?
• איך בודקים שינוי בלי לגעת בנתוני הפרודקשן?
• מה יידרש כדי להעביר את ה-backend מ-Base44 אם נצטרך?

איך שותף פיתוח ייעודי ניגש לזה

UVISION לוקחת אחריות ארוכת טווח על תוכנה קריטית לעסק מאז 2012, ואנחנו ניגשים לאפליקציה שנבנתה עם AI כמו לכל מערכת שאנחנו נכנסים אליה. קודם כול בודקים: את הקוד, את מודל הנתונים, את ההרשאות, את תהליך השחרור ואת התהליכים העסקיים שתלויים בהם, וגם כמה מהמערכת תלוי בפלטפורמה. משאירים את מה שעובד, כי חלק גדול ממה שכלי כמו Base44 מייצר הוא נקודת פתיחה סבירה, ומתקנים את החלקים המסוכנים לפני שמרחיבים את ההיקף.

אחר כך ממשיכים לפתח. בכל פרויקט יש לפחות מפתח אחד במשרה מלאה שמכיר את המערכת, כמפתח ייעודי בתוך הצוות שלכם או במסגרת managed engineering שבה אנחנו אחראים על הפיתוח. אנחנו לא מתחייבים ללוחות זמנים או לתוצאות לפני הבדיקה, כי הם תלויים במה שהבדיקה מגלה.