Architecture: Should preview use mock data stubs or real backend HTTP for ...

Documentation for Sessions

🏗️ Architecture: Should preview use mock data stubs or real backend HTTP for ...

Date: 2026-03-16
Time: 15:18:55 UTC
Session: gspace1-225.3
Agent: backend
Confidence: 85%
Status: ✅ Documented

📋 Decision Context

Question:

Should preview use mock data stubs or real backend HTTP for CRUD operations?

Task: Not specified

🎯 Decision Made

Chosen:

Real HTTP proxy to backend-api (port 3000). UniverseDataService stub makes actual POST/PUT/DELETE calls to the same REST endpoints the deployed platform will use. Graceful catchError fallback returns empty data if backend unavailable.

Options Considered:

Noop stubs returning of([]) — rejected: hides real capability
Mock API with seed data (gmodules1 pattern) — rejected: unnecessary when real backend exists
Real HTTP proxy with catchError fallback (chosen) — leverages existing infrastructure

💭 Reasoning

gspace1 already has 4 real NestJS backends with MongoDB, UniverseDataService, and Cloudflare R2. The generated code is already wired to call UniverseDataService.query(). Using noop stubs that return of([]) defeats the purpose — gmodules1 (which has NO real backend) shows more data than gspace1 (which has full infra). The blob URL iframe origin http://localhost:6200 passes CORS (cors.factory.ts allows all localhost). spaceId/universeId available in SdkPreviewConfig. Auth guard may block requests — catchError handles this gracefully.

📁 Files Involved

libs/libs-structural/platform-preview/src/lib/config/sdk-preview-stubs.ts
libs/libs-structural/platform-preview/src/lib/services/bundler-filesystem.service.ts

🔗 Related

Decision ID: dev_1773674335858_rk7run4
Session: 225
Workspace: gspace1

Auto-generated by MCP Smart Consolidation