Architecture: How should generated modules connect to backend CRUD?

Documentation for Sessions

🏗️ Architecture: How should generated modules connect to backend CRUD?

Date: 2026-02-25
Time: 14:46:48 UTC
Session: gspace1-138.5
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should generated modules connect to backend CRUD?

Task: Full-stack CRUD generation architecture

🎯 Decision Made

Chosen:

Dynamic/generic CRUD via existing DataController + UniverseDataService on frontend

Options Considered:

Generate full NestJS code (controllers, services, schemas)
Dynamic/generic CRUD via existing DataController
Hybrid: dynamic CRUD with optional code ejection

💭 Reasoning

The platform already has DataController (apis/backend-api/src/app/data/data.controller.ts) providing generic REST endpoints for any collection (query, insert, update, delete) with multi-tenant isolation (one DB per space, collections per universe). No NestJS code generation needed. Frontend services are auto-corrected to use UniverseDataService (@libs-foundational/core-angular) which handles spaceId/universeId resolution, caching, and DataController URL construction. Entity schemas are pushed via BACKEND_SETUP phase using SYSTEM_TOKEN auth. This avoids NestJS restart requirements and leverages existing infrastructure.

📁 Files Involved

apis/backend-api/src/app/data/data.controller.ts
libs/libs-foundational/core-angular/src/lib/services/universe-data.service.ts
apis/backend-vitto-api/src/app/module-generation/phases/backend-setup.phase.ts
apis/backend-vitto-api/src/app/module-generation/validation/auto-correction.service.ts

🔗 Related

Decision ID: dev_1772030807418_h2z45kv
Session: 138
Workspace: gspace1

Auto-generated by MCP Smart Consolidation