🎨 Pattern: How should the API executor plugin architecture be designed ...

Date: 2026-03-31
Time: 19:06:47 UTC
Session: gspace1-290.28
Agent: backend
Confidence: 91%
Status: ✅ Documented

📋 Decision Context

Question:

How should the API executor plugin architecture be designed for extensibility?

Task: S289: OAuth-First Intelligent Task Execution

🎯 Decision Made

Chosen:

ApiExecutor interface + ApiExecutorRegistry + per-service executor classes (GmailApiExecutor). Registry auto-registers executors via OnModuleInit constructor injection. Each executor declares serviceId, provider, supportedActions. callProxy helper centralizes error handling and type safety.

Options Considered:

1. 1. Single monolithic executor handling all services
2. 2. Per-service executor classes with registry (clean, extensible)
3. 3. Dynamic executor loading from config/database
4. 4. Decorator-based auto-registration (@ApiExecutor())

💭 Reasoning

The registry pattern allows future Calendar and GitHub executors to be added with zero changes to the router or supervisor. Each executor is a focused NestJS injectable that implements a simple interface (canHandle + execute). The callProxy helper in GmailApiExecutor consolidates all 5 actions' error handling into one place — typed OAuthProxyResponse interface eliminates (result as any) casts. The OnModuleInit registration means executors are ready before any request is processed. Future improvement: use multi-provider injection token ('API_EXECUTORS') when the number of executors grows beyond 3.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/api-executors/api-executor.interface.ts
• APIs/backend-vitto-api/src/app/engine/api-executors/api-executor.registry.ts
• APIs/backend-vitto-api/src/app/engine/api-executors/gmail-api.executor.ts

🔗 Related

• Decision ID: dev_1774984003517_2pfhckj
• Session: 290
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation