בניית שיתוף פעולה בזמן אמת לתוך אפליקציית AI שבנית (בלי לשבור את העבודה של אחרים)

מה קורה כששני אנשים עורכים את אותה אפליקציה בו־זמנית?

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

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

• משימה 1: קניות
• משימה 2: להתקשר לאמא
• משימה 3: לתאם פגישה

חבר הצוות א’ סימן את “קניות” כבוצע. חבר הצוות ב’ הוסיף “לתקן את הראוטר”. שניהם לחצו על שמירה.

כשחבר הצוות א’ רענן, הוא ראה:

• משימה 1: קניות (מסומן)
• משימה 2: להתקשר לאמא
• משימה 3: לתאם פגישה

“לתקן את הראוטר” נעלם. העבודה של חבר הצוות ב’ התאדתה.

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

מהם באגי שיתוף הפעולה בזמן אמת הנפוצים ביותר?

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

כשל 1: הכתיבה האבודה (אובדן נתונים שקט)

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

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

רוב האפליקציות האמיתיות פותרות את זה על ידי שמירה בכל הקשה על מקלדת, לא רק בלחיצה על “שמור”. Google Sheets, Notion ו-Figma עושים את זה. גם האפליקציה שלך צריכה את ההתנהגות הזו.

כשל 2: הרענון המיושן (רואים נתונים ישנים)

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

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

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

כשל 3: הסתירה המדורגת (שתי אמיתות)

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

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

איך מתקנים באגי שיתוף פעולה בזמן אמת?

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

תיקון 1: זיהוי התנגשויות כתיבה (שמירות מצטברות)

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

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

• השינוי של אדם א’ נכנס ראשון.
• השינוי של אדם ב’ נכנס שני.
• אדם ב’ מנצח (הכתיבה האחרונה מנצחת).

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

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

תיקון 2: רענון בלי לאבד עריכות מקומיות

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

הדרך הלא נכונה: לטעון מחדש את כל הדף. כל העריכות המקומיות נעלמות.

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

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

תיקון 3: הציגו את האמת בבירור

כשיש התנגשות או נתונים מיושנים, הציגו את זה. אל תסתירו.

דוגמאות:

• “המשימה הזו נמחקה על ידי מישהו אחר. לבטל?”
• “מישהו הוסיף שלושה פריטים לרשימה הזו בזמן שהקלדת. [ראו מה חדש]”
• “אתם מסתכלים על גרסה מלפני 2 דקות. רעננו כדי לראות את העדכני ביותר.”

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

איך נראה שיתוף פעולה בזמן אמת כשהוא פתור לגמרי?

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

1. כל הקשה נשמרת מיידית — בלי לחכות לכפתור.
2. התנגשויות נפתרות לפי כלל — אם שנינו עורכים את אותה מילה, המערכת בוחרת מנצח (בדרך כלל הכתיבה האחרונה מנצחת, או שאתם מקבלים הודעת התנגשות).
3. עדכונים מגיעים מיידית — WebSocket, Server-Sent Events, או מסד נתונים שדוחף (כמו Firebase).

לרוב האפליקציות זה לא נחוץ ביום הראשון. התחילו עם שמירות מצטברות (תיקון 1). הוסיפו polling ומיזוג (תיקון 2) כששני אנשים משתמשים בה בו־זמנית. הוסיפו דחיפה מיידית רק אם התנגשויות גורמות לכאב אמיתי.

איך בודקים שיתוף פעולה בזמן אמת לפני ההשקה?

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

מבחן 1: מבחן השמירה במקביל

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

מבחן 2: מבחן הנתונים המיושנים

• פתחו את האפליקציה בחלון 1. אל תיגעו בה.
• בחלון 2, שנו משהו משמעותי (הוסיפו/הסירו שורה, שנו כותרת).
• חִזרו לחלון 1 (עדיין מציג נתונים ישנים).
• נסו לערוך את הגרסה המיושנת בחלון 1.
• עובר: אתם מקבלים אזהרה, או שהמיזוג מתבצע בצורה חלקה. נכשל: אתם דורסים את השינוי מחלון 2.

מבחן 3: מבחן הרענון

• הכינו עבודה משמעותית באמצע (טופס חצי מלא, טיוטת הודעה).
• רעננו את הדף.
• עובר: העבודה שלכם עדיין שם. נכשל: היא נעלמה.

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

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

משתמשים מצפים לזה כיום. Gmail, Google Docs, Slack — כל אפליקציה מודרנית עושה את זה. גם האפליקציה שלכם צריכה.

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