איך בונים מוצר שתלוי ב־API חיצוני בלי לסכן את העסק?

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

מה הסיפור של Twitterrific מלמד על תלות בפלטפורמה?

ב־19 בינואר 2023 הודיעה Iconfactory על סגירת Twitterrific. לפי הודעת החברה, הסיבה הייתה שינוי מדיניות של Twitter שלא הוכרז ולא תועד. הצוות ביקש ממנויי iOS לשקול שלא לבקש החזר, והסביר שהחזרים בהיקף גדול יפגעו בחברה הקטנה. זו הייתה פגיעה במודל העסקי, מעבר לשיבוש טכני שאפשר לתקן בגרסה הבאה.

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

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

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

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

איך מתכננים התנהגות בזמן תקלה?

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

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

מה עשינו באתר Julius כשמקור התוכן אינו זמין?

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

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

מתי כדאי להשקיע באפשרות לעבור לספק אחר?

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

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

מה לבקש מבית התוכנה לפני אישור ההשקה?

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

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