הגדלת API ב־Node.js מ־200 אלף למיליון משתמשים עם תגובות מהירות ב־60%

לאן הולך הזמן ב־API איטי ב־Node.js?

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

מה אינדקסים משנים?

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

למה להחליף שאילתות חוזרות ב־aggregation pipeline?

דפוס נפוץ הוא לשלוף רשימה, לעבור עליה בלולאה ב־Node.js ולהריץ עוד שאילתה לכל פריט. עם 50 פריטים אלה 51 סבבים מול מסד הנתונים. ‏aggregation pipeline עושה את הסינון, הצירוף והספירה בתוך MongoDB בבקשה אחת:

const resumes = await Resume.aggregate([
  { $match: { userId } },
  { $sort: { updatedAt: -1 } },
  { $limit: 20 },
  { $lookup: { from: "templates", localField: "templateId", foreignField: "_id", as: "template" } },
  { $project: { title: 1, updatedAt: 1, "template.name": 1 } },
])

שמים את $match ו־$limit כמה שיותר מוקדם, כדי שהשלבים הבאים יעבדו על פחות מסמכים, ובוחרים עם $project רק את השדות שהאפליקציה מציגה.

מה כדאי לשמור בקאש?

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

איך API צריך לחלק רשימות ארוכות לעמודים?

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

// Next page: everything older than the last item the client has
const page = await Resume.find({ userId, updatedAt: { $lt: cursor } })
  .sort({ updatedAt: -1 })
  .limit(20)

איך ולידציה וטיפול מרוכז בשגיאות מצמצמים תקלות בפרודקשן?

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

app.use((err, req, res, next) => {
  logger.error({ err, path: req.path, user: req.user?.id })
  const status = err.status || 500
  res.status(status).json({ error: status === 500 ? "Something went wrong" : err.message })
})

איך שומרים על שחרורים יציבים כשהתנועה גדלה?

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