TypeScript के साथ Microservices
In this page:
// 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
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
// 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
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
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
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 }));
- एक shared event interface को एक service में बदलना बिना दूसरों को update किए, जो उन्हें runtime पर break कर देता है।
- Types का एक बड़ा package share करना ताकि सभी services एक-दूसरे पर depend करें, tight coupling बनाते हुए।
- Network boundary के across TypeScript types पर भरोसा करना, जब messages को अब भी runtime पर validate किया जाना चाहिए।
Chapter Quiz — Complete all 14 topics to unlock
0/14 topics done
Complete these topics first:
- Todo App with TypeScript
- REST API with Express + TypeScript
- React Dashboard with TypeScript
- CLI Tool with TypeScript
- Library with TypeScript
- Full Stack TypeScript App
- TypeScript Design System
- TypeScript Monorepo Project
- Authentication System
- Real-time App with Socket.io
- GraphQL API with TypeScript
- Microservices with TypeScript
- TypeScript Best Practices Review
- What to Learn Next