DE
RU
EN
ES
ZH
FR
PT
AR
HI
Einleitung: Warum Ihr Projekt ein API Gateway benötigt?
\n\nStellen Sie sich vor: Sie entwickeln ein Startup oder eine Unternehmensanwendung in TypeScript. Sie haben bereits einen Benutzerdienst, einen Bestelldienst und einen Benachrichtigungsdienst. Jeder läuft auf seinem eigenen Port (oder sogar auf seinem eigenen Server), kommuniziert über HTTP und verwendet seine eigene Datenbank. Alles funktioniert, aber der Client (Frontend, mobile App) beginnt zu ersticken: Um eine Profilseite zusammenzustellen, muss er 4-5 Anfragen an verschiedene Dienste stellen, sich mit verschiedenen Fehlerformaten auseinandersetzen und sich außerdem bei jedem einzelnen anmelden.
\n\nHier kommt das API Gateway ins Spiel – ein einheitlicher Einstiegspunkt für alle Clients. Es übernimmt Routing, Authentifizierung, Datenaggregation, Caching und sogar die Transformation von Antworten. In diesem Artikel werden wir ein echtes API Gateway in TypeScript von Grund auf neu schreiben, Patterns und Anti-Patterns analysieren und zeigen, wie man typische Fallstricke vermeidet.
\n\nWas ist ein API Gateway in einfachen Worten
\n\nEin API Gateway ist eine Zwischenschicht zwischen dem Client und Ihren internen Diensten. Der Client (Browser, mobile App, externe API) kommuniziert nur mit dem Gateway. Das Gateway prüft den Pfad der Anfrage, überprüft das Token und leitet die Anfrage an den entsprechenden Microservice weiter. Manchmal sammelt es sogar die Antwort aus mehreren Diensten in einer einzigen – das nennt man Aggregation.
\n\nWarum wird dies im TypeScript-Ökosystem benötigt? Weil TypeScript uns Typen, Schnittstellen und Strenge bietet, und das Gateway ist der ideale Ort für die Validierung und Vereinheitlichung von Daten auf einen gemeinsamen Vertrag.
\n\nArchitektur: Wie es in TypeScript funktioniert
\n\nLassen Sie uns eine einfache, aber funktionale Architektur entwerfen. Wir werden haben:
\n\n- \n
- Gateway (unser TypeScript-Dienst) – Port 3000, der einzige Einstiegspunkt. \n
- Benutzerdienst (User Service) – Port 4001, REST API. \n
- Bestelldienst (Order Service) – Port 4002, REST API. \n
- Benachrichtigungsdienst (Notification Service) – Port 4003, REST API. \n
Alle internen Dienste leben in ihrem eigenen Netzwerk (z. B. Docker network) und sind von außen nicht sichtbar. Der Client kommuniziert nur mit dem Gateway.
\n\n// Projektstruktur\ngateway/\n├── src/\n│ ├── routes/\n│ │ ├── userRoutes.ts\n│ │ ├── orderRoutes.ts\n│ │ └── notificationRoutes.ts\n│ ├── middleware/\n│ │ ├── authMiddleware.ts\n│ │ ├── rateLimiter.ts\n│ │ └── cacheMiddleware.ts\n│ ├── services/\n│ │ └── proxyService.ts\n│ ├── types/\n│ │ └── index.ts\n│ └── index.ts\n├── package.json\n└── tsconfig.json\nEin einfaches API Gateway in TypeScript schreiben
\n\nBeginnen wir mit der Installation der Abhängigkeiten. Wir benötigen Express (das beliebteste Framework), http-proxy-middleware für das Proxying und einige Dienstprogramme.
\n\nnpm init -y\nnpm install express http-proxy-middleware cors helmet express-rate-limit\nnpm install -D typescript @types/node @types/express ts-node nodemon\nErstellen wir die tsconfig.json:
{\n "compilerOptions": {\n "target": "ES2020",\n "module": "commonjs",\n "outDir": "./dist",\n "rootDir": "./src",\n "strict": true,\n "esModuleInterop": true,\n "skipLibCheck": true,\n "forceConsistentCasingInFileNames": true\n },\n "include": ["src/**/*"],\n "exclude": ["node_modules"]\n}\nJetzt schreiben wir die Hauptdatei src/index.ts:
import express, { Request, Response } from 'express';\nimport cors from 'cors';\nimport helmet from 'helmet';\nimport { createProxyMiddleware } from 'http-proxy-middleware';\nimport { authMiddleware } from './middleware/authMiddleware';\nimport { rateLimiter } from './middleware/rateLimiter';\n\nconst app = express();\nconst PORT = process.env.PORT || 3000;\n\n// Globale Middleware\napp.use(helmet());\napp.use(cors());\napp.use(express.json());\napp.use(rateLimiter);\n\n// Proxy für den Benutzerdienst\napp.use('/api/users', auth 
