🏗️ Architecture: Where should shared messaging infrastructure (Twilio, channe...

Date: 2026-02-18
Time: 15:28:43 UTC
Session: gspace1-117.3
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Where should shared messaging infrastructure (Twilio, channel CRUD, schemas) live?

Task: Extract messaging infrastructure to shared NestJS library - Session 117

🎯 Decision Made

Chosen:

Create @libs-api/messaging-core shared NestJS lib following auth-core pattern

Options Considered:

1. Keep in backend-vitto-api (current)
2. Create @libs-api/messaging-core shared NestJS lib
3. Create separate lib per provider (twilio-core, sendgrid-core)

💭 Reasoning

Messaging will be needed by multiple backends (backend-api for notifications, backend-ai-api for AI alerts, backend-vitto-api for agent communication). Following the exact same pattern as @libs-api/auth-core: @Global() dynamic module with forRoot/forRootAsync, configurable env var key names, MongooseModule.forFeature for channel schema. Backend-vitto-api retains Vitto-specific routing/webhook logic as a thin wrapper. Any backend can now just MessagingCoreModule.forRoot() and get TwilioService + ChannelService.

📁 Files Involved

• libs/libs-api/messaging-core/src/lib/messaging-core.module.ts
• libs/libs-api/messaging-core/src/lib/services/twilio.service.ts
• libs/libs-api/messaging-core/src/lib/services/channel.service.ts
• libs/libs-api/messaging-core/src/lib/schemas/channel.schema.ts
• libs/libs-api/messaging-core/src/lib/interfaces/messaging.interfaces.ts
• apis/backend-vitto-api/src/app/connectivity/connectivity.module.ts
• apis/backend-vitto-api/src/app/connectivity/channel-gateway.service.ts

🔗 Related

• Decision ID: dev_1771428523829_1inn4ua
• Session: 117
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation