Vault restructure

Corpus/🎇 Sparks/Deciding which functionality goes where.md

@@ -0,0 +1,125 @@
+---
+tags:
+  - iso27DIY
+  - stack
+  - WeWeb
+  - SupaBase
+  - dev
+  - design
+---
+# Deciding which functionality goes where
+
+Here’s a decision framework to help you choose the right approach for each piece of functionality:
+
+## WeWeb (Frontend Logic)
+
+**Use when:**
+
+- UI/UX logic and interactions
+- Client-side data formatting and presentation
+- Form validation (basic, user-facing)
+- Navigation and routing logic
+- Real-time UI updates from Supabase subscriptions
+- Simple calculations that don’t need to be secured
+
+**Examples:** Date formatting, sorting/filtering displays, form field validation, conditional UI rendering
+
+## SQL Functions + RPC
+
+**Use when:**
+
+- Complex data operations involving multiple tables
+- Business logic that must be consistent and secure
+- Performance-critical operations (closer to data)
+- Data validation that can’t be bypassed
+- Calculations that need to be atomic
+- Logic that might be reused across different clients
+
+**Examples:** User permission checks, complex reporting calculations, multi-step data updates, financial calculations
+
+## Edge Functions
+
+**Use when:**
+
+- External API integrations (payments, email, webhooks)
+- Heavy computational tasks
+- File processing and transformations
+- Custom authentication flows
+- Business logic that needs full programming language capabilities
+- Third-party service communications
+
+**Examples:** Stripe payment processing, PDF generation, image resizing, sending emails, complex AI/ML operations
+
+## Database Triggers
+
+**Use when:**
+
+- Automatic responses to data changes
+- Audit logging and history tracking
+- Data consistency enforcement
+- Background maintenance tasks
+- Cross-table updates that must happen atomically
+
+**Examples:** Updating timestamps, creating audit logs, maintaining calculated fields, sending notifications on data changes
+
+## Decision Matrix
+
+**Performance Priority:**
+
+- SQL Functions > Database Triggers > Edge Functions > WeWeb
+
+**Security Requirements:**
+
+- Database Triggers ≥ SQL Functions > Edge Functions > WeWeb
+
+**External Integration Needs:**
+
+- Edge Functions > WeWeb > SQL Functions > Database Triggers
+
+**Complexity of Logic:**
+
+- Edge Functions > SQL Functions > WeWeb > Database Triggers
+
+**Real-time Requirements:**
+
+- Database Triggers > SQL Functions > WeWeb > Edge Functions
+
+## Practical Examples
+
+**User Registration Flow:**
+
+- WeWeb: Form UI and basic validation
+- Edge Function: Email verification, external service calls
+- SQL Function: Create user profile with complex business rules
+- Database Trigger: Create related records, audit log
+
+**E-commerce Order Processing:**
+
+- WeWeb: Shopping cart UI, order summary
+- SQL Function: Inventory checks, price calculations
+- Database Trigger: Update inventory, create audit trail
+- Edge Function: Payment processing, order confirmation emails
+
+**Reporting Dashboard:**
+
+- WeWeb: Charts, filters, display logic
+- SQL Function: Complex data aggregations
+- Database Trigger: Update materialized views
+- Edge Function: Export to PDF, email reports
+
+## General Guidelines
+
+**Start with the data layer and work outward:**
+
+1. Database Triggers for automatic data consistency
+2. SQL Functions for secure business logic
+3. Edge Functions for external integrations
+4. WeWeb for user interface and experience
+
+**Security rule:** Never trust the client - critical business logic should be in SQL Functions or Edge Functions, not WeWeb.
+
+**Performance rule:** Keep data-heavy operations close to the database (SQL Functions/Triggers).
+
+**Maintainability rule:** Keep similar logic in the same layer when possible.
+
+The key is often using multiple approaches together rather than choosing just one - they complement each other in a well-architected application.​​​​​​​​​​​​​​​​