פיתוח API של WebSocket לאפליקציות מובייל

תארו לעצמכם: משתמש פותח צ'אט ברכבת התחתית, שולח הודעה—והיא אובדת כי הטלפון עבר מ-LTE ל-Wi-Fi. או אפליקציית iOS ברקע מקבלת push, אבל כשהמשתמש חוזר, הנתונים לא מתעדכנים. זה קלאסי: ללא WebSocket API מעוצב היטב, כל שינוי רשת הופך לאובדן אירועים. אנחנו בונים פתרונות זמן-אמת לפלטפורמות ניידות מאז 2019, השלמנו 25+ פרויקטים ב-iOS ו-Android—ואנחנו יודעים איך לתכנן API שעומד בניתוקים ללא אובדן.

הנתונים שלנו מראים: WebSocket API מיושם כראוי עם replay מפחית אובדן הודעות ב-95% אפילו תחת מעברי רשת תכופים. WebSocket יעיל פי 10 מ-polling קלאסי מבחינת תעבורה ופי 5 מהיר יותר בזמן אספקה. להלן פתרונות ארכיטקטוניים שנבדקו בייצור.

פרוטוקול מעל WebSocket

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

{ "type": "message.new", "id": "uuid-v4", "payload": { ... }, "timestamp": 1711234567890 } 

{ "type": "message.new", "id": "uuid-v4", "payload": { ... }, "timestamp": 1711234567890 } —ניתוב בצד הלקוח. type—אידמפוטנטיות: הלקוח מתעלם מכפילויות בעת חיבור מחדש. id—סנכרון מצב.

פרוטוקולים פופולריים מעל WebSocket: STOMP (עובד היטב עם Spring Boot, מערכת אקולוגית עשירה של לקוחות), Socket.IO (גיבוי polling, חדרים מובנים, אבל קשור למערכת האקולוגית של JS), פרוטוקול מותאם אישית (שליטה מקסימלית, אבל יותר עבודה בכל הרמות). השוואה:

פרוטוקול מותאם אישית באמצעות Protobuf או MessagePack חוסך עד 40% תעבורה בהשוואה למסגרות JSON של STOMP—קריטי לאפליקציות ניידות עם תוכניות נתונים מוגבלות.

איך לשחזר מצב לאחר ניתוק?

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

בצד השרת: לכל אירוע יש timestamp או sequence עולה מונוטונית. בעת חיבור מחדש, הלקוח שולח את ה-cursor האחרון שהתקבל:

{ "type": "subscribe", "channel": "chat.123", "lastSeq": 4521 } 

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

ללא מנגנון זה, כל שבירת חיבור פירושה הודעות שהוחמצו—קריטי במיוחד ב-Android עם Doze Mode. הניסיון שלנו מראה: replay מיושם כראוי מפחית אובדן נתונים ב-95% אפילו תחת ניתוקים תכופים.

אימות והרשאות

חיבור WebSocket מאומת בעת handshake באמצעות פרמטר שאילתה או הודעה ראשונה:

wss://api.example.com/ws?token=eyJ... 

פרמטר שאילתה פשוט יותר, אבל הטוקן מגיע ללוגים. מועדף: יצירת חיבור, שליחת מסגרת { "type": "subscribe", "channel": "chat.123", "lastSeq": 4521 } עם טוקן, המתנה ל-seq > 4521 מהשרת לפני כל הרשמות.

פגיית טוקן במהלך סשן היא תרחיש אמיתי. השרת צריך לשלוח אזהרת wss://api.example.com/ws?token=eyJ... 60 שניות לפני הפגייה; הלקוח מביא טוקן חדש ושולח מסגרת auth חדשה מבלי לשבור את החיבור.

קנה מידה של השרת האחורי

מופע שרת יחיד אינו יכול להחזיק את כל חיבורי הלקוחות. תחת קנה מידה אופקי, הודעה שמגיעה לשרת A חייבת להגיע ללקוחות בשרתים B ו-C. פתרון סטנדרטי: pub/sub באמצעות Redis (auth_ok/token_expiring). כל שרת נרשם לערוצים ומעביר הודעות ללקוחות ה-WebSocket שלו.

חלופות תשתית: Ably (תשתית WebSocket מתארחת), Pusher Channels, AWS API Gateway WebSocket—הן מפחיתות עומס תפעולי במחיר של עלות ופחות שליטה. אם תבחרו בפתרון מתארח, צפו ל-vendor lock-in ולעלויות נוספות תחת עומס גבוה. השוואה:

יישום לקוח

ב-Android—OkHttp auth עם PUBLISH ל-heartbeat. ב-iOS—SUBSCRIBE. פרטי יישום מכוסים במאמר על צ'אט WebSocket. חשוב: בעת תכנון ה-API, הסכימו על גודל הודעה מקסימלי (מגבלת מסגרת WebSocket), פורמט שגיאות, וסגירת חיבור מנומסת (WebSocket לעומת pingInterval).

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

פרוטוקול מותאם אישית חוסך עד 40% תעבורה בהשוואה למסגרות JSON של STOMP, ואתם לא קשורים לספריות צד שלישי. עם זאת, הוא דורש פי 2–3 יותר זמן פיתוח. אם יש לכם לוגיקה פשוטה (סוג אירוע אחד, עומס נמוך)—Socket.IO או STOMP מספיקים. אם האפליקציה רגישה לתעבורה ולזמן השהיה—אנחנו כותבים פרוטוקול מותאם אישית על Protobuf או MessagePack.

מה כלול בעבודה

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

לוח זמנים: 6–12 ימי עסקים, כולל חלק שרתי ובדיקות ברשתות לא יציבות. צרו קשר להערכה חינמית של הפרויקט שלכם—נעריך מורכבות ולוח זמנים ללא עלות. הזמינו פיתוח WebSocket API turnkey עם אחריות של 3 חודשים על כל החיבורים.