---
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.​​​​​​​​​​​​​​​​