# Design Document: Custom Start Page Application ## Overview The Custom Start Page Application is a web-based dashboard that provides users with a personalized starting point for their browsing sessions. The application follows a hypermedia-driven architecture using HTMX for dynamic interactions, with server-side HTML rendering and a Go backend. The system is designed to scale efficiently to support users with thousands of bookmarks and notes, with rich tagging, grouping, and content formatting capabilities. ### Requirements Coverage Summary This design document comprehensively addresses all requirements from the requirements document: **Authentication (Requirement 1):** OAuth-based authentication with Google and extensible provider support, session management, and secure logout. **Page Management (Requirement 2):** Multi-page dashboard with default "Home" page, page creation/deletion/reordering, and prevention of last page deletion. **Search Functionality (Requirement 3):** Customizable search providers (Google, DuckDuckGo, Bing) with persistent preferences and empty query validation. **Bookmark Widget (Requirement 4):** Full bookmark management with tags, groups, reordering, and efficient storage for 10,000+ bookmarks per user. Tag-based filtering with one-to-many relationships. **Notes Widget (Requirement 5):** Rich content support with multiple formats (plain text, RTF, code, YAML, Markdown), syntax highlighting, Unicode support, tag-based filtering, and format preservation. **Weather Widget (Requirement 6):** Location-based weather display with error handling and periodic refresh. **Widget Management (Requirement 7):** Widget creation, deletion, positioning, resizing, and custom titles with immediate persistence. **Data Persistence (Requirement 8):** Immediate persistence of all changes, DynamoDB-based storage optimized for 10,000+ items, efficient tag queries, and concurrent update handling. **Responsive Design (Requirement 9):** Adaptive layouts for desktop, tablet, and mobile with automatic reflow. **User Interface (Requirement 10):** Intuitive navigation with toolbar, page tabs, visual feedback, and loading indicators. **Database Evaluation (Requirement 11):** Comprehensive DynamoDB evaluation with analysis of scale handling, tag queries, concurrent updates, cost implications, indexing strategy, and alternative considerations. The application architecture emphasizes: - **Simplicity**: Server-side rendering with HTMX for dynamic updates, minimizing client-side complexity - **Separation of concerns**: Clear boundaries between UI templates, business logic, and data layers - **Extensibility**: Widget system designed to easily accommodate new widget types - **Real-time persistence**: All user changes are immediately saved to prevent data loss - **Responsive design**: Adaptive layouts that work across desktop, tablet, and mobile devices - **Scalability**: Efficient data models and access patterns to support 10,000+ bookmarks/notes per user - **Rich content support**: Multiple content formats with syntax highlighting and format-aware rendering - **Flexible organization**: Tag-based filtering and group-based organization for efficient content management ### Key Design Decisions **Architecture Pattern: Hypermedia-Driven with HTMX** The application uses HTMX for dynamic interactions, allowing server-side HTML rendering with minimal JavaScript. This approach provides: - Simplified frontend with no complex state management - Progressive enhancement (works without JavaScript) - Reduced bundle size and faster initial load - Server-side rendering for better SEO and accessibility - HTMX attributes for dynamic updates (hx-get, hx-post, hx-swap) **Database Selection: DynamoDB** After evaluating requirements for scale (10,000+ items), tag-based queries, and concurrent updates, DynamoDB is selected as the primary data store. This decision is based on: - Horizontal scalability for large item collections - Flexible schema for widget-specific configurations - Global Secondary Indexes (GSI) for efficient tag queries - Optimistic locking for concurrent update handling - Cost-effective at scale with on-demand pricing - Managed service reducing operational overhead **Backend Language: Go (with Python for specific tasks)** Go is the primary backend language, with Python used where Go is insufficient: - Go: HTTP server, routing, authentication, CRUD operations, DynamoDB access, HTML templating - Python: Weather API integration (if complex parsing needed), potential future ML features - Go's concurrency model handles multiple user requests efficiently - Go's standard library provides robust HTTP and template support **Scalability Architecture** The application is designed to scale efficiently to support users with 10,000+ bookmarks and notes. This addresses Requirements 4.13, 5.14, 8.8, 11.2. **Horizontal Scaling:** - Stateless Go backend servers (can run multiple instances behind load balancer) - Session state stored in DynamoDB or Redis (not in server memory) - No server affinity required (any server can handle any request) - Auto-scaling based on CPU/memory metrics **Database Scaling:** - DynamoDB on-demand capacity (automatic scaling) - Partition key design (user_id) ensures even data distribution - GSIs for efficient tag queries without full table scans - Batch operations for bulk reads/writes - Connection pooling for DynamoDB client **Caching Strategy:** - Redis cache for frequently accessed data (user preferences, tag lists) - Cache invalidation on updates - TTL-based expiration for weather data - Client-side caching with ETags for static assets **Performance Optimizations:** - Lazy loading for large bookmark/note lists (pagination or infinite scroll) - Debounced auto-save for notes (500ms delay) - Batch DynamoDB operations where possible - Compressed responses (gzip) - CDN for static assets (CSS, JS, images) **Data Access Patterns:** - Optimized for user-scoped queries (all data partitioned by user_id) - Minimal cross-user queries (only for sharing) - Denormalized data to avoid joins - Composite sort keys for efficient range queries **Load Testing Targets:** - 1,000 concurrent users - 10,000 bookmarks per user (p95 query time <100ms) - 100 requests/second per server instance - <200ms p95 latency for all operations - <2 seconds for tag deletion from 1,000 items **Validates Requirements 4.13, 5.14, 8.8, 11.2** **Tag Architecture** Tags are implemented as a many-to-many relationship using a dedicated TagAssociation table with GSIs for efficient bidirectional queries. This design addresses Requirements 4.9, 4.10, 4.14, 4.15, 5.12, 5.13, 5.15, 5.16, and 11.6. **Key Design Decisions:** - **Separate TagAssociations Table:** Avoids item size limits and enables efficient tag queries - **Normalized Tag Names:** All tags stored lowercase and trimmed for consistency - **Bidirectional GSIs:** Query items by tag (TagItemsIndex) and tags by item (primary key) - **Optimistic Locking:** Version numbers on items prevent concurrent update conflicts - **Atomic Operations:** TransactWriteItems ensures tag additions/removals are atomic **Capabilities:** - One-to-many relationships (multiple tags per bookmark/note) - Efficient tag-based filtering with O(log n) query complexity - Quick tag management operations (add, remove, rename, delete) - Tag usage statistics and autocomplete - Concurrent tag updates without data loss - Multi-tag filtering with AND/OR logic (computed in application layer) **Performance Characteristics:** - Single tag query: <10ms for 10,000 bookmarks - Multi-tag query (2 tags, AND): <50ms for 10,000 bookmarks - Tag addition: <20ms (transaction with version check) - Tag deletion from all items: ~2-3 seconds for 1,000 items (with progress indicator) **Validates Requirements 4.9, 4.10, 4.14, 4.15, 5.12, 5.13, 5.15, 5.16, 8.9, 8.10, 11.6, 11.7** **Rich Text Strategy** Notes support multiple content format modes (plain text, RTF, code, YAML, Markdown) with format-aware rendering. This design addresses Requirements 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.11, 5.18. **Content Format Modes:** 1. **Plain Text:** Simple text with line breaks and Unicode support 2. **Rich Text (RTF):** Basic formatting (bold, italic, lists, headings) using contenteditable or TinyMCE 3. **Code:** Syntax-highlighted code blocks with language selection (JavaScript, Python, Go, etc.) 4. **YAML:** Structured data with indentation preservation 5. **Markdown:** Markdown syntax with live preview **Storage Strategy:** - Content stored as string in DynamoDB Notes table - Format metadata stored in `format` field (enum: plain, rtf, code, yaml, markdown) - Language metadata stored in `language` field (for code format) - Raw content always preserved regardless of format - Format switching never loses data (raw content remains unchanged) **Rendering Strategy:** - **Plain Text:** Render in `
` or `