מדריך מקצועי קצר

המשך פיתוח לאפליקציה שנבנתה ב־Base44

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

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

מתי צריך מפתח לאפליקציית Base44?

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

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

מה אפשר לעשות בלי לעזוב את Base44?

Base44 מייצר frontend ב־React ופונקציות backend, ובתוכניות בתשלום אפשר לסנכרן אותם דו־כיוונית עם GitHub או להוריד ZIP. כך מפתח יכול לעבוד על אותה אפליקציה מקומית, לשמור היסטוריית שינויים ולמזג חזרה לעורך של Base44.

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

איך איתי קרקסון ממשיך פיתוח של אפליקציית Base44?

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

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

מתי באמת שווה לעבור מ־Base44 לתשתית אחרת?

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

מעבר כזה הוא פרויקט: מייצאים כל טבלה בנפרד, מחליפים את כל קריאות ה־SDK בקוד משלכם, ומתכננים איפוס סיסמה לכל המשתמשים, כי ה־hash של הסיסמאות לא ניתן לייצוא. פקודת base44 eject לא מוציאה את האפליקציה מהפלטפורמה: היא יוצרת אפליקציה חדשה על Base44 עם מסד נתונים ריק.

רכיבים שצריך לתכנן

גישה לקוד

חיבור ל־GitHub ועבודה עם היסטוריית שינויים במקום שינויים עיוורים.

מיפוי נתונים

אילו ישויות קיימות, מי רואה מה ואיפה הלוגיקה העסקית יושבת.

פיצ׳רים ואינטגרציות

סליקה, CRM, מייל, API חיצוני או שכבת AI.

בדיקות לפני עלייה

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

שאלות נפוצות

האם צריך לבנות את האפליקציה מחדש?

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

האם אפשר לעבור מ־Base44 לתשתית אחרת?

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

האם אפשר להמשיך להשתמש ב־AI של Base44 אחרי שמפתח נכנס?

כן. שינויים בעורך נשמרים כ־commits ב־GitHub, ושינויים שממוזגים ל־main חוזרים לעורך. כדאי לא לשנות ידנית קבצים שהעורך מנתח, כמו הגדרות ה־entities, כדי לא לשבור את הסנכרון.

מקורות למחקר

העמוד נבנה כמדריך קצר על בסיס מחקר NotebookLM ומקורות מקצועיים. המקורות המרכזיים:

יש לכם אפליקציה ב־Base44 שצריכה להמשיך?

אפשר להתחיל מסקירה קצרה של האפליקציה ומה צריך להשתנות.

השאירו פרטים