איך אפליקציה עובדת? 30 מונחי פיתוח שכדאי להכיר - חלק 2

בקצרה: כדי לעבוד טוב עם AI על אפליקציה לא צריך לדעת לתכנת, אבל כדאי להבין כמה מונחים: API, Backend, Frontend ו-Database. כאן הסברתי 30 מונחי פיתוח בשפה פשוטה, עם דוגמאות מאפליקציה של מסעדה ופרומפטים מוכנים לעבודה עם AI. בסוף יש גם פרק על API לעסק ועל API לסליקה לעסק קטן.

כשה-AI כותב ״הוספתי Endpoint ב-Backend״, כדאי להבין מה השתנה. לא צריך להפוך למתכנתים כדי לעקוב אחרי העבודה, אבל כמה מושגים הופכים את השיחה לברורה הרבה יותר.

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

איך משתמשים במדריך

1. מחפשים את הרכיב או המושג שמתאים למה שאתם רוצים לבנות.
2. קוראים את ההסבר ומעתיקים את הפרומפט שמתחתיו.
3. מחליפים את הפרטים בדוגמה בפרטים של המוצר שלכם. את שם המונח אפשר להשאיר באנגלית.

החלקים של אפליקציה

התמונה הגדולה: מה רואים, מה פועל בשרת ואיפה נשמר המידע.

1. Frontend - הצד שהמשתמש רואה

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

ב-Frontend תוסיף מסך הזמנה עם רשימת המנות וכפתור "הזמן" בתחתית.

2. Backend - הקוד שמאחורי המסכים

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

ב-Backend תבדוק שהמנה עדיין במלאי לפני שיוצרים את ההזמנה. אל תסתמך רק על בדיקה באפליקציה.

3. Database - בסיס הנתונים

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

כל הזמנה חדשה תישמר ב-Database, עם המשתמש, המנות, הכתובת והסטטוס.

4. API - הממשק בין תוכנות

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

תכין חיבור ל-API של חברת המשלוחים כדי להציג את מיקום השליח על המפה. נתחיל עם סביבת הבדיקה של הספק.

5. Server - שרת

תוכנה שמקבלת בקשות ונותנת שירות, ולעיתים גם הכינוי למחשב שמריץ אותה. ה-Backend יכול לפעול בשרת קבוע או בשירות שמופעל לפי בקשות.

את הכנת ושליחת המיילים תבצע בצד ה-Server, לא מתוך האפליקציה. בפיתוח השתמש בסביבת בדיקה בלי לשלוח ללקוחות אמיתיים.

6. Full Stack - מקצה לקצה

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

תבנה את זה Full Stack: המסך, הקוד בשרת והטבלה ב-Database. תבדוק שהזמנה נשמרת ומופיעה שוב אחרי רענון.

בונים את הממשק בקוד

איך מחלקים מסכים לחלקים ואיך מנהלים את ההתנהגות שלהם.

7. Component - רכיב חוזר

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

תהפוך את כרטיס המנה ל-Component אחד, ותשתמש בו בכל המסכים. את שם המנה, התמונה והמחיר תעביר כנתונים.

8. State - המצב הנוכחי

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

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

9. Routing - מעבר בין מסכים

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

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

10. Responsive - התאמה לגודל מסך

פריסה שמשתנה לפי השטח הזמין. באותו מוצר אפשר להציג כמה טורים במחשב וטור אחד בטלפון.

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

11. Framework - מסגרת עבודה

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

תבנה את האפליקציה ב-Expo כדי להגיע לאייפון ולאנדרואיד. לפני הבנייה תבדוק שהיכולות שאנחנו צריכים נתמכות בשתי הפלטפורמות.

12. Library - ספריית קוד

קוד מוכן שמשלבים בפרויקט עבור יכולת מסוימת. ספרייה יכולה להגיע כ-Package, אבל חבילה יכולה להכיל גם כלי פיתוח או משאבים אחרים.

בשביל המפה תשתמש ב-Library מוכנה. תסביר מה היא דורשת, אילו פלטפורמות נתמכות והאם יש עלות לשירות המפות.

מידע ונתונים

איך מסדרים מידע, מבקשים אותו ושומרים קבצים.

13. Table - טבלה

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

תתכנן Table של הזמנות עם משתמש, כתובת, מחיר וסטטוס, וטבלת פריטים שמחברת כל הזמנה למנות שלה.

14. Schema - מבנה הנתונים

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

לפני שאתה כותב קוד, תציג לי את ה-Schema של כל הטבלאות והקשרים ביניהן. תסביר אילו שדות חובה.

15. Query - שאילתה

בקשה לקריאה או לעיבוד מידע מבסיס הנתונים. למשל עשר ההזמנות האחרונות של המשתמש המחובר.

תכתוב Query שמביא את 10 ההזמנות האחרונות של המשתמש המחובר, מהחדשה לישנה. תוודא שאין גישה להזמנות של משתמש אחר.

16. CRUD - ארבע פעולות על מידע

Create, Read, Update, Delete: יצירה, קריאה, עדכון ומחיקה. אלה הפעולות שמרכיבות הרבה מסכי ניהול.

תבנה CRUD מלא למנות: הוספה, צפייה, עריכה ומחיקה. פעולות השינוי יהיו זמינות רק למנהל מורשה.

17. JSON - פורמט להעברת נתונים

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

תחזיר את רשימת המנות כ-JSON, עם מזהה, שם, מחיר וכתובת תמונה לכל מנה. תתעד את סוג הנתון בכל שדה.

18. Storage - אחסון קבצים

שירות לשמירת תמונות, סרטונים ומסמכים. לעיתים בסיס הנתונים שומר את מזהה הקובץ או את הנתיב אליו; קבצים פרטיים לא חייבים לקבל קישור ציבורי.

את תמונות המנות תשמור ב-Storage, וב-Database תשמור את מזהה הקובץ. תגדיר הרשאות העלאה ותבדוק סוג קובץ וגודל.

משתמשים והרשאות

ההבדל בין לדעת מי נכנס לבין להחליט מה מותר לו לעשות.

19. Authentication - אימות זהות

תהליך שמוודא מי המשתמש, למשל באמצעות סיסמה, קוד חד-פעמי או חשבון חיצוני. מכונה לעיתים Auth.

תוסיף Authentication עם מספר טלפון וקוד אימות ב-SMS. תתחיל בסביבת בדיקה ותגדיר תפוגה והגבלת ניסיונות לקוד.

20. Authorization - הרשאות

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

תגדיר Authorization: רק מנהל יכול לערוך מנות ולשנות מחירים. תאכוף את הכלל בשרת גם אם שולחים בקשה בלי הממשק.

21. Session - מצב התחברות

המנגנון שמקשר בקשות של המשתמש להתחברות שלו. משך התוקף הוא החלטה של המוצר, וצריך גם לאפשר התנתקות וביטול גישה.

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

22. API Key - מפתח גישה לשירות

ערך שמשמש לזיהוי או להרשאה מול שירות. חלק מהמפתחות מיועדים לחשיפה בממשק וחלקם סודיים; צריך לבדוק מה הספק מגדיר לכל מפתח.

את ה-API Key הסודי של שירות התשלומים תשמור רק בשרת. אל תכניס אותו לקוד שנשלח לדפדפן או לאפליקציה.

23. Environment Variables - משתני סביבה

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

את הסודות תשמור במשתני סביבה בצד השרת. אל תוסיף קובצי .env עם סודות ל-Git, ואל תחשוף אותם דרך משתנים ציבוריים של הממשק.

24. Validation - בדיקת קלט

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

לפני יצירת הזמנה תבצע Validation לטלפון, לכתובת ולפריטים. תציג שגיאות ליד השדות ותאכוף את אותם כללים גם בשרת.

חיבורים ועלייה לאוויר

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

25. Endpoint - כתובת לפעולה ב-API

נקודת גישה לפעולה מסוימת, שמוגדרת לרוב בשיטת בקשה ובנתיב. למשל בקשת GET לקריאת סטטוס הזמנה.

תכין Endpoint לקריאת סטטוס הזמנה לפי מזהה. תחזיר נתונים רק לבעל ההזמנה או למנהל מורשה.

26. Webhook - עדכון משירות חיצוני

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

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

27. Git - היסטוריית גרסאות

כלי למעקב אחרי שינויים בקבצים. יוצרים נקודות שמירה באמצעות Commit; הוא לא שומר כל שינוי מעצמו ואינו גיבוי אוטומטי לבסיס הנתונים.

לפני השינוי תבדוק את מצב Git. אחרי הבדיקה תשמור Commit ברור של השינוי, בלי לצרף סודות או קבצים שאינם קשורים.

28. Deploy - הוצאת גרסה לסביבה

העברת גרסה לסביבת הרצה. באתר זה עשוי להיות שרת או שירות אירוח; אפליקציה לחנויות עוברת גם תהליכי בנייה והפצה נפרדים.

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

29. Hosting - אירוח

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

תציע Hosting שמתאים למערכת ותסביר על עלות, מגבלות, לוגים וגיבויים. אל תרכוש או תפעיל תוכנית בתשלום בלי אישור.

30. Domain - שם מתחם

שם קריא שמפנה לשירות, כמו mmn.co.il. הוא חלק מכתובת האתר; הנתיב של עמוד מסוים אינו חלק משם המתחם.

תסביר איך מחברים Domain לאירוח דרך DNS ומוודאים HTTPS. תציג את הרשומות הנדרשות לפני שינוי ההגדרות.

API לעסק: מה זה אומר בפועל

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

כמה דוגמאות ל-API שבעל עסק פוגש:

• סליקה: האתר או האפליקציה מחייבים כרטיס אשראי דרך חברת הסליקה.
• וואטסאפ עסקי: מערכת ששולחת ללקוחות תזכורות ועונה להודעות דרך הפלטפורמה של Meta. כתבתי על זה במדריך Lovable ו-WhatsApp.
• יומן: מערכת תורים שקובעת פגישה ישירות ביומן Google.
• חשבוניות: חשבונית שיוצאת אוטומטית אחרי תשלום.

API לסליקה לעסק קטן: איך זה עובד

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

1. הלקוח לוחץ "לתשלום" באתר או באפליקציה.
2. המערכת שלכם פונה ל-API של חברת הסליקה ופותחת עמוד תשלום שלה, או מציגה את שדות התשלום שלה בתוך העמוד שלכם (iframe).
3. הלקוח מקליד את פרטי הכרטיס אצל חברת הסליקה, ולא בשרת שלכם.
4. חברת הסליקה מאשרת או דוחה, ושולחת למערכת שלכם עדכון אוטומטי (Webhook).
5. המערכת מעדכנת את ההזמנה, ואפשר לשלוח ללקוח אישור וחשבונית.

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

מה לבדוק לפני שבוחרים חברת סליקה

• סביבת בדיקה (Sandbox): מקום לנסות תשלומים בלי כסף אמיתי.
• תיעוד API ציבורי וברור: אם ה-AI בונה את החיבור, הוא צריך לקרוא את התיעוד.
• עמוד תשלום או iframe מוכן: כדי שפרטי הכרטיס לא יעברו אצלכם.
• עדכון אוטומטי אחרי תשלום (Webhook): כדי שההזמנה תתעדכן גם אם הלקוח סגר את הדפדפן.
• חיובים חוזרים (טוקן): אם יש לכם מנוי או תשלום חודשי.
• חשבוניות, Bit ו-Apple Pay: אם אתם צריכים אותם.
• עמלות ועלויות: את זה שואלים ישירות את החברה. המחירים משתנים, ולכן לא כתבתי אותם כאן.

בדקתי ב-20 באוקטובר 2026 את התיעוד הציבורי של שלוש חברות סליקה ישראליות. זו לא המלצה, רק דוגמה למה שתמצאו בתיעוד:

• PayPlus (נפתח בלשונית חדשה): סביבת בדיקה, עמודי תשלום, Hosted Fields, טוקנים, חיובים חוזרים ועדכון IPN אחרי עסקה.
• Tranzila (נפתח בלשונית חדשה): מדריך התחלה מהירה בסביבת בדיקה, חיוב חד-פעמי דרך API, חשבונית אלקטרונית שמחוברת לעסקה, Bit ו-Apple Pay.
• Grow (לשעבר משולם) (נפתח בלשונית חדשה): סביבת בדיקה, תשלום ב-iframe או במעבר לעמוד תשלום, ו-Webhooks.

תכין חיבור ל-API של [שם חברת הסליקה] בסביבת הבדיקה שלהם, לפי התיעוד הרשמי: [קישור לתיעוד]. הלקוח ישלם בעמוד התשלום או ב-iframe שלהם, כך שפרטי הכרטיס לא יעברו בשרת שלנו. תכין Webhook שמעדכן את ההזמנה רק אחרי שאימתת שההודעה הגיעה מחברת הסליקה, ותמנע עדכון כפול. את מפתחות ה-API תשמור רק בשרת. אל תעבור לסביבה אמיתית ואל תחייב כרטיס אמיתי בלי אישור שלי. אם משהו לא ברור בתיעוד, תשאל אותי.

מקורות לפרק הזה: PCI Security Standards Council: PCI DSS (נפתח בלשונית חדשה), מדריך האבטחה של Stripe על PCI DSS (נפתח בלשונית חדשה), והתיעוד של PayPlus, Tranzila ו-Grow שקישרתי למעלה. נבדקו ב-20 באוקטובר 2026.

מחברים את המונחים לבקשה אחת

תכנן אפליקציית מסעדה Full Stack: Frontend עם תפריט ועגלה, Backend שבודק מלאי ומחיר, ו-Database של משתמשים, הזמנות ופריטי הזמנה. תציג קודם Schema וזרימת הזמנה. תכין חיבור תשלומים בסביבת בדיקה ו-Webhook עם בדיקת חתימה ומניעת כפילויות. הלקוח יראה רק את ההזמנות שלו, ורק מנהל יוכל לשנות מנות. אל תחייב, תשלח הודעות או תעלה גרסה לאוויר בלי אישור מפורש.

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

לדרך העבודה המלאה, מהתכנון ועד הבדיקות והעיצוב, המשיכו לבניית אפליקציה עם AI ב-7 שלבים.

רוצים להעמיק? קלוד קוד למתחילים, מה זה וייב קודינג ובניית אפליקציה עם AI ב-7 שלבים. ואם אתם רוצים לבנות את האפליקציה יחד איתי: פיתוח אפליקציות AI לעסקים.