← Back to TypeScript Course | Chapter 28: Real World Projects | Lesson 12 of 14

TypeScript के साथ Microservices

Microservices एक application को independently deployable services में बांटते हैं। TypeScript requests, responses, configuration, और shared domain models के लिए clear contracts provide कर सकता है।
Syntax
typescript
// shared/events.ts
export interface EventName {
    property: type;
}

// each service imports the same shared shape
import { EventName } from "shared";

Core Concept

एक TypeScript microservices architecture में, हर service का अपना independent tsconfig.json और dependencies हो सकते हैं, लेकिन services के बीच shared request/response contracts को अब भी एक common typed schema से फायदा होता है ताकि वे silently अलग न हो जाएं।

उदाहरण: Core Concept

typescript
interface OrderCreatedEvent {
  orderId: string;
  total: number;
}
// Each service has its own tsconfig, but shares this event's shape.
const event: OrderCreatedEvent = { orderId: "1", total: 50 };
console.log(event);

Basic Setup

एक basic setup अक्सर एक shared-types package (या एक schema जैसे Protobuf/OpenAPI से generated types) उपयोग करता है जो एक private registry पर publish होता है, हर उस service द्वारा import किया जाता है जिसे दूसरी service को call करना या उससे call होना हो।

उदाहरण: Basic Setup

typescript
// shared-types package published to a private registry,
// imported by every service that produces/consumes these events.
interface OrderCreatedEvent { orderId: string; }
console.log("A shared-types package prevents contract drift between services");

Typed Example

एक typed example: एक shared interface OrderCreatedEvent { orderId: string; userId: string; total: number } उस service द्वारा भी उपयोग होता है जो event publish करती है और हर उस service द्वारा भी जो इसे subscribe करती और process करती है।

उदाहरण: Typed Example

typescript
interface OrderCreatedEvent {
  orderId: string;
  userId: string;
  total: number;
}
function publishOrderCreated(event: OrderCreatedEvent) {
  console.log("Publishing:", event);
}
publishOrderCreated({ orderId: "1", userId: "u1", total: 99 });

Project Usage

एक असली project में, इन shared inter-service types को carefully version करना एक monolith से ज़्यादा मायने रखता है, क्योंकि दो services अलग schedules पर deploy हो सकती हैं और temporarily एक shared contract के slightly अलग versions के against run कर सकती हैं।

उदाहरण: Project Usage

typescript
interface OrderCreatedEventV2 {
  orderId: string;
  total: number;
  currency: string; // added in v2
}
console.log("Services on different deploy schedules may see different versions");

Best Practices

हर service boundary पर incoming inter-service messages को runtime पर validate करें (सिर्फ compile time पर नहीं), क्योंकि TypeScript के types runtime पर गायब हो जाते हैं और एक service को किसी older version चला रही दूसरी service द्वारा भेजे गए एक malformed message से protect नहीं कर सकते।

उदाहरण: Best Practices

typescript
interface OrderCreatedEvent { orderId: string; total: number; }
function isOrderCreatedEvent(value: any): value is OrderCreatedEvent {
  return typeof value?.orderId === "string" && typeof value?.total === "number";
}
console.log(isOrderCreatedEvent({ orderId: "1", total: 10 }));
Related Topics
{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
आम गलतियां
  1. एक shared event interface को एक service में बदलना बिना दूसरों को update किए, जो उन्हें runtime पर break कर देता है।
  2. Types का एक बड़ा package share करना ताकि सभी services एक-दूसरे पर depend करें, tight coupling बनाते हुए।
  3. Network boundary के across TypeScript types पर भरोसा करना, जब messages को अब भी runtime पर validate किया जाना चाहिए।

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.