Architecture
API Architecture Overview
How CafeRadar's API layer works: Supabase PostgREST, Edge Functions, and RPC patterns.
Last updated March 19, 2026
API Architecture Overview
CafeRadar uses Supabase as its backend, which provides three API surface areas:
PostgREST (Auto-generated REST API)
Every table and view in the public schema gets a REST endpoint automatically. Row Level Security (RLS) policies control access.
GET /rest/v1/cafes?select=id,name,lat,lng&lat=gte.41.0&lat=lte.42.0
RPC (Remote Procedure Calls)
Complex queries are exposed as PostgreSQL functions called via /rest/v1/rpc/<function_name>.
Examples:
find_nearby_cafes(lat, lng, radius_m)-- geo-filtered discoverysearch_cafes_full(query, lat, lng)-- trigram + unaccent full-text searchget_home_dashboard(user_lat, user_lng)-- personalized home feed
Edge Functions (Deno)
26 serverless functions for operations that need external APIs, scheduled tasks, or complex orchestration.
All edge functions use the shared _shared/auth.ts module for Clerk JWT verification and _shared/cors.ts for CORS headers.
Authentication
Mobile app uses Clerk for authentication. JWTs are sent via X-Clerk-Token header. Edge functions verify against Clerk's JWKS endpoint with PEM fallback.
Admin portal uses PBKDF2 password hashing with in-memory sessions. Merchant portal uses Clerk + email OTP 2FA.