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

מדוע דשבורד הטוקן-סייל קורס בעומס שיא

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

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

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

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

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

מה נותן דשבורד טוקן-סייל מנוהל: אפקט מדיד

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

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

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

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

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

דרכי מסירת נתונים: זרם, סקירה, ייצוא באצוות

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

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

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

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

שלבי הפיתוח: מביקורת הזרמים ועד מסירה לצוות

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

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

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

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

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

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

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

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

מסירה: סכמות נתונים, קונפיגורציות ותקנוני עדכון

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

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

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

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

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

מה נבנה מחדש

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

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

מה השתנה

• זמן התגובה של המסך הראשי בשיא — מ-12–14 שנ' ל-1.5 שנ';
• שיעור הפערים בין הוויטרינה לנתוני הרשת — מ-3% ל-0.1%;
• פניות לתמיכה בנושא "המספרים לא מסתדרים" — פי שישה פחות;
• ייצוא דוחות — 100% בלי החמצות, כולל ימי שיא.

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

במה נבדלת ויטרינה עצמאית משירות אנליטי מוכן?

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

מה עושים עם השהיית מקור הנתונים?

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

האם מורכב להטמיע את הדשבורד באזור אישי?

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

מדוע המספרים לא מסתדרים עם נתוני הבורסה?

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

מה עם תמיכה לאחר מסירת הפרויקט?

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

מה לשלוח כדי לקבל הערכה ותוכנית עבודה

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

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

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