מה למדתי מפיתוח שכבת אדמין למערכת ride-hailing עם FastAPI וסנכרון בין בסיסי נתונים

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

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

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

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

אחד הדברים החשובים בפרויקט היה לעבוד מול API מתועד היטב, עם Swagger / OpenAPI, מה שאפשר חיבור מדויק יותר בין שכבת האדמין לבין מערכת הליבה. כשיש חוזה API ברור, הרבה יותר קל לשמור על קצב פיתוח, להקטין טעויות, ולבנות שכבת ניהול שלא נשענת על “ניחושים”.

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

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

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

זה סוג הפרויקטים שאני מחפש גם היום:
פלטפורמות web,
מערכות עסקיות,
admin panels,
API-driven products,
ומערכות שבהן ה-backend והלוגיקה התפעולית הם חלק מהלב של המוצר.