מפתח הקדיש שבועיים להחלפת REST API ב-tRPC בכלי פנימי.

למה המעבר היה משמעותי

הסטאק הישן אילץ אותנו לתחזק DTO, ולידטור (validator), וסט נפרד של טיפוסי TypeScript עבור ה-frontend. אם שינית שם של שדה ב-backend, ה-API עדיין החזיר 200, ה-UI המשיך להתרנדר, והבאג הופיע רק כערכי "undefined". לקוח זיהה את הבעיה לפני שמישהו מהצוות עשה זאת. חוזי ה-REST הסתירו את הבעיה, והקבצים הנוספים הוסיפו תחזוקה שמעולם לא השתלמה.

איך נראה המבנה של REST

  • OpenAPI spec – קובץ סטטי שתיאר נקודות קצה (endpoints) אך מעולם לא שימש כמקור האמת (source of truth).
  • שלב יצירת Client SDK – תהליך CI שיצר wrapper ב-JavaScript.
  • Postman collection – ארטיפקט בדיקה משותף שאף אחד לא השתמש בו.
  • TypeScript interfaces ידניות – טיפוסים שנכתבו ביד ונאלצו להישאר מסונכרנים עם השרת.

כל שינוי ב-API נגע בלפחות שלושה מהארטיפקטים הללו, בנוסף ל-validator ולכל קריאות ה-fetch בהמשך השרשרת. התהליך היה רגיש לשגיאות ואיטי.

איך tRPC צמצם את בסיס הקוד

tRPC מבטל את קובץ החוזה הנפרד. השרת מייצא router type; הלקוח מייבא את אותו הטיפוס. אם משנים שם של שדה ב-backend, העורך (editor) מסמן את חוסר ההתאמה באופן מיידי — ללא צורך בהרצת קוד או בבקשה שנכשלה. המפתח הסיר:

  • את קובץ ה-OpenAPI spec.
  • את שלב יצירת ה-client SDK.
  • את ה-Postman collection שלא היה בשימוש.
  • את תיקיית ה-TypeScript interfaces הידניות.

ה-repo הפך לרזה יותר, והמשוב הגיע במהלך הפיתוח במקום לאחר הפריסה (deployment).

מגבלות של tRPC

tRPC עובד רק כאשר שני הצדדים מדברים TypeScript. הוא פחות מתאים אם:

  • צוות מובייל משתמש ב-Swift או ב-Kotlin.
  • ה-API חייב להיות נצרך על ידי שותפים חיצוניים.
  • אתם זקוקים לממשק ציבורי שאינו תלוי בשפה (language-agnostic).

מה המעבר דרש בפועל

המאמץ של השבועיים היה הרבה יותר מסתם העתק-הדבק. המפתח היה צריך:

  • לכתוב מחדש כל קריאת fetch כדי להשתמש בפונקציות הלקוח של tRPC.
  • להתאים את לוגיקת הטיפול בשגיאות (error-handling).
  • לעדכן רכיבי UI שהסתמכו על מצבי טעינה (loading) וניסיונות חוזרים (retry) הקשורים לתגובות HTTP גולמיות.

שאלות לשאול לפני שיוצאים לדרך

  • האם גם ה-frontend וגם ה-backend משתמשים ב-TypeScript? ללא מערכת טיפוסים משותפת, tRPC מאבד את היתרון העיקרי שלו.
  • האם אותו צוות אחראי על שני הצדדים? פערי בעלות עלולים להחזיר את חוסר הסנכרון בחוזים (contract drift).
  • האם אתם מתקנים באג קונקרטי או רודפים אחרי טרנד? שיפור הפרודוקטיביות הוא אמיתי, אך הוא צריך לפתור נקודת כאב קיימת.

גישה היברידית ל-2025

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

  • tRPC עבור שכבות אפליקציה פנימיות שבהן בסיס הקוד הוא כולו TypeScript ואותו צוות מחזיק בשרת ובלקוח.
  • REST עבור webhooks, APIs ציבוריים ואינטגרציות עם שותפים שבהם נדרשת גישה שאינה תלויה בשפה.

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

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