canva-architecture-variants

# Canva Architecture Variants ## Overview Three validated architecture patterns for Canva Connect API integrations. All use the REST API at `api.canva.com/rest/v1/*` with OAuth 2.0 PKCE tokens. The key architectural decision is how to handle token storage, async operations (exports, autofills), and rate limit management. ## Variant A: Monolith (Simple) **Best for:** MVPs, small teams, < 100 Canva users ``` my-app/ ├── src/ │ ├── canva/ │ │ ├── client.ts # REST client with auto-refresh │ │ ├── auth.ts # OAuth PKCE flow │ │ └── types.ts │ ├── routes/ │ │ ├── auth.ts # OAuth callback │ │ └── designs.ts # Design CRUD │ ├── store/ │ │ └── tokens.ts # SQLite/file token store │ └── index.ts ``` ```typescript // Direct API calls in route handlers app.post('/api/designs', async (req, res) => { const canva = getClientForUser(req.user.id); const { design } = await canva.request('/designs', { method: 'POST', body: JSON.stringify({ design_type: { type: 'custom', width: 1080, height: 1080 }, title: req.body.title, }), }); res.json({ designId: design.id, editUrl: design.urls.edit_url }); }); ``` **Pros:** Fast to build, simple token management, easy to debug. **Cons:** Synchronous exports block requests, no job queue for autofills. --- ## Variant B: Service Layer (Moderate) **Best for:** Growing apps, 100-1,000 users, multiple Canva features ``` my-app/ ├── src/ │ ├...