כלים בצד השרת מול צד הלקוח: מי מריץ, ומי יכול לעצור

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

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

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

הבלבול שכדאי להסיר

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

למה ההבדל חשוב

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

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

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

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

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

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

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

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

מלכודת במריץ הכלים

מריץ הכלים של ה-SDK מקבל גם כלים בצד השרת במערך. הוא לא ממשיך אוטומטית אחרי השהיה: הוא ממשיך רק אחרי שכלי בצד הלקוח החזיר תוצאה.

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

מה שנשאר לשקול

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