Supabase Edge Functions
Relevant source files
The following files were used as context for generating this wiki page:
Supabase Edge Functions in the mdeapp project serve as the server-side logic layer for handling complex workflows that exceed the capabilities of standard database operations. They are designed to manage external integrations, such as payment processing and lead capture, while maintaining high performance through a distributed runtime.
These functions are part of the Phase 1 architectural target, specifically supporting discovery and ticketing features for the Medellín platform. They interact closely with the Supabase database schema, utilizing specific schemas like public for general events and sponsor for organizational assets.
Sources: README.md:9-16, supabase/README.md:27-29
Runtime Configuration
The Edge Functions are powered by the Supabase Edge Runtime, which uses Deno. The configuration for local development and deployment is managed via the project's central configuration file.
Edge Runtime Settings
The environment is configured to support hot reloading during local development and provides a dedicated port for debugging.
| Parameter | Value | Description |
|---|---|---|
| Enabled | true | Enables the Edge Runtime environment |
| Policy | per_worker | Enables hot reload during local development |
| Inspector Port | 8083 | Port for attaching the Chrome inspector for debugging |
| Deno Version | 2 | Specifies the major version of Deno used |
Sources: supabase/config.toml:343-353
Functional Architecture
Edge Functions are categorized by their business domain, primarily focusing on the ticketing lifecycle and lead management. The project architecture leverages these functions as "bridge" components between the AI agent runtime (Mastra) and external services like Stripe.
Core Functions Registry
The following functions are identified as Phase 1 targets or active components:
chat-lead-capture: Captures user information during AI chat interactions.ticket-checkout: Manages the initiation of ticket purchases, including generating UUIDs for attendees.ticket-payment-webhook: Processes asynchronous payment notifications from Stripe.staff-link-revoke: Endpoint used to invalidate door-staff JWTs by bumping versioning in the database.
Sources: supabase/README.md:27-29, supabase/migrations/20260503011925_event_phase1.sql:468-472, package.json:28-31
Data Flow: Ticket Purchase
The Edge Functions coordinate with Database RPCs to ensure atomic operations during the checkout process.
The diagram shows the coordination between the Edge Function and the database to prevent overselling tickets during concurrent requests.
Sources: supabase/migrations/20260503011925_event_phase1.sql:357-418
Security and Authentication
Edge Functions operate within a specific security context, often utilizing the service_role key to perform elevated database operations or verifying user JWTs for authenticated requests.
Access Control Lists (ACL)
Specific schemas are designed to facilitate Edge Function ACL tests. For instance, the sponsor schema uses Row Level Security (RLS) to ensure that Edge Function lookups (e.g., sponsor.* lookups) are restricted based on ownership or roles.
- Service Role Access: Functions often bypass standard RLS via the
service_roleto perform system-level updates, such as finalizing payments. - Staff JWTs: The
eventstable includes astaff_link_versioncolumn. Bumping this version through an Edge Function (or RPC) revokes all outstanding door-staff JWTs for that event.
Sources: supabase/migrations/20260512120000_sponsor_schema_edge_acl.sql:1-10, supabase/migrations/20260503011925_event_phase1.sql:98-99, supabase/migrations/20260503011925_event_phase1.sql:338-349
Integration with Database RPCs
Edge Functions frequently act as wrappers for SECURITY DEFINER stored procedures. This pattern ensures that sensitive logic (like atomic inventory management) remains in the database while the Edge Function handles HTTP-related concerns.
Key RPCs Orchestrated by Functions
| RPC Name | Purpose | Called By |
|---|---|---|
ticket_checkout_create_pending | Atomic capacity check and pending record creation | ticket-checkout function |
ticket_payment_finalize | Converts pending reservations to sold tickets | ticket-payment-webhook |
record_check_in | Logs scan attempts for door staff | Event management logic |
get_anonymous_order | Allows ticket retrieval via opaque access token | Frontend via API |
Sources: supabase/migrations/20260503011925_event_phase1.sql:22-35, supabase/migrations/20260503011925_event_phase1.sql:440-444
Development and Testing
The project utilizes npm scripts to verify and smoke-test Edge Functions, particularly for the ticketing and lead capture flows.
{
"scripts": {
"smoke:lead-capture": "node --env-file=.env.local scripts/smoke-lead-capture.mjs",
"smoke:ticket-checkout": "node --env-file=.env.local scripts/smoke-ticket-checkout.mjs",
"smoke:ticket-paid-proof": "node --env-file=.env.local scripts/smoke-ticket-paid-proof.mjs"
}
}
Sources: package.json:28-31
Supabase Edge Functions are critical for bridging the gap between the AI-driven frontend and the transactional backend, particularly for external payment systems and secure event management. Their significance lies in providing a secure, scalable environment for logic that must run outside the database while maintaining tight integration with the project's SQL schema and RLS policies.
Sources: README.md:12-16, supabase/README.md:27-29