מה באמת יש בתוך אפליקציה שנבנתה עם בינה מלאכותית: סיור ללא-מתכנתים

הקלדתם תיאור, לחצתם “צא לדרך”, ועשרים דקות לאחר מכן הייתה לכם אפליקציה שעובדת. נהדר. אבל עכשיו לחצתם “הצג קבצים” ואתם בוהים בעץ תיקיות שנראה כאילו נכתב בשפה אחרת. מה זה package.json? למה יש ארבעים דברים ב-node_modules? מה “schema” אומר ולמה יש לכם אחד?

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

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

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

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

ה-frontend: מה שהלקוח שלכם באמת רואה

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

עבור מאיה, ה-frontend הוא טבלת מובילים עם דירוג, שם, ומספר הפניות. עבור ג’ורדן, זה יומן של שיעורים עם כפתור “הזמן”. עבור סם, זו רשימה של מאפים עם כפתורי פלוס ומינוס קטנים ליד כל אחד.

בתוך הפרויקט, ה-frontend בדרך כלל חי בתיקייה שנקראת משהו כמו app/, pages/, או src/. תראו קבצים שמסתיימים ב-.tsx או .jsx. כל אחד הוא בערך “מסך אחד” או “חלק אחד של מסך”. שורת טבלת המובילים היא קובץ אחד. ה-header הוא קובץ אחר. העמוד שקושר את הכול יחד הוא שלישי.

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

ה-backend: החלק שחושב

ה-backend הוא החלק שאף אחד לא רואה, אבל כולם תלויים בו. זה הקוד שרץ במקום אחר — על שרת, לא בדפדפן של הלקוח — כשמשהו צריך לקרות שאי אפשר לסמוך על הדפדפן של הלקוח לעשות לבדו.

למה הדפדפן לא יכול לעשות הכול? כי הדפדפן הוא המכונה של הלקוח, ואי אפשר לסמוך עליו. אם טבלת המובילים של מאיה הייתה מעדכנת ספירת הפניות אך ורק בדפדפן, כל אחד יכול היה ללחוץ קליק ימני ולהוסיף לעצמו 9,000 הפניות. אז ה-backend הוא איפה שהכללים חיים: “האדם הזה יכול לעשות את זה, אבל לא את זה”, “באמת תשמור את זה למסד הנתונים”, “תשלח את המייל הזה”.

ה-backend בדרך כלל חי בתיקייה שנקראת api/, server/, או app/api/. הקבצים שם בדרך כלל קצרים. כל אחד מטפל בבקשה ספציפית: “צור הזמנה”, “הצג את הקרואסונים של היום”, “הוסף הפניה”.

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

מסד הנתונים: הזיכרון של האפליקציה שלכם

דמיינו את הזיכרון של האפליקציה שלכם כשורה של ארונות תיוק. לכל ארון יש תווית בחזית. אחד אומר “users”. אחד אומר “bookings”. אחד אומר “croissant_orders”. בתוך כל ארון, כל מגירה היא שורה אחת. לכל מגירה יש את אותו סט של חריצים: שם, מייל, created_at, סטטוס.

המבנה הזה — “אילו ארונות קיימים, אילו חריצים יש לכל שורה” — נקרא schema. זה הקובץ הכי חשוב בפרויקט, גם אם הוא גם כנראה הכי משעמם-למראה. מצאו קובץ שנקרא schema.ts, schema.prisma, או משהו בתוך תיקייה בשם db/ או migrations/. פתחו אותו. תראו רשימה שמשקפת את מה שהאפליקציה שלכם באמת זוכרת על העולם.

ל-schema של ג’ורדן יש טבלת classes, טבלת bookings, וטבלת users. לשל סם יש products, orders, ו-order_items. לשל מאיה יש members ו-referrals. הצורה של ה-schema היא הצורה של המוצר, ולכן לשנות אותו אחר כך קשה יותר מלשנות איך הכפתורים נראים.

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

Auth: השומר בדלת

“Auth” הן שתי מילים שמודבקות יחד: authentication (מי אתה?) ו-authorization (מה מותר לך לעשות?). שתיהן בדרך כלל מטופלות על ידי קבוצה קטנה של קבצים בתיקייה שנקראת auth/, או על ידי שירות ששמו אולי מוכר לכם: Clerk, Auth0, Supabase Auth, NextAuth.

שתי השאלות שונות. Authentication עונה: “האם זו באמת מאיה?” — בדרך כלל עם סיסמה, התחברות גוגל, או קישור קסם שנשלח לה במייל. Authorization עונה: “האם מותר למאיה למחוק את ההפניות של אנשים אחרים?” — והתשובה הכנה לרוב האפליקציות שנבנו עם בינה מלאכותית בשבוע הראשון שלהן היא “שכחנו לבדוק”.

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

אינטגרציות: הדברים שלא בניתם אבל אתם משתמשים בהם בכל זאת

כאן רוב הלא-מתכנתים מזלזלים במה שבאמת קורה. הדבר ששולח את המייל “הקרואסונים שלכם מוכנים” של סם אינו קוד — הוא חשבון ב-SendGrid או ב-Resend. הדבר שמעבד את התשלום על שיעור של ג’ורדן אינו קוד — הוא Stripe. הדבר שמארח את התמונות בטבלת המובילים של מאיה אינו קוד — הוא שירות אחסון כמו S3 או Cloudinary.

כל אינטגרציה מופיעה בשני מקומות. יש פיסת קוד קטנה ב-backend שאומרת “היי, Stripe, תחייב את הכרטיס הזה”. ויש מפתח — מחרוזת סודית ארוכה — שנשמר במקום בטוח (בדרך כלל קובץ שנקרא .env שאף אחד לעולם לא צריך לבצע לו commit) שמוכיח ל-Stripe שהבקשה הגיעה מהמאפייה של סם ולא מזר.

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

ה-deploy: איך זה מגיע לאינטרנט

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

• המארח (host): שירות כמו Vercel, Netlify, Fly, או Render שמריץ את ה-backend שלכם ומגיש את ה-frontend שלכם.
• הדומיין: שם כמו mayas-leaderboard.com שמצביע על המארח שלכם.
• ה-build: המתכון שלוקח את קבצי המקור המבולגנים שלכם והופך אותם לגרסה הרזה והמהירה יותר שבאמת רצה.

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

ההרגל של חמש דקות שמשתלם בעצמו

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

מאיה עושה את זה כל יום שישי אחר הצהריים. היא מקלידה: “מה השתנה ב-schema השבוע, ולמה?” ו: “האם יש אינטגרציות חדשות באפליקציה הזו שלא ביקשתי?” התשובות כמעט תמיד מרגיעות. בפעמים המעטות שהן לא, היא תופסת בעיות בזמן שהן עדיין קטנות.

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

לאן ללכת הלאה

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