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

הרגע שבו מתחילים לתהות

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

האפליקציה שלכם עובדת. משתמשים נרשמים. פיצ’רים יוצאים לדרך. ואז מתחילה להתגנב אליכם ההרגשה הזאת: לא אמור להיות פה “בקאנד אמיתי”? כולם מדברים על בקאנדים. לאפליקציות רציניות יש בקאנדים. הבילדר שלכם נתן לכם משהו מבוסס TypeScript-in-React, ומתחילה לנקר בכם המחשבה שאולי זה לא… מקצועי מספיק.

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

הפוסט הזה עוסק בלדעת להבחין בין השניים.

למה בקאנד בכלל קיים?

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

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

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

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

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

איך יודעים שבאמת צריכים בקאנד?

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

“זה איטי.” אם משתמשים מדווחים על איטיות, הבעיה היא בדרך כלל אחד משלושה דברים: הדפדפן עושה יותר מדי עבודה (מוגבל על ידי המעבד, אלגוריתם גרוע, רינדור יתר של ה-DOM), הרשת איטית (עצוב אבל נכון), או מסד הנתונים איטי (יותר מדי שאילתות, אינדקסים שגויים - האפליקציה שלכם שנבנתה עם AI כבר מדברת עם מסד נתונים, בדרך כלל טוב). בקאנד אמיתי לא יתקן עבודת מעבד שמתבצעת בדפדפן. בקאנד אמיתי לא יתקן latency ברשת (הפיזיקה קשה). בקאנד יכול לעזור עם שאילתות מסד נתונים על ידי הוספת caching או דפוסי שאילתה חכמים יותר, אבל הבילדר שלכם כנראה כבר חשב על זה.

סיפור אמיתי על איטיות: אפליקציית משימות הייתה איטית בטעינת הרשימה. המפתח חשב “אני צריך בקאנד אמיתי.” הבעיה בפועל: האפליקציה טענה את כל 5,000 המשימות, בכל פעם, במקום לטעון רק 50 הראשונות עם כפתור “טען עוד.” תוקן בתוך אחר צהריים אחד בלי לגעת בבקאנד. הבקאנד לא היה הבעיה.

“אני רוצה להריץ קוד שהמשתמש לא אמור לראות.” זו הסיבה היחידה שבאמת הגיונית, והיא נדירה יותר משאתם חושבים. דוגמאות: שליחת אימייל אחרי שמשתמש נרשם (אתם רוצים שהקוד הזה ירוץ גם אם הוא סוגר את הלשונית), הרצת job ברקע שמעבד קבצים במהלך הלילה, קריאה ל-API חיצוני על פי לוח זמנים. אלה סיבות תקפות. אתם באמת צריכים משהו שרץ על שרת כלשהו. אבל זה לא חייב להיות בקאנד מלא עם אימות וניתוב ומסדי נתונים. זה יכול להיות “cloud function” בודדת שרצה על פי לוח זמנים או מופעלת על ידי webhook. הרבה יותר פשוט מבקאנד שלם.

“כמה משתמשים משנים את אותם נתונים באותו זמן ואני מאבד עדכונים.” זה אמיתי. אם אתם רואים “העריכות של אליס נעלמו” או “שני אנשים ערכו את אותו טופס והשינויים של השני דרסו את הראשון,” יש לכם בעיית contention. חלק ממסדי הנתונים מטפלים בזה טוב יותר מאחרים, וחלק מבילדרי ה-AI ברירת המחדל שלהם היא מסדי נתונים שלא. אבל התיקון לא תמיד הוא בקאנד שלם - זה יכול להיות החלפת מסד הנתונים, הוספת נעילה, או הוספת concurrency אופטימי (מונח מפוצץ ל”שמרו את מספר הגרסה הישן והשוו לפני שמאפשרים עדכון”). שאלו את הבילדר שלכם אם הם יכולים להחליף מסדי נתונים או להוסיף מעקב גרסאות. ייתכן שאתם לא צריכים בקאנד; אתם צריכים הגדרת מסד נתונים חכמה יותר.

מה נראה כמו בעיית בקאנד, אבל לא?

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

“הקוד הוא JavaScript והכל במקום אחד.” הרבה אפליקציות מצליחות הן JavaScript בדפדפן, שמדבר עם מסד נתונים אמיתי (Firebase, Supabase, MongoDB Atlas, מה שהבילדר שלכם הגדיר). אין “בקאנד אמיתי” בתור שרת. הכל עובד. העובדה שהקוד נמצא בשפה אחת במקום אחד לא אומרת שהוא לא אמיתי. JavaScript עובד.

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

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

עץ ההחלטות הכן

הנה איך לפצח את זה בלי לנחש:

האם האפליקציה שלכם יכולה לעשות מה שהיא עושה כרגע, בלי בקאנד? אם כן, עברו ל-2. אם לא, כבר יש לכם בקאנד (או שאתם צריכים לבנות אחד). המשיכו. (ייתכן שלאפליקציה שנבנתה עם AI כבר יש אחד.)
האם הדבר שאתם רוצים להוסיף הוא משהו שהדפדפן ביסודו לא יכול לעשות? לחייב כסף? בהחלט. לשלוח אימייל? כן. לקרוא ל-API חיצוני עם מפתח סודי? כן. משהו אחר? כנראה שלא. אם זה משהו שהדפדפן יכול לעשות אבל זה איטי, עברו ל-3. אם זה משהו שהדפדפן לא יכול לעשות, אתם צריכים בקאנד.
האם האיטיות נעלמת אם אתם מתקנים את הבעיה בפועל? לטעון פחות דברים? לעשות caching חכם יותר? לאגד בקשות? להשתמש במסד נתונים טוב יותר? הטריק הוא: לגלות קודם מה באמת איטי. הוסיפו בקאנד רק אחרי שמיציתם את התיקונים הברורים. כי הוספת בקאנד לא מתקנת אלגוריתם איטי - היא רק מזיזה אותו למחשב אחר.
אם תוסיפו בקאנד, האם זה באמת פותר את הבעיה? זו המלכודת. אתם מוסיפים בקאנד כדי “לשפר ביצועים,” וה-latency דווקא מחמיר כי עכשיו אתם עושים קריאות רשת לבקאנד שלכם, שעושה קריאות רשת למסד הנתונים, מה שיכולתם לעשות מהדפדפן בקפיצה אחת. מדדו קודם. הוסיפו אחר כך.

אתם צריכים בקאנד מלא או רק cloud function?

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

חשבו על מה שאתם רוצים שהבקאנד יעשה. עכשיו דמיינו כותבים את זה כפונקציית JavaScript בודדת (אולי 100 שורות) שרצה כמה שניות כשקוראים לה, ואז נעצרת. האם זה נכנס לתוך התיבה הזאת?

לטפל ב-webhooks של תשלומים? כן.
לשלוח אימייל ברוכים הבאים? כן.
לוודא קובץ לפני העלאה? כן.
להריץ דוח לילי? כן (במידה מסוימת - הייתם קוראים לזה על פי לוח זמנים).

אם התשובה חיובית, אתם לא צריכים “בקאנד אמיתי.” אתם צריכים cloud function. Vercel, AWS Lambda, Google Cloud Functions, מה שלא יהיה. זה זול יותר, פשוט יותר, ואתם לא צריכים לשמור על שרת.

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

השאלה האמיתית לשאול את הבילדר שלכם

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

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

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

לרוב האפליקציות המצליחות שנבנות על ידי אדם אחד אין “בקאנד אמיתי” במובן שאתם מדמיינים. יש להן מסד נתונים (הבילדר שלכם כנראה הגדיר את זה). ייתכן שיש להן פונקציה או שתיים שרצות על פי לוח זמנים. אבל הקוד שרץ בדפדפן עושה את העבודה, מדבר עם מסד הנתונים ישירות, ומוציא פיצ’רים לדרך בלי שכבה אמצעית.

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

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