@bluealba/platform-cli 1.0.1 → 1.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.js +277 -9
- package/docs/404.mdx +5 -0
- package/docs/architecture/api-explorer.mdx +478 -0
- package/docs/architecture/architecture-diagrams.mdx +12 -0
- package/docs/architecture/authentication-system.mdx +903 -0
- package/docs/architecture/authorization-system.mdx +886 -0
- package/docs/architecture/bootstrap.mdx +1442 -0
- package/docs/architecture/gateway-architecture.mdx +845 -0
- package/docs/architecture/multi-tenancy.mdx +1150 -0
- package/docs/architecture/overview.mdx +776 -0
- package/docs/architecture/scheduler.mdx +818 -0
- package/docs/architecture/shell.mdx +885 -0
- package/docs/architecture/ui-extension-points.mdx +781 -0
- package/docs/architecture/user-states.mdx +794 -0
- package/docs/development/overview.mdx +21 -0
- package/docs/development/workflow.mdx +914 -0
- package/docs/getting-started/core-concepts.mdx +892 -0
- package/docs/getting-started/installation.mdx +780 -0
- package/docs/getting-started/overview.mdx +83 -0
- package/docs/getting-started/quick-start.mdx +940 -0
- package/docs/guides/adding-documentation-sites.mdx +1367 -0
- package/docs/guides/creating-services.mdx +1736 -0
- package/docs/guides/creating-ui-modules.mdx +1860 -0
- package/docs/guides/identity-providers.mdx +1007 -0
- package/docs/guides/mermaid-diagrams.mdx +212 -0
- package/docs/guides/using-feature-flags.mdx +1059 -0
- package/docs/guides/working-with-rooms.mdx +566 -0
- package/docs/index.mdx +57 -0
- package/docs/platform-cli/commands.mdx +604 -0
- package/docs/platform-cli/overview.mdx +195 -0
- package/package.json +5 -2
- package/skills/ba-platform/platform-cli.skill.md +26 -0
- package/skills/ba-platform/platform.skill.md +35 -0
- package/templates/application-monorepo-template/gitignore +95 -0
- package/templates/bootstrap-service-template/gitignore +57 -0
- package/templates/bootstrap-service-template/src/main.ts +6 -16
- package/templates/customization-ui-module-template/gitignore +73 -0
- package/templates/nestjs-service-module-template/gitignore +56 -0
- package/templates/platform-init-template/{{platformName}}-core/gitignore +97 -0
- package/templates/react-ui-module-template/Dockerfile +1 -1
- package/templates/react-ui-module-template/caddy/Caddyfile +1 -1
- package/templates/react-ui-module-template/gitignore +72 -0
|
@@ -0,0 +1,478 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: API Explorer
|
|
3
|
+
description: Interactive API documentation system for exploring and testing the Blue Alba Platform REST APIs
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
import { Card, CardGrid, Aside, Tabs, TabItem } from '@astrojs/starlight/components';
|
|
7
|
+
|
|
8
|
+
The Blue Alba Platform provides comprehensive API documentation through an interactive **API Explorer** that enables developers to discover, understand, and test all available REST endpoints across the platform and business applications.
|
|
9
|
+
|
|
10
|
+
## Overview
|
|
11
|
+
|
|
12
|
+
The Platform API consists of two main categories:
|
|
13
|
+
|
|
14
|
+
<CardGrid>
|
|
15
|
+
<Card title="Business Application APIs" icon="seti:javascript">
|
|
16
|
+
Custom APIs provided by business applications, prefixed by the gateway through the Application Catalog. These APIs are product-specific and depend on the applications and modules deployed.
|
|
17
|
+
</Card>
|
|
18
|
+
|
|
19
|
+
<Card title="Platform APIs" icon="seti:config">
|
|
20
|
+
Out-of-the-box APIs provided by the Platform itself and its core microservices. These APIs handle authentication, authorization, catalog management, user management, and more.
|
|
21
|
+
</Card>
|
|
22
|
+
</CardGrid>
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## API Documentation via Swagger
|
|
27
|
+
|
|
28
|
+
Every Platform service implements interactive API documentation using **Swagger/OpenAPI**. This provides:
|
|
29
|
+
|
|
30
|
+
- **Interactive Testing**: Execute API calls directly from the documentation
|
|
31
|
+
- **Request/Response Examples**: See real-world examples of API payloads
|
|
32
|
+
- **Schema Definitions**: Understand data structures and validation rules
|
|
33
|
+
- **Authentication Support**: Test authenticated endpoints with your session
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## Accessing the API Explorer
|
|
38
|
+
|
|
39
|
+
### Built-in API Docs Explorer
|
|
40
|
+
|
|
41
|
+
The most straightforward way to inspect and test APIs is through the **built-in API Docs Explorer**, available since Platform version `v1.5.0`.
|
|
42
|
+
|
|
43
|
+
**Access Requirements**:
|
|
44
|
+
- Navigate to the Admin Application
|
|
45
|
+
- Requires the `api-docs::*` operation permission
|
|
46
|
+
|
|
47
|
+
**Features**:
|
|
48
|
+
- Unified interface for all platform services
|
|
49
|
+
- Single sign-on - uses your current authentication session
|
|
50
|
+
- Tenant-aware - respects your current tenant context
|
|
51
|
+
- Service switching - easily navigate between different service APIs
|
|
52
|
+
|
|
53
|
+
<Aside type="tip" title="Admin Access">
|
|
54
|
+
The API Explorer is available in the Platform Admin UI under the API Documentation section. Users must have the appropriate permissions to access this feature.
|
|
55
|
+
</Aside>
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## Individual Service Documentation
|
|
60
|
+
|
|
61
|
+
You can also access each service's Swagger documentation directly at specific URLs:
|
|
62
|
+
|
|
63
|
+
<Tabs>
|
|
64
|
+
<TabItem label="Gateway">
|
|
65
|
+
**Gateway Service API**
|
|
66
|
+
```
|
|
67
|
+
/api-documentation
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
Provides documentation for orchestrator and gateway endpoints.
|
|
71
|
+
</TabItem>
|
|
72
|
+
|
|
73
|
+
<TabItem label="Catalog">
|
|
74
|
+
**Application Catalog API**
|
|
75
|
+
```
|
|
76
|
+
/catalog/docs
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Documents endpoints for managing applications, modules, and catalog entries.
|
|
80
|
+
</TabItem>
|
|
81
|
+
|
|
82
|
+
<TabItem label="Authorization">
|
|
83
|
+
**Authorization API**
|
|
84
|
+
```
|
|
85
|
+
/authz/docs
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Documents endpoints for managing roles, operations, permissions, and authorization rules.
|
|
89
|
+
</TabItem>
|
|
90
|
+
|
|
91
|
+
<TabItem label="User Service">
|
|
92
|
+
**User Service API**
|
|
93
|
+
```
|
|
94
|
+
/user/api-docs
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
Documents endpoints for user management, authentication, and user states.
|
|
98
|
+
</TabItem>
|
|
99
|
+
</Tabs>
|
|
100
|
+
|
|
101
|
+
<Aside type="note">
|
|
102
|
+
The base URL depends on your platform instance. For example, in development it might be `http://localhost/_/docs`, while in production it would use your configured domain.
|
|
103
|
+
</Aside>
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Using the API Explorer
|
|
108
|
+
|
|
109
|
+
### Interactive Testing
|
|
110
|
+
|
|
111
|
+
The Swagger interface allows you to:
|
|
112
|
+
|
|
113
|
+
1. **Expand Endpoint Groups**: Click on endpoint categories to see available operations
|
|
114
|
+
2. **View Details**: See request parameters, headers, and body schemas
|
|
115
|
+
3. **Try It Out**: Click "Try it out" to enable interactive testing
|
|
116
|
+
4. **Execute Requests**: Fill in parameters and click "Execute"
|
|
117
|
+
5. **View Responses**: See actual API responses with status codes and data
|
|
118
|
+
|
|
119
|
+
**Example Workflow**:
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
1. Navigate to Authorization API docs (/authz/docs)
|
|
123
|
+
2. Find "GET /operations" endpoint
|
|
124
|
+
3. Click "Try it out"
|
|
125
|
+
4. Execute the request
|
|
126
|
+
5. View the list of all operations in the system
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
### Authentication Context
|
|
130
|
+
|
|
131
|
+
The API Explorer automatically uses your current session:
|
|
132
|
+
|
|
133
|
+
- **JWT Token**: Extracted from your HTTP-only cookie
|
|
134
|
+
- **Tenant Context**: Inherited from your current tenant selection
|
|
135
|
+
- **User Context**: Operations are executed as the logged-in user
|
|
136
|
+
- **Permissions**: You can only execute operations you're authorized for
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Platform Core APIs
|
|
141
|
+
|
|
142
|
+
### Gateway & Orchestrator API
|
|
143
|
+
|
|
144
|
+
**Base Path**: `/api-documentation`
|
|
145
|
+
|
|
146
|
+
Key endpoints include:
|
|
147
|
+
- Health checks
|
|
148
|
+
- Configuration management
|
|
149
|
+
- Platform metadata
|
|
150
|
+
- Request proxying information
|
|
151
|
+
|
|
152
|
+
### Catalog API
|
|
153
|
+
|
|
154
|
+
**Base Path**: `/catalog/docs`
|
|
155
|
+
|
|
156
|
+
Manages the dynamic service registry:
|
|
157
|
+
|
|
158
|
+
<CardGrid>
|
|
159
|
+
<Card title="Applications" icon="seti:folder">
|
|
160
|
+
- List all applications
|
|
161
|
+
- Get application details
|
|
162
|
+
- Create/update applications
|
|
163
|
+
- Manage application access
|
|
164
|
+
</Card>
|
|
165
|
+
|
|
166
|
+
<Card title="Modules" icon="puzzle">
|
|
167
|
+
- Register services and UIs
|
|
168
|
+
- Update module configurations
|
|
169
|
+
- Query module endpoints
|
|
170
|
+
- Manage module dependencies
|
|
171
|
+
</Card>
|
|
172
|
+
|
|
173
|
+
<Card title="Operations" icon="approve-check">
|
|
174
|
+
- List all operations
|
|
175
|
+
- Create new operations
|
|
176
|
+
- Bind operations to applications
|
|
177
|
+
- Query operation permissions
|
|
178
|
+
</Card>
|
|
179
|
+
</CardGrid>
|
|
180
|
+
|
|
181
|
+
### Authorization API
|
|
182
|
+
|
|
183
|
+
**Base Path**: `/authz/docs`
|
|
184
|
+
|
|
185
|
+
Implements the RBAC system:
|
|
186
|
+
|
|
187
|
+
**Key Endpoints**:
|
|
188
|
+
- `GET /roles` - List all roles
|
|
189
|
+
- `POST /roles` - Create a new role
|
|
190
|
+
- `GET /operations` - List all operations
|
|
191
|
+
- `POST /operations` - Create a new operation
|
|
192
|
+
- `GET /users/{username}/resources` - Get user's authorized resources
|
|
193
|
+
- `POST /authorization-rules` - Create authorization rules
|
|
194
|
+
|
|
195
|
+
### User Service API
|
|
196
|
+
|
|
197
|
+
**Base Path**: `/user/api-docs`
|
|
198
|
+
|
|
199
|
+
Manages users and user-related data:
|
|
200
|
+
|
|
201
|
+
**Key Endpoints**:
|
|
202
|
+
- `GET /users` - List users (with filtering)
|
|
203
|
+
- `POST /users` - Create a new user
|
|
204
|
+
- `GET /users/{id}` - Get user details
|
|
205
|
+
- `PUT /users/{id}` - Update user
|
|
206
|
+
- `GET /user-states` - Manage user state storage
|
|
207
|
+
- `POST /api-keys` - Generate API keys
|
|
208
|
+
|
|
209
|
+
---
|
|
210
|
+
|
|
211
|
+
## API Request Flow
|
|
212
|
+
|
|
213
|
+
Understanding how API requests flow through the platform:
|
|
214
|
+
|
|
215
|
+
```
|
|
216
|
+
┌──────────────────────────────────────────────────────┐
|
|
217
|
+
│ 1. Client makes API request │
|
|
218
|
+
│ (Browser, Postman, cURL, etc.) │
|
|
219
|
+
└────────────────────┬─────────────────────────────────┘
|
|
220
|
+
│
|
|
221
|
+
▼
|
|
222
|
+
┌──────────────────────────────────────────────────────┐
|
|
223
|
+
│ 2. Gateway receives request │
|
|
224
|
+
│ - Validates JWT token │
|
|
225
|
+
│ - Resolves tenant context │
|
|
226
|
+
│ - Identifies target service from catalog │
|
|
227
|
+
└────────────────────┬─────────────────────────────────┘
|
|
228
|
+
│
|
|
229
|
+
▼
|
|
230
|
+
┌──────────────────────────────────────────────────────┐
|
|
231
|
+
│ 3. Authorization check │
|
|
232
|
+
│ - Verifies user has required operations │
|
|
233
|
+
│ - Evaluates authorization rules │
|
|
234
|
+
│ - Checks tenant-specific restrictions │
|
|
235
|
+
└────────────────────┬─────────────────────────────────┘
|
|
236
|
+
│
|
|
237
|
+
▼
|
|
238
|
+
┌──────────────────────────────────────────────────────┐
|
|
239
|
+
│ 4. Request proxied to target service │
|
|
240
|
+
│ - Gateway adds platform context headers │
|
|
241
|
+
│ - Service processes business logic │
|
|
242
|
+
│ - Service respects tenant isolation │
|
|
243
|
+
└────────────────────┬─────────────────────────────────┘
|
|
244
|
+
│
|
|
245
|
+
▼
|
|
246
|
+
┌──────────────────────────────────────────────────────┐
|
|
247
|
+
│ 5. Response returned to client │
|
|
248
|
+
│ - Gateway forwards service response │
|
|
249
|
+
│ - Client receives data │
|
|
250
|
+
└──────────────────────────────────────────────────────┘
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
---
|
|
254
|
+
|
|
255
|
+
## API Authentication
|
|
256
|
+
|
|
257
|
+
### For Browser-Based Requests
|
|
258
|
+
|
|
259
|
+
When using the API Explorer or making requests from UI applications:
|
|
260
|
+
|
|
261
|
+
```typescript
|
|
262
|
+
// Authentication happens automatically via HTTP-only cookie
|
|
263
|
+
fetch('/catalog/api/applications', {
|
|
264
|
+
method: 'GET',
|
|
265
|
+
credentials: 'include' // Include cookies
|
|
266
|
+
})
|
|
267
|
+
.then(response => response.json())
|
|
268
|
+
.then(data => console.log(data));
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
### For API Keys
|
|
272
|
+
|
|
273
|
+
For programmatic access or service-to-service calls:
|
|
274
|
+
|
|
275
|
+
```bash
|
|
276
|
+
# Using Bearer token
|
|
277
|
+
curl -X GET "https://platform.com/catalog/api/applications" \
|
|
278
|
+
-H "Authorization: Bearer YOUR_API_KEY"
|
|
279
|
+
```
|
|
280
|
+
|
|
281
|
+
**Generate API Keys**:
|
|
282
|
+
1. Navigate to User Service API docs
|
|
283
|
+
2. Use `POST /api-keys` endpoint
|
|
284
|
+
3. Provide description and expiration
|
|
285
|
+
4. Store the generated key securely
|
|
286
|
+
|
|
287
|
+
<Aside type="caution" title="API Key Security">
|
|
288
|
+
- Never commit API keys to version control
|
|
289
|
+
- Use environment variables for key storage
|
|
290
|
+
- Rotate keys regularly
|
|
291
|
+
- Set appropriate expiration dates
|
|
292
|
+
- Revoke compromised keys immediately
|
|
293
|
+
</Aside>
|
|
294
|
+
|
|
295
|
+
---
|
|
296
|
+
|
|
297
|
+
## Business Application APIs
|
|
298
|
+
|
|
299
|
+
Custom applications can expose their own APIs through the platform:
|
|
300
|
+
|
|
301
|
+
### Registering Application APIs
|
|
302
|
+
|
|
303
|
+
When a service registers with the catalog, its endpoints automatically become available:
|
|
304
|
+
|
|
305
|
+
```json
|
|
306
|
+
{
|
|
307
|
+
"name": "@mycompany/orders-service",
|
|
308
|
+
"type": "service",
|
|
309
|
+
"baseUrl": "/api/orders",
|
|
310
|
+
"service": {
|
|
311
|
+
"host": "orders-service",
|
|
312
|
+
"port": 4002
|
|
313
|
+
}
|
|
314
|
+
}
|
|
315
|
+
```
|
|
316
|
+
|
|
317
|
+
**Resulting API Paths**:
|
|
318
|
+
```
|
|
319
|
+
GET /api/orders → List all orders
|
|
320
|
+
POST /api/orders → Create new order
|
|
321
|
+
GET /api/orders/:id → Get order details
|
|
322
|
+
PUT /api/orders/:id → Update order
|
|
323
|
+
DELETE /api/orders/:id → Delete order
|
|
324
|
+
```
|
|
325
|
+
|
|
326
|
+
### Documenting Application APIs
|
|
327
|
+
|
|
328
|
+
Services can provide Swagger documentation:
|
|
329
|
+
|
|
330
|
+
<Tabs>
|
|
331
|
+
<TabItem label="NestJS">
|
|
332
|
+
```typescript
|
|
333
|
+
// main.ts
|
|
334
|
+
import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';
|
|
335
|
+
|
|
336
|
+
const config = new DocumentBuilder()
|
|
337
|
+
.setTitle('Orders Service API')
|
|
338
|
+
.setDescription('API for managing customer orders')
|
|
339
|
+
.setVersion('1.0')
|
|
340
|
+
.addBearerAuth()
|
|
341
|
+
.build();
|
|
342
|
+
|
|
343
|
+
const document = SwaggerModule.createDocument(app, config);
|
|
344
|
+
SwaggerModule.setup('api-docs', app, document);
|
|
345
|
+
```
|
|
346
|
+
</TabItem>
|
|
347
|
+
|
|
348
|
+
<TabItem label="Express">
|
|
349
|
+
```typescript
|
|
350
|
+
// app.ts
|
|
351
|
+
import swaggerJsdoc from 'swagger-jsdoc';
|
|
352
|
+
import swaggerUi from 'swagger-ui-express';
|
|
353
|
+
|
|
354
|
+
const swaggerOptions = {
|
|
355
|
+
definition: {
|
|
356
|
+
openapi: '3.0.0',
|
|
357
|
+
info: {
|
|
358
|
+
title: 'Orders Service API',
|
|
359
|
+
version: '1.0.0',
|
|
360
|
+
},
|
|
361
|
+
},
|
|
362
|
+
apis: ['./routes/*.ts'],
|
|
363
|
+
};
|
|
364
|
+
|
|
365
|
+
const swaggerSpec = swaggerJsdoc(swaggerOptions);
|
|
366
|
+
app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(swaggerSpec));
|
|
367
|
+
```
|
|
368
|
+
</TabItem>
|
|
369
|
+
</Tabs>
|
|
370
|
+
|
|
371
|
+
---
|
|
372
|
+
|
|
373
|
+
## API Response Formats
|
|
374
|
+
|
|
375
|
+
Platform APIs follow consistent response patterns:
|
|
376
|
+
|
|
377
|
+
### Success Response
|
|
378
|
+
|
|
379
|
+
```json
|
|
380
|
+
{
|
|
381
|
+
"statusCode": 200,
|
|
382
|
+
"data": {
|
|
383
|
+
"id": "123",
|
|
384
|
+
"name": "Example Resource"
|
|
385
|
+
}
|
|
386
|
+
}
|
|
387
|
+
```
|
|
388
|
+
|
|
389
|
+
### List Response
|
|
390
|
+
|
|
391
|
+
```json
|
|
392
|
+
{
|
|
393
|
+
"statusCode": 200,
|
|
394
|
+
"data": [
|
|
395
|
+
{ "id": "1", "name": "Item 1" },
|
|
396
|
+
{ "id": "2", "name": "Item 2" }
|
|
397
|
+
],
|
|
398
|
+
"total": 2,
|
|
399
|
+
"page": 1,
|
|
400
|
+
"pageSize": 10
|
|
401
|
+
}
|
|
402
|
+
```
|
|
403
|
+
|
|
404
|
+
### Error Response
|
|
405
|
+
|
|
406
|
+
```json
|
|
407
|
+
{
|
|
408
|
+
"statusCode": 400,
|
|
409
|
+
"message": "Validation failed",
|
|
410
|
+
"error": "Bad Request",
|
|
411
|
+
"timestamp": "2025-01-09T10:30:00Z",
|
|
412
|
+
"path": "/api/orders"
|
|
413
|
+
}
|
|
414
|
+
```
|
|
415
|
+
|
|
416
|
+
---
|
|
417
|
+
|
|
418
|
+
## Best Practices
|
|
419
|
+
|
|
420
|
+
<CardGrid>
|
|
421
|
+
<Card title="Use the API Explorer" icon="rocket">
|
|
422
|
+
Start with the built-in API Explorer for discovery and testing before writing code
|
|
423
|
+
</Card>
|
|
424
|
+
|
|
425
|
+
<Card title="Respect Rate Limits" icon="warning">
|
|
426
|
+
Be mindful of API rate limits and implement appropriate retry logic
|
|
427
|
+
</Card>
|
|
428
|
+
|
|
429
|
+
<Card title="Handle Errors Gracefully" icon="error">
|
|
430
|
+
Always implement proper error handling for API calls
|
|
431
|
+
</Card>
|
|
432
|
+
|
|
433
|
+
<Card title="Validate Input" icon="approve-check">
|
|
434
|
+
Use schema definitions to validate request data before submission
|
|
435
|
+
</Card>
|
|
436
|
+
|
|
437
|
+
<Card title="Secure API Keys" icon="seti:lock">
|
|
438
|
+
Never expose API keys in client-side code or public repositories
|
|
439
|
+
</Card>
|
|
440
|
+
|
|
441
|
+
<Card title="Version APIs" icon="seti:config">
|
|
442
|
+
Plan for API versioning to support backward compatibility
|
|
443
|
+
</Card>
|
|
444
|
+
</CardGrid>
|
|
445
|
+
|
|
446
|
+
---
|
|
447
|
+
|
|
448
|
+
## Troubleshooting
|
|
449
|
+
|
|
450
|
+
### Common Issues
|
|
451
|
+
|
|
452
|
+
**401 Unauthorized**:
|
|
453
|
+
- Verify you're logged in
|
|
454
|
+
- Check if your JWT token is valid
|
|
455
|
+
- Ensure API key is correct (if using key auth)
|
|
456
|
+
|
|
457
|
+
**403 Forbidden**:
|
|
458
|
+
- Verify you have the required operations
|
|
459
|
+
- Check tenant-specific restrictions
|
|
460
|
+
- Confirm application access permissions
|
|
461
|
+
|
|
462
|
+
**404 Not Found**:
|
|
463
|
+
- Verify the endpoint URL is correct
|
|
464
|
+
- Check if the service is registered in the catalog
|
|
465
|
+
- Confirm the module is deployed and running
|
|
466
|
+
|
|
467
|
+
**500 Internal Server Error**:
|
|
468
|
+
- Check service logs for details
|
|
469
|
+
- Verify database connectivity
|
|
470
|
+
- Ensure all dependencies are available
|
|
471
|
+
|
|
472
|
+
---
|
|
473
|
+
|
|
474
|
+
## Next Steps
|
|
475
|
+
|
|
476
|
+
- **[Gateway Architecture](/_/docs/architecture/gateway-architecture/)** - Understand how the gateway routes API requests
|
|
477
|
+
- **[Authorization System](/_/docs/architecture/authorization-system/)** - Learn about API access control
|
|
478
|
+
- **[Authentication System](/_/docs/architecture/authentication-system/)** - Understand API authentication mechanisms
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Architecture Diagrams
|
|
3
|
+
description: Architecture diagrams have been merged into the System Architecture Overview page.
|
|
4
|
+
sidebar:
|
|
5
|
+
hidden: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
import { Aside } from '@astrojs/starlight/components';
|
|
9
|
+
|
|
10
|
+
<Aside type="note">
|
|
11
|
+
The architecture diagrams have been merged into the **[System Architecture Overview](/_/docs/architecture/overview/)** page. All interactive diagrams covering platform topology, request flows, service communication, micro-frontend loading, authentication, catalog lifecycle, and multi-tenancy are available there.
|
|
12
|
+
</Aside>
|