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

מה זה "צד השרת" (backend) ב-⁠Base44

כשבונים ב-⁠Base44 אף פעם לא מקימים שרת, אבל לאפליקציה יש שרת. זה שירות משותף ומנוהל שכל אפליקציות ה-⁠Base44 מדברות איתו, והוא ממלא שמונה תפקידים:

1. שומר את הנתונים שלכם במסד נתונים של מסמכים, שמאורגן בישויות (entities), כלומר בטבלאות.
2. מטפל בהתחברות: הרשמה, סיסמאות, קודים חד-פעמיים, איפוס סיסמה, והתחברות עם חשבונות כמו Google.
3. אוכף את כללי האבטחה שלכם בכל בקשה, ומחליט מי יכול לראות ולשנות אילו רשומות ושדות.
4. מריץ את פונקציות השרת שלכם, קוד TypeScript שרץ ב-⁠Deno.
5. מריץ אוטומציות ותהליכי עבודה (workflows) לפי תזמונים ובתגובה לשינויים בנתונים.
6. מספק אינטגרציות מובנות: שליחת אימייל, קריאה למודלי שפה גדולים, יצירת תמונות, טיפול בהעלאת קבצים.
7. מחזיק את הטוקנים של הקונקטורים לשירותים כמו Gmail, ‏Google Calendar או Slack.
8. שולח עדכונים בזמן אמת לדפים פתוחים כשהנתונים משתנים.

האחסון נמצא לצד כל זה. ההוראות של Base44 לחיבור דומיין חיצוני מפנות את ה-⁠DNS שלכם ל-base44.onrender.com, כלומר אפליקציות שפורסמו מוגשות דרך Render.

הטכנולוגיות של Base44, והשפות שמאחוריהן

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

מהטבלה הזו נובעים כמה דברים:

• אי אפשר לבחור את השפה. ה-⁠AI כותב React ב-⁠JavaScript, והפונקציות הן TypeScript על Deno. התיעוד של Base44 לא מתאר פונקציות בשום שפה אחרת. מערכות אחרות עדיין יכולות להגיע לנתונים של האפליקציה: הדף API בלוח הבקרה נותן קטעי קוד מוכנים ל-⁠SDK של JavaScript, ל-fetch רגיל ב-⁠JavaScript, ל-⁠cURL ול-⁠Python.
• מסד הנתונים הוא החלק שאתם לא רואים. Base44 אומרת שהוא תואם MongoDB, אבל לא איזה מסד נתונים זה, או איפה הוא רץ מעבר לאזור (ארה״ב כברירת מחדל).
• החלקים עצמם רגילים. React, ‏Vite, ‏Tailwind, ‏Deno ומסמכים בסגנון MongoDB נפוצים מאוד גם מחוץ ל-⁠Base44. כל מי שמפתח ב-⁠React יכול לקרוא את צד הלקוח, והפונקציות הן TypeScript סטנדרטי. מה שקושר את האפליקציה ל-⁠Base44 הוא ה-⁠SDK והשירותים שמאחוריו, ובהם עוסק שאר המאמר.

איך הנתונים נשמרים: ישויות

Base44 מתארת כל ישות כסכמה של מסמכים באוסף (collection), שנשמרים במסד נתונים NoSQL תואם MongoDB, כך שאפליקציות יכולות להשתמש באופרטורי שאילתה של MongoDB דרך ה-⁠SDK (סקירת הישויות). בפועל זה אומר:

• רשומות הן מסמכים, לא שורות בטבלה קבועה. רשומה יכולה להכיל אובייקטים ורשימות מקוננים, ואפשר לשנות את הסכמה בכל רגע, בלי להסב את הנתונים הקיימים (migration). Base44 מציגה את הגמישות הזו כיתרון.
• לכל רשומה יש שדות מובנים לצד השדות שלכם, כמו המזהה שלה, תאריכי היצירה והעדכון, ו-created_by, ששומר את כתובת האימייל של מי שיצר אותה.
• קשרים הם הפניות. כשהזמנה שייכת ללקוח, ההזמנה שומרת את המזהה של הלקוח בשדה. שום דבר במסד הנתונים לא מוודא שהלקוח קיים; הקוד של האפליקציה הוא ששומר על העקביות.
• מחיקה היא רכה בהתחלה. רשומות שנמחקו נשמרות 30 יום, ואפשר לשחזר אותן מ-Recently deleted (נמחקו לאחרונה); אחרי זה הן נמחקות לצמיתות (ניהול הנתונים של האפליקציה).

כללי האבטחה יושבים ליד הנתונים

כל ישות יכולה לכלול כללי אבטחה ברמת השורה וברמת השדה (אבטחת ישויות). כללים ברמת השורה קובעים מי רשאי ליצור, לקרוא, לעדכן או למחוק רשומה; כללים ברמת השדה קובעים מי רשאי לקרוא או לכתוב שדה מסוים.

כלל הוא true (כולם), false (אף אחד) או תנאי. תנאים משווים את הרשומה למי ששואל, למשל "ה-created_by של הרשומה שווה לאימייל של המשתמש המחובר", או בודקים את המשתמש ישירות, למשל "התפקיד של המשתמש הוא admin". כללים יכולים להתייחס לשדות שלכם ולשדות משתמש מותאמים, ולשלב תנאים עם $or, ‏$and ו-$nor.

Base44 אוכפת אותם בשרת שלה, בכל בקשה, ובקריאות היא נכשלת בשקט: רשימה או סינון שהכללים חוסמים חוזרים ריקים במקום להחזיר שגיאה, ו-get שנחסם מחזיר "not found" (לא נמצא) בין אם הרשומה קיימת ובין אם לא. יצירה ועדכון שנחסמו מחזירים שגיאת הרשאה. ההתנהגות הזו היא חלק מהלוגיקה של האפליקציה, בין אם תכננתם אותה כך ובין אם לא, וכל מעבר לצד שרת אחר צריך לשחזר אותה בדיוק, אחרת נתונים ידלפו או ייעלמו.

איך האפליקציה מדברת עם צד השרת

כל פעולה על נתונים בדפים שלכם עוברת דרך ה-⁠SDK של Base44: list, ‏filter, ‏get, ‏create, ‏update, ‏delete ו-subscribe על כל ישות; functions.invoke לפונקציות שרת; integrations.Core.* לאינטגרציות המובנות. כל קריאה הופכת לבקשת HTTP ל-⁠API של Base44, מאומתת בשם המשתמש המחובר.

מגבלה אחת משפיעה על כמעט כל אפליקציה עם הרבה נתונים: בקשה אחת מחזירה לכל היותר 5,000 פריטים, כלל ש-⁠Base44 הנהיגה ב-⁠27 בנובמבר 2025. התיעוד של ה-⁠API לניהול מוסיף שהתשובה לא מציינת שהיא נחתכה (Apps API: ישויות). דף שטוען אוסף שלם פשוט נעצר ב-⁠5,000, ולכן דוחות, ייצוא ולוחות בקרה שבנויים על "להביא הכול" הופכים בשקט לשגויים ככל שהאפליקציה גדלה. הפתרון הוא חלוקה לעמודים (pagination).

דרכים להגיע לנתונים שלכם

מה שלא תמצאו הוא מחרוזת חיבור (connection string) למסד הנתונים. Base44 לא מתעדת שום דרך לחבר תוכנת לקוח של מסד נתונים, כלי BI או משימת גיבוי ישירות למסד הנתונים. הכול עובר דרך ה-⁠API.

מגבלות הקצב של ה-⁠API לניהול נספרות לכל סביבת עבודה, לא לכל אדם, עם מכסת בסיס ל-⁠Free ול-⁠Starter שמוכפלת פי 2 ב-⁠Builder, פי 3 ב-⁠Pro, פי 5 ב-⁠Elite ופי 10 ב-⁠Enterprise (מגבלות קצב). רשימה וספירה של רשומות חולקות מכסת בסיס של 70 בקשות לדקה לכל אפליקציה.

גיבויים ושחזור

Base44 שומרת רשומות שנמחקו 30 יום. מעבר לזה, גיבויים אוטומטיים, שבהם אפשר לעיין במצבים קודמים של הטבלאות, להוריד אותם ולשחזר אותם, הם יכולת של Elite ו-⁠Enterprise, ונשמרים 7 ימים ב-⁠Elite ו-⁠30 יום ב-⁠Enterprise (גיבוי ושחזור). הם מכסים רק רשומות בטבלאות, לא קבצים שהועלו ולא את המשתמשים של האפליקציה. במסלולים האחרים, אסטרטגיית הגיבוי שלכם היא מה שאתם מייצאים בעצמכם, ובפועל: ייצוא CSV או סקריפט מול ה-⁠API.

משתמשים והתחברות

המשתמשים של האפליקציה נמצאים בקטע Users (משתמשים), עם תפקיד (admin או user, או תפקיד מותאם) וכל שדה מותאם שתוסיפו. ההתחברות יכולה להיות עם אימייל וסיסמה, Google, ‏Microsoft, ‏Facebook או Apple, ועם single sign-on במסלולי Enterprise של Base44 (Business או Enterprise; סביבות עבודה שנוצרו לפני 1 באוקטובר 2026 שומרות על הדרישה הקודמת, Elite ומעלה) (ניהול התחברות והרשמה).

שני פרטים חשובים אם תעברו אי פעם:

• אי אפשר לייצא סיסמאות. Base44 לא מוסרת hash של סיסמאות, ותיעוד הפרטיות שלה אומר שאי אפשר לייצא את משתמשי האפליקציה בכלל.
• התחברות עם Google רצה בדרך כלל על לקוח ה-⁠OAuth של Base44 עצמה. בהגדרת ברירת המחדל מופיע base44.com במסך ההסכמה של Google; לקוח Google OAuth מותאם, שמציג את הדומיין שלכם, דורש מסלול Builder ומעלה.

פונקציות, אוטומציות ותהליכי עבודה

פונקציות שרת הן TypeScript שרץ על Deno, זמינות במסלול Builder ומעלה, עם זמן ריצה מרבי של 5 דקות לכל הפעלה, בין אם הן נקראות ישירות, על ידי אוטומציה או כשלב בתהליך עבודה (פונקציות שרת).

אפליקציות שנוצרו לפני יולי 2026 עשויות להשתמש באוטומציות: פונקציה שרצה לפי תזמון או בתגובה לשינויים בנתונים, כשכל הרצה יכולה להימשך עד 3 דקות, ובין הרצה להרצה חייבות לעבור לפחות 5 דקות (יצירת אוטומציות). אפליקציות חדשות יותר משתמשות בתהליכי עבודה, שמחברים שלבים לשרשרת, עם תנאים והשהיות. עליהם כתבנו במדריך העברת תהליכי עבודה מ-⁠Base44.

הפונקציות קוראות את המפתחות הסודיים (secrets) שלהן, כמו מפתח של Stripe, ממשתני סביבה. השמות של המפתחות הסודיים גלויים בלוח הבקרה וב-⁠API של Base44; הערכים שלהם ניתנים לכתיבה בלבד, וזה משנה בהמשך, אם הפונקציות צריכות לרוץ במקום אחר.

מה זה אומר אם אתם רוצים לעבור

צד השרת הוא המקום שבו נמצאת בפועל הנעילה בפלטפורמה (lock-in) של Base44. קוד צד הלקוח שלכם נייד, עקרונית; ההתנהגות של צד השרת היא מה שהקוד שלכם תלוי בו: נתונים בצורת מסמכים עם שאילתות בסגנון MongoDB, כללי אבטחה ב-⁠JSON עם הסמנטיקה המדויקת של Base44, שירות התחברות שמחזיק את כל הסיסמאות, ופונקציות שנכתבו מול ה-⁠SDK של Base44.

מעבר למסד נתונים רלציוני כמו Postgres אומר לתרגם כל אחד מאלה, ולשכתב את הקוד שמשתמש בהם. מעבר לצד שרת שעונה על אותו API, על אותו סוג של מסד נתונים, אומר שלא צריך לתרגם שום דבר מזה. בגישה השנייה Unbase44 עובד: הרשומות נכנסות ל-⁠MongoDB שלכם עם המזהים המקוריים שלהן, שרת מתועד שתואם ל-⁠Base44 אוכף את אותם כללים, והמשתמשים שומרים על הסיסמאות שלהם.