| name | canva-architecture-variants |
| description | Choose and implement Canva Connect API architecture blueprints for different scales.
Use when designing new Canva integrations, choosing between monolith/service/microservice
architectures, or planning migration paths.
Trigger with phrases like "canva architecture", "canva blueprint",
"how to structure canva", "canva project layout", "canva microservice".
|
| allowed-tools | Read, Grep |
| version | 1.5.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","design","canva"] |
| compatibility | Designed for Claude Code |
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
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.