Varför Edge Functions för AI

Tre anledningar till att Edge Functions är rätt val för AI API-anrop:

1. **Säkerhet**: Din OpenAI/Anthropic API-nyckel lever som en serversidig hemlighet, aldrig exponerad för klienten. Ingen med din frontendkod kan extrahera nyckeln.

2. **Databasåtkomst**: Edge Functions körs inuti Supabase infrastruktur och har direkt, låg-latens åtkomst till din PostgreSQL-databas. Du kan hämta användarkontext, lagra resultat och logga användning i samma funktion som anropar AI.

3. **Strömningsstöd**: Edge Functions stöder Response-strömning, vilket låter dig skicka AI-output till klienten ord för ord — dramatiskt förbättrar upplevd prestanda för långa AI-svar.

För svenska bolag finns ytterligare ett skäl: EU-väst-regionen i Supabase innebär att din Edge Function exekveras i EU, vilket förenklar GDPR-dokumentation och minskar latens för svenska användare.

Grundläggande OpenAI proxy-funktion

Den enklaste Edge Function: ta emot en prompt, anropa OpenAI, returnera svaret.

Struktur: importera OpenAI npm-paketet, initiera klienten med nyckeln från Deno.env, ta emot prompt från request body, anropa chat.completions.create med gpt-4o-modellen och max_tokens 500, returnera resultattexten som JSON.

Distribuera med: `supabase functions deploy openai-proxy`. Ange hemligheten: `supabase secrets set OPENAI_API_KEY=sk-...`.

Enkel men komplett — och säker. Inga API-nycklar i WeWeb eller FlutterFlow-koden.

Lägga till autentisering och hastighetsbegränsning

Varje AI Edge Function bör verifiera att användaren är autentiserad och kontrollera deras användningsgränser.

Mönstret: extrahera JWT-token från Authorization-headern, skapa en Supabase-klient med service role-nyckel, anropa auth.getUser(token) för att verifiera, returnera 401 om ogiltigt.

För hastighetsbegränsning: fråga ai_usage_log-tabellen efter count där user_id matchar och created_at är inom den senaste timmen. Returnera 429 om count >= 20 (eller din valda gräns).

Logga sedan varje lyckad AI-förfrågan till tabellen. Det ger dig inte bara hastighetsbegränsning utan också fullständig revisionslogg — viktigt för GDPR-artikel 5-efterlevnad och för att förstå vilka funktioner som faktiskt används av svenska kunder.

Strömning av svar till WeWeb

Strömning skickar AI-output till klienten progressivt — användare ser text visas ord för ord istället för att vänta på hela svaret.

I Edge Function: skapa en OpenAI-completionförfrågan med `stream: true`, bygg en ReadableStream som itererar över varje chunk och encodar texten, returnera med Content-Type: text/event-stream.

I WeWeb: använd en anpassad JavaScript-åtgärd för att hämta stream-URL:en och uppdatera en sidvariabel tecken för tecken när chunk ankommer. Bind en textruta till variabeln för realtidsvisning.

Strömning förbättrar upplevd prestanda dramatiskt. För en svensk B2B-app där yrkesverksamma väntar på AI-svar är skillnaden mellan "väntar 5 sekunder" och "ser text genereras direkt" avgörande för produktacceptans.

Bygga en RAG-pipeline (Retrieval Augmented Generation)

RAG förbättrar AI-svar genom att injicera relevant kunskap i prompten vid förfrågningstid. Arkitektur:

1. **Kunskapsinsamling** (kör en gång): För varje dokument i din kunskapsbas, anropa OpenAIs embedding-API för att få en 1536-dimensionell vektor. Lagra vektorer i Supabase med pgvector-tillägget.

2. **Förfrågningstid**: När en användare ställer en fråga, bädda in frågan (samma embedding-API), kör sedan en likhetssökning i Supabase: `SELECT content, 1 - (embedding <=> query_embedding) AS similarity FROM documents ORDER BY similarity DESC LIMIT 3`.

3. **Utökad prompt**: Injicera de 3 bäst matchande dokumenten i systemprompten: "Svara enbart med följande kontext: [docs]. Om svaret inte finns i kontexten, säg att du inte vet."

Resultat: AI:n svarar enbart från din dokumentation, utan hallucination om saker du inte dokumenterat. Perfekt för svenska kundtjänstbottar med branschspecifik kunskapsbas.