125 lines
No EOL
3.7 KiB
Markdown
125 lines
No EOL
3.7 KiB
Markdown
---
|
||
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. |