Back to Docs

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 discovery
  • search_cafes_full(query, lat, lng) -- trigram + unaccent full-text search
  • get_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.