Lewati ke konten

Referensi Edge Function

Semua edge function memakai service-role key di sisi server saja (tidak pernah dikirim ke browser), menerima/menolak lewat Authorization: Bearer <token> (JWT Supabase Auth) kecuali disebut lain, dan menangani OPTIONS untuk CORS. Lima dari enam fungsi dipanggil otomatis oleh aplikasi; hanya push-notifications (aksi dispatch) yang dipicu oleh scheduler/cron eksternal dengan header rahasia terpisah.

Membangun system prompt untuk asisten AI bisnis (“Asisten Catering AI”) dan meneruskan percakapan ke penyedia LLM.

  • Autentikasi: wajib login dan profil berstatus active.
  • Alur: mengambil konteks bisnis lewat RPC ai_chat_business_context (dipanggil atas nama user yang login, bukan service-role, supaya RLS tetap berlaku), lalu memanggil Gemini (model utama) dengan fallback ke OpenAI (gpt-4o-mini) jika kunci Gemini tidak diatur.
  • Env var yang dibutuhkan: GEMINI_API_KEY dan/atau OPENAI_API_KEY.

Membuat ringkasan harian bisnis (pesanan, omset, stok menipis, kehadiran, dll.) memakai AI, dan menyimpan hasilnya sebagai cache.

  • Autentikasi: wajib login dan profil berstatus active.
  • Alur: agregasi data lewat RPC ai_daily_summary_data, kirim ke Gemini untuk diringkas, simpan hasil lewat RPC ai_daily_summary_save (disimpan di legacy_documents tabel aiDailySummaryCache) agar pembacaan cache di frontend tidak perlu berubah.
  • Env var: GEMINI_API_KEY.

Memprediksi permintaan produk ke depan berdasarkan riwayat pesanan.

  • Autentikasi: wajib login dan profil berstatus active.
  • Alur: mengambil histori pesanan lewat RPC ai_demand_order_history (parameter p_lookback_days), kirim ke Gemini untuk menghasilkan prediksi.
  • Env var: GEMINI_API_KEY.

Mendukung panel “Test Koneksi Layanan” di halaman Pengaturan — mengecek apakah API key Gemini yang dikonfigurasi benar-benar berfungsi.

  • Autentikasi: wajib login dan profil berstatus active.
  • Alur: mengirim prompt minimal (“Jawab hanya: OK”) ke Gemini dan melaporkan status koneksi beserta nama model.
  • Env var: GEMINI_API_KEY.

Mengambil detail pesanan untuk Portal Pelanggan (bertoken, publik — tanpa akun Supabase Auth), termasuk foto bukti pengiriman.

  • Autentikasi: memverifikasi token portal (bukan JWT Supabase Auth) lewat RPC portal_order_detail dan portal_token_validate; fungsi ini dideploy dengan verify_jwt=false karena pengunjung portal tidak punya sesi Supabase Auth. Nomor telepon pemilik token dicocokkan ulang di sisi server terhadap data pesanan sebagai lapisan keamanan tambahan.
  • Keamanan khusus: /cek-pesanan (yang hanya butuh nomor pesanan) sengaja tidak memakai endpoint ini, supaya tebak-tebakan nomor pesanan tidak bisa membocorkan foto bukti pengiriman — hanya alur Portal bertoken yang bisa mengaksesnya.
  • Lainnya: foto bukti pengiriman dikembalikan sebagai signed URL (berlaku 10 menit), bukan URL permanen.

Mengelola web push notification: pendaftaran perangkat, validasi, dan pengiriman notifikasi terjadwal.

  • Autentikasi: campuran — pendaftaran (subscribe) menerima baik user yang login (profil active) maupun pengunjung portal (token portal tervalidasi); aksi dispatch (pengiriman notifikasi dari antrean) divalidasi lewat header x-dispatch-secret, bukan JWT.
  • Alur dispatch: mengambil item dari push_notification_queue berstatus pending, mengirim lewat Web Push API (npm:web-push) memakai VAPID key, lalu menandai langganan yang sudah tidak valid (HTTP 404/410) sebagai nonaktif.
  • Env var: VAPID_PUBLIC_KEY, VAPID_PRIVATE_KEY, VAPID_SUBJECT, PUSH_DISPATCH_SECRET.

Sumber: supabase/functions/ai-chat/index.ts, supabase/functions/ai-daily-summary/index.ts, supabase/functions/ai-demand-prediction/index.ts, supabase/functions/connection-test/index.ts, supabase/functions/portal-order-detail/index.ts, supabase/functions/push-notifications/index.ts.