כשהנתונים מ-Moralis API אינם תואמים לבלוקצ'יין
Moralis API לא קורא את הבלוקצ'יין ישירות — הוא מחזיר נתונים משכבת אינדקס משלו, שנבנית מעל צמתי הרשת. בין אישור בלוק לבין עדכון האינדקס תמיד קיים חלון השהיה, והוא גדל יחד עם מספר הרשתות המחוברות והיקף הבקשות מהחזית.
בתוך חלון זה יתרת הארנק, רשימת בעלי הטוקנים ומספר ההעברות נראים אחרת מאשר בשרשרת. אם על נתונים אלה מבוססים חישוב תשלומים או בדיקת הרשאות, אי-ההתאמה יוצאת לעולם האמיתי וחוזרת כתלונות.
מקור נפרד לחוסר סנכרון — ארגון מחדש של השרשרת: האינדקס הספיק להחזיר אירוע שכבר לא קיים לאחר ביטול הבלוק.
הסוג השני של תקלות — לא הנתונים עצמם, אלא הגישה אליהם. מגבלות בקשות חוסמות את החזית ברגע השיא, וניתוק של מנוי זרימה לא תמיד מורגש: האפליקציה עובדת, אבל האירועים כבר לא מגיעים.
לאחר הפעלה מחדש לא ברור מאיזה בלוק להמשיך, — הלקוח או מדלג על טווח, או פונה שוב ושוב לרשת עבור נתונים שכבר התקבלו.
בקשות חוזרות ושימוש במטמון לא מתקנים זאת: דרוש מצביע מפורש לבלוק האחרון שעובד, והשוואה של השליפה מול השרשרת עצמה לפי כתובות שנויות במחלוקת. בהמשך נסביר כיצד אנו בונים השוואה כזו ואילו בדיקות מכסות תשלומים מפני תמונת מצב מיושנת.
מה נותנת שכבת נתונים מאומתת למוצר על בלוקצ'יין
מקור נתונים אחיד מסיר סוג של אי-התאמות שבדרך כלל צף במפגש בין כמה מקורות: צומת משלכם, סייר חיצוני ושליפה עצמית לפי טוקנים מנרמלים אותה העברה בצורה שונה — מכאן סטטוסים שונים וזמנים שונים בחזית ובדוחות פנימיים.
שכבה מאומתת קובעת סכמת תגובה אחת, ולכן Moralis API וספקים דומים מתחברים כספק נתונים מאומתים, ולא כערוץ נוסף שאינו מתואם.
מהירות הופעת הנתונים בממשק נקבעת לפי שיטת האספקה, ולא לפי תדירות הסקירה. עדכוני זרימה מעבירים אירוע לפי החוזה מיד לאחר האישור — ההשהיה בין פעולת המשתמש להצגתה מצטמצמת מדקות לשניות, ומצבי ביניים לא נתקעים בהמתנה לבקשה המתוכננת הבאה. בארנק, במרקטפלייס או בפאנל ניהול זה מסיר את המקור העיקרי לתלונות על «יתרה תקועה».
שימוש במטמון לתגובות מכסה את החצי השני של המשימה. פרופילים מבוקשים לעיתים קרובות, רשימות טוקנים ושערים מוחזרים מהמטמון עם תוקף ידוע מראש, והצומת נסקר רק בעת שינוי מצב בפועל.
העומס על הצמתים שלכם יורד פי כמה, והם מפסיקים להיות צוואר בקבוק ברגעי פעילות שיא — למשל בזמן מינט המוני או חלוקת פרסים.
כתוצאה מכך יורד שיעור הבדיקות הידניות של אי-התאמות: כשפורמט התגובות יציב, אי-התאמות בין החזית לצד השרת הופכות למקרים בודדים ולא לעבודה שגרתית.
צוות התחזוקה עובר מטיפול בתקלות לפיתוח המוצר, וזה האפקט המדיד היציב ביותר של שכבת נתונים מאומתת — הוא נבדק לפי מספר הפניות לתמיכה ולפי זמן התגובה לאירוע.
דרכים לקבל נתונים: השוואה בין ארבע גישות
הבחירה בדרך הגישה לנתונים קובעת כמה זמן הפתרון יעמוד בגידול עומס ובשינוי דרישות. צומת משלכם נותן עצמאות ונתונים ממקור ראשון, אבל סנכרון, עדכונים ואחסון נופלים על התשתית שלכם, ושליפות היסטוריות בכל זאת צריך לחשב בנפרד.
אינדקסר מקומי מכסה בקשות לא שגרתיות — אגרגציות לפי כתובות, שליפות לפי אירועי חוזה — במחיר של לוחות זמנים לפיתוח ותחזוקה של סכמת אחסון משל עצמו.
שירותים חיצוניים מוכנים, למשל Moralis, מסירים את עבודת התשתית: יתרות, פעולות לפי טוקנים, מטא-נתונים ובעלי NFT מוחזרים בבקשה אחת. המגבלה כאן היא גבולות העומס וכללי הספק: תדירות הבקשות, עומק ההיסטוריה ורשימת הרשתות הנתמכות נקבעים לא על ידכם. להלן — ארבע גישות במבט אחד.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| צומת משלכם | נדרשת עצמאות מצדדים שלישיים ונתונים ממקור ראשון | תשתית משלכם, פיגור סנכרון, ההיסטוריה נאינדקסת ידנית |
| אינדקסר מקומי | שליפות ואגרגציות לא שגרתיות לפי כתובות ואירועים | לוחות זמנים לפיתוח, אינדוקס מחדש בעת ארגון מחדש של הרשת, גידול באחסון |
| ספק נתונים חיצוני | התחלה מהירה וכיסוי רשתות רבות בלי סביבה משלכם | מגבלות בקשות, תלות בזמינות ובכללי הספק |
| סכמה היברידית | בקשות קריטיות בסביבה שלכם, אנליטיקה — אצל הספק | קונפיגורציה מורכבת יותר, דרושים השוואת נתונים וכללי מעבר |
סכמה היברידית בפועל נפוצה יותר מהאחרות: היא מחזיקה השהיה במסלול הקריטי בגבולות סבירים ולא קושרת את המוצר לספק אחד. בהמשך נסביר כיצד פיצול כזה מוגדר ונבדק תחת עומס.
כיצד מתבצעת הטמעה: שבעה שלבים מהאודיט ועד למסירה
אנחנו מתחילים לא בקוד, אלא באודיט של האינטגרציה: בודקים אילו פניות לרשת כבר קיימות במערכת, כמה הן, והיכן אותם נתונים נקראים כמה פעמים. בפלט — מפת זרימות נתונים: מה מושכים בבקשה, מה מאזינים בזרימה, מה שומרים במטמון וממתי מחשיבים אותו לישן.
- אודיט אינטגרציה. עורכים מלאי של קריאות: כתובות, תדירות, גודל תגובות, שיעור כפילויות. מפרידים נתונים קריטיים ללוגיקה מאלה שאפשר לקבל באופן אסינכרוני.
- סכמת זרימות נתונים. פורשים קריאה ומנויים לפי שכבות: בקשות סינכרוניות, זרימות לפי כתובות וטוקנים, מטמון מקומי עם זמן חיים. לכל זרימה מגדירים מקור אמת.
- כללי חזרות ומגבלות. מגדירים התנהגות בשגיאות: השהיה עם גדילת מרווח, הגבלת בקשות מקבילות, תורים לפי עדיפות. מיצוי מכסה לא צריך להפיל את התרחיש המרכזי.
- הגדרת סביבות. מפתחות במאגר מאובטח, הפרדה לפי סביבות, מנויים לאירועים הנדרשים, מסננים לפי רשת וסוג נכס. מקבלים סביבת עבודה להרצות בדיקה.
- בדיקה תחת עומס. מריצים פרופיל קרוב לשיא: פרץ מנויים, הנפקה המונית של NFT, אינדוקס מחדש לאחר תקלה. מתקנים את מה שלא עמד בזמן תגובה ובשיעור כשלים.
- נראות. מדדים לפי זרימות: השהיה, שגיאות, פגיעות במטמון, עומק תור. התראות על מיצוי מכסה ואי-התאמה עם מצב הרשת.
- מסירת תיעוד. מוסרים סכמת זרימות, קונפיגורציות, כללי חזרות, סדר רוטציה של מפתחות וניתוח אירועים — צוות הלקוח ממשיך את האינטגרציה בעצמו.
כל שלב נשען על התוצר של השלב הקודם: בלי מפת זרימות אי אפשר להגדיר מגבלות, ובלי בדיקה תחת עומס אי אפשר לטעון שהזרימות יעמדו בפרץ פעילות. עובדים עם Moralis וספקי נתונים אחרים — בוחרים מקור לפי המשימה, ולא להפך.
ערכת תיעוד וקונפיגורציות בסיום העבודה
לאחר מסירת האינטגרציה אצל הלקוח נשאר לא התכתבות וצילומי מסך, אלא ערכה עובדת: קונפיגורציות, סכמת קשרים, הרשאות והוראות. את הכול מניחים במאגר של הלקוח כקונפיגורציה-כקוד — שינויים עוברים דרך ביקורת, וסביבות בדיקה וייצור מתוארות באותו מערך קבצים עם ערכי משתנים שונים.
להלן רשימת התוצרים שאנו מוסרים לפי פרוטוקול, עם הסבר למה כל אחד נדרש בתפעול.
- קונפיגורציות חיבור ל-Moralis: מפתחות ומגבלות בקשות לפי סביבות, סכמת מטמון לתגובות, זמני פסק זמן ואסטרטגיית חזרות — הסוד עצמו במאגר מאובטח, במאגר הקוד רק תבנית ותיאור שדות.
- סכמת אינטגרציה: אילו שירותים פונים ל-API, מי אחראי על תור זרימות הבלוקים, היכן נקודת העיבוד החוזר בעת תקלה וכיצד לשחזר טווח שהוחמץ.
- כללי גישה: מטריצת תפקידים ותחומי מפתחות — קריאת יתרות ומטא-נתוני טוקנים לאנליטיקה, כתיבה ומנויים רק לחשבון שירות, סדר רוטציה של מפתחות.
- הוראות תפעול: כיצד לפרוס סביבה מאפס, כיצד לבדוק חיות אינטגרציה, מה לחפש ביומנים בעת אי-התאמת יתרות או כפילות אירועים.
- נוהל עדכונים: סדר הוצאה של שינויי סכמה ומטפלים, חלון חזרה לגרסה קודמת, כללי תאימות אחורה לתגובות עבור לקוחות שכבר מחוברים.
- מפת ניטור: אילו אותות נאספים — השהיית תגובות, שיעור כשלים לפי מגבלות, פיגור אינדוקס — ולאילו ספים מוגדרות התראות לתורן.
- יומן החלטות הנדסיות: מדוע נבחרו שיטות ומצבי מטמון מסוימים, אילו חלופות נדחו — כדי שבעוד חצי שנה הצוות לא יבנה מחדש את אותה בחירה.
מקרה בוחן של פלטפורמה לפריטים דיגיטליים: מדדים לפני ואחרי
פלטפורמה לפריטים דיגיטליים החזיקה קטלוג על בקשות ישירות לצמתים: לאחר התשלום הפריט הופיע בפרופיל הקונה כעבור 40–90 שניות, וכל הזמן הזה המשתמש ראה «עיבוד». אי-התאמות בין הקטלוג לבעלות בפועל נמצאו ידנית — על השוואות עברו כמה שעות ביום, והיקף העבודה הזה גדל יחד עם מספר העסקאות. כדי לעמוד בשיאים, החזיקו תשתית עם עודף: כל לקוח סקר את הנתונים בעצמו, ושכפל אותן בקשות.
מה עבדנו מחדש בשכבת הנתונים
הרכבנו שכבה נפרדת: אירועים מאושרים נכנסים לתור ומעובדים באופן אידמפוטנטי, הקטלוג קורא מצב מוכן מהמטמון, ולא תגובות גולמיות. הלקוחות עברו למנוי — השרת עוקב אחרי העדכונים ומפיץ שינויים שכבר נבדקו, ולכן הופעת הפריט כבר לא תלויה בתדירות שבה הפרונטאנד סקר את הרשת.
את הסכמה הרכבנו על Moralis: הזרימות מביאות אירועים עם הגמר, והנרמול למודל הבעלות שלנו וכללי העיבוד החוזר נשארים בצד השירות.
מדדים לפני ואחרי
- השהיית הופעת הפריט בפרופיל: 40–90 שניות → 3–6 שניות.
- שיעור אי-התאמות בעלות: כ-1% מהעסקאות → 0.02%, את השאר תופסת השוואה אוטומטית.
- השוואות ידניות: כמה שעות מדי יום → בדיקה מתוכננת פעם בשבוע.
- עומס על התשתית: פניות שיא לצמתים הצטמצמו פי 4–5, קריאת הקטלוג עברה כמעט כולה למטמון.
- כשלי צמתים ומשלוחים חוזרים של אירועים כבר לא שוברים את המצב — העיבוד משוחזר.
את המדדים אספנו על אותו מערך תרחישים לפני ואחרי העבודה מחדש, כדי שההשוואה תהיה הוגנת. ניתוח ציבורי מלא עם סכמות של שכבת הנתונים ותיאור הבדיקות צירפנו בנפרד — ממנו רואים אילו החלטות הניבו את האפקט העיקרי ואילו היו תוצאה שלו.
במה Moralis API שונה מחיבור ישיר לצומת?
חיבור ישיר לצומת — זה כאשר צומת הרשת אתם מרימים ומתחזקים, והאפליקציה פונה אליו ישירות. השהיית התגובה אז נקבעת כולה לפי התשתית שלכם: סנכרון, דיסק, שיאי עומס. בתמורה אתם מקבלים שליטה מלאה והיעדר מתווך בין האפליקציה לרשת.
אבל הצומת מחזיר נתונים גולמיים. כדי להציג היסטוריית פעולות לפי ארנק או לאסוף את כל הטוקנים של כתובת, האפליקציה עוברת בעצמה על בלוקים, מפענחת אירועים ומאחסנת את התוצאה במאגר משלה. בלי שלב זה שלמות ההיסטוריה אינה מושגת — המשתמש רואה קטעים במקום תמונה מלאה.
Moralis מחזיק היסטוריה מאונדקסת ומחזיר שליפות מוכנות. מכאן ההבדל בהיקף הבקשות: במקום עשרות פניות למסך אחד — יתרות, העברות, מטא-נתונים — יוצאת בקשה אחת, והשהיית התגובה מפסיקה להיות תלויה בכך אם הצומת הספיק לעבד בלוק נוסף.
הצד השני — תלות בספק: מגבלות על היקף בקשות, כללי תמחור, שינויים בצד השירות שאתם לא שולטים בהם. לחיבור ישיר אין תלות כזו, אבל זמינות, עדכונים והרחבה של הצומת מוטלים על הצוות שלכם.
בפועל הבחירה אינה בינארית. שכבת הגישה לנתונים עוברת אבסטרקציה: אגרגטים והיסטוריה נלקחים מהאינדקס של הספק, ופעולות קריטיות וכתיבה — דרך צומת משלכם. אז החלפת ספק עולה בכתיבה מחדש של מודול אחד, ולא של כל האפליקציה.
שאלות טכניות נפוצות לפני ההתחלה
לפני תחילת האינטגרציה הלקוח בודק לא «האם הצוות יודע», אלא «מה יקרה אם»: הספק ישנה תנאים, מפתח ידלוף, הרשת תיפול. להלן ארבע שאלות ששואלים כמעט תמיד, ותשובות ענייניות, בלי הבטחה ש«הכול יהיה יציב».
מקור נתונים חיצוני אנחנו עוטפים בשכבת גישה דקה בתוך השירות: האפליקציה קוראת רק אליה, ולכן הספק הופך לחלק שניתן להחליף.
מה יקרה אם נחליט להחליף ספק נתונים?
שכבת הגישה מחזיקה ממשק אחיד: קריאות, פורמטי תגובות ומטמון נשארים שלנו. מעבר מ-Moralis לפלטפורמה אחרת — זה תיקון של מתאם אחד והרצה חוזרת של בדיקות חוזה, ולא כתיבה מחדש של הלוגיקה בכל הקוד.
כיצד מוגנים מפתחות הגישה?
מפתחות לא נשמרים בקוד ובמאגר — רק במאגר סודות עם מסירה לאפליקציה בעת ההפעלה. לקריאות לקוח מונפקים מפתחות נפרדים עם מערך מוגבל של שיטות והצמדה לדומיין, ומפתחות שרת עוברים רוטציה לפי לוח זמנים. דליפה של מפתח אחד לא פותחת את שאר הסביבות.
כיצד האינטגרציה מתנהגת בעומס יתר על הרשת?
בקשות עוברות דרך חזרות עם השהיה גדלה, הגבלת קריאות במקביל ומטמון מקומי לנתונים חמים. במיצוי מגבלות אנו מחזירים את המצב המאושר האחרון עם ציון גילו, ולא מפילים מסכים. כתיבות מעובדות באופן אידמפוטנטי, ולכן חזרה לא יוצרת כפילויות.
האם יש תוכנית חזרה לאחור וכיצד מופרדות הסביבות?
פיתוח, בדיקות ופרודקשן מופרדים לפרויקטים, מפתחות ומערכי נתונים נפרדים — בדיקות לא כותבות לפרודקשן. גרסאות יוצאות בשלבים ומסומנות במספר גרסה, ולכן חזרה לאחור — חזרה לתמונה הקודמת עם הרצה חוזרת של מיגרציות, ולא שחזור מצב ידני.
נדבר על המשימה: מה לשלוח להערכה מדויקת
כדי שההערכה תהיה עניינית ולא «מהעין», נדרש סט מינימלי של נתוני פתיחה. הם קובעים את היקף העבודה: מעטיפה דקה מעל Moralis API ועד אינדקסר משלכם עם מטמון ותורים. שלחו את מה שיש — על החסרים נשאל בעצמנו.
- רשימת רשתות: סביבה ראשית ורשתות בדיקה, EVM ולא-EVM, עבודה עם L2 ורשתות צד.
- עומס צפוי: בקשות בשנייה בשיא, מספר כתובות ייחודיות ביום, עומק היסטוריה — בלוקים אחרונים או ארכיון מהראשון.
- דרישות השהיה: מהו זמן תגובה מקובל לקריאת יתרה ומטא-נתוני NFT.
- תפקידי גישה: מי קורא נתונים, מי כותב, והאם דרושים מפתחות שירות נפרדים לצד השרת ולאפליקציות לקוח.
- סכמת הפניות הנוכחית: צמתים משלכם, ספק מוכן או עדיין כלום; אילו בקשות כבר יוצאות לרשת ובאיזו תדירות.
- סוגי נתונים ומסננים: העברות טוקנים, תנועות פנימיות, אירועי חוזים, מטא-נתוני NFT ובעלים.
- מגבלות: פרטיות, אזורי אחסון, תיעוד יומנים, לוחות זמנים להשקה.
בהמשך מחשבים היקף: צווארי בקבוק נראים כבר על הנתונים האלה — היכן מספיקות זרימות, והיכן דרושים מטמון משלכם, ניסיונות חוזרים וספק גיבוי. אם חלק מהנתונים חסר, נאסוף אותו יחד וניתן הערכה לפי טווח, ולא לפי הגבול העליון. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.