یکی از نکاتی که در استفاده از TypeScript باید همیشه در نظر داشته باشیم اینه که TypeScript می‌تونه در زمان توسعه و کامپایل جلوی خیلی از خطاها رو بگیره، اما وقتی داده‌ای در زمان اجرا از بیرون application وارد می‌شه، دیگه تضمینی درباره‌ی درست بودن اون داده نداره.

ما می‌تونیم برای همه چیز type و interface تعریف کنیم، از autocomplete و بررسی‌های TypeScript استفاده کنیم، ولی وقتی داده از بیرون application وارد می‌شه،
دیگه تضمینی وجود نداره که واقعاً همون شکلی باشه که انتظار داریم.

مثلاً یک API ممکنه یک field رو حذف کنه، اسم یک مقدار رو تغییر بده یا یک response متفاوت برگردونه. اینجا TypeScript دیگه نمی‌تونه کمکی کنه، چون این اتفاق در runtime رخ داده.اینجاست که Runtime Validation اهمیت پیدا می‌کنه.

در همکاری تیمی داشتن یک API Contract بین دو سمت فرانت و بک خیلی مهمه. هر endpoint باید مشخص کنه چه داده‌ای دریافت می‌کنه و چه داده‌ای برمی‌گردونه ،اما حتی داشتن یک API Contract هم به تنهایی کافی نیست؛ چون contract باید در runtime هم بررسی بشه تا مطمئن بشیم داده‌ای که واقعاً بین دو سمت رد و بدل می‌شه، با چیزی که انتظار داریم هماهنگه.

در یکی از پروژه‌هایی که روی اون کار کردم، برای حل این مسئله یک API Contract Boundary طراحی کردم؛ یک لایه بین featureهای frontend و API که request و responseها رو بر اساس contract مورد انتظار validate می‌کنه.

این باعث شد mismatchهای بین frontend و backend زودتر مشخص بشن و خطاها به جای اینکه جایی در UI ظاهر بشن، نزدیک‌تر به منبع خودشون شناسایی بشن.

توی پست جدیدم داخل dev.to درباره‌ی این موضوع، اینکه چرا TypeScript به تنهایی کافی نیست و چطور Runtime Validation رو در یک API layer پیاده کردم نوشتم.

لینک:
https://dev.to/rrealmrezarajabi/typescript-types-are-not-enough-building-a-runtime-api-contract-boundary-5epn

@DevTwitter | <Mohamad Reza Rajabi/>