Architecture¶
This document describes the internal architecture of Canvas CLI.
Project Structure¶
canvas-cli/
├── cmd/canvas/ # Application entry point
├── commands/ # CLI command definitions (Cobra)
├── internal/
│ ├── api/ # Canvas API client and services
│ ├── auth/ # OAuth 2.0 + PKCE authentication
│ ├── config/ # Configuration management
│ ├── cache/ # Response caching
│ ├── batch/ # Concurrent batch operations
│ ├── repl/ # Interactive shell
│ └── output/ # Output formatters
├── pkg/ # Public packages
├── docs/ # Documentation
└── test/ # Test fixtures
Component Overview¶
graph LR
subgraph User
CLI[CLI Commands]
REPL[REPL Shell]
end
subgraph Core
API[API Client]
AUTH[Auth Manager]
CFG[Config Manager]
end
subgraph Features
CACHE[Cache]
BATCH[Batch Processor]
OUT[Output Formatter]
end
CLI --> API
REPL --> CLI
API --> AUTH
API --> CACHE
API --> BATCH
CLI --> OUT
AUTH --> CFG
Core Components¶
API Client¶
The API client (internal/api/) provides a type-safe interface to the Canvas REST API.
classDiagram
class Client {
+BaseURL string
+HTTPClient *http.Client
+Get(path, params) Response
+Post(path, body) Response
+Put(path, body) Response
+Delete(path) Response
}
class Service {
+client *Client
}
Client <|-- CoursesService
Client <|-- AssignmentsService
Client <|-- UsersService
Client <|-- ModulesService
Client <|-- PagesService
Client <|-- DiscussionsService
Client <|-- CalendarService
Client <|-- PlannerService
Key features: - Automatic pagination handling - Rate limit awareness - Exponential backoff retry - Request/response logging
Authentication¶
OAuth 2.0 with PKCE (Proof Key for Code Exchange) for secure authentication.
sequenceDiagram
participant User
participant CLI
participant Browser
participant Canvas
User->>CLI: canvas auth login
CLI->>CLI: Generate PKCE verifier + challenge
CLI->>Browser: Open authorization URL
Browser->>Canvas: User authenticates
Canvas->>CLI: Authorization code (callback)
CLI->>Canvas: Exchange code + verifier for token
Canvas->>CLI: Access token + refresh token
CLI->>Keyring: Store tokens securely
Token storage priority: 1. System keyring (macOS Keychain, Windows Credential Manager, Linux Secret Service) 2. Encrypted file fallback (AES-256-GCM)
Rate Limiting¶
Adaptive rate limiting respects Canvas API quotas.
graph TD
REQ[Request] --> CHECK{Check Quota}
CHECK -->|>50%| NORMAL[5 req/sec]
CHECK -->|20-50%| WARN[2 req/sec]
CHECK -->|<20%| CRITICAL[1 req/sec]
NORMAL --> SEND[Send Request]
WARN --> SEND
CRITICAL --> SEND
SEND --> RESP[Response Headers]
RESP --> UPDATE[Update Quota State]
UPDATE --> CHECK
Caching¶
Smart caching with TTL-based invalidation:
| Resource | TTL |
|---|---|
| Courses | 15 minutes |
| Users | 5 minutes |
| Assignments | 10 minutes |
| Modules | 10 minutes |
Batch Processing¶
Concurrent processing with configurable parallelism:
graph LR
INPUT[Items] --> POOL[Worker Pool]
POOL --> W1[Worker 1]
POOL --> W2[Worker 2]
POOL --> W3[Worker 3]
POOL --> W4[Worker 4]
POOL --> W5[Worker 5]
W1 --> COLLECT[Collector]
W2 --> COLLECT
W3 --> COLLECT
W4 --> COLLECT
W5 --> COLLECT
COLLECT --> RESULT[Results + Errors]
Technology Stack¶
| Component | Technology |
|---|---|
| Language | Go 1.21+ |
| CLI Framework | Cobra |
| Configuration | Viper |
| OAuth | golang.org/x/oauth2 |
| Rate Limiting | golang.org/x/time/rate |
| Keyring | zalando/go-keyring |
| Logging | log/slog (stdlib) |
Design Principles¶
- Security First - All credentials encrypted, no hardcoded secrets
- Graceful Degradation - Fallbacks for keyring, network, and API issues
- User Experience - Progress indicators, helpful error messages
- Testability - Interface-driven design, mock-friendly
- Performance - Caching, batching, concurrent operations
Error Handling¶
Custom error types with actionable suggestions:
Testing Strategy¶
- Unit tests for all services
- Integration tests with mock HTTP server
- 90% code coverage target
- Race condition detection enabled