移动性能与Supabase边缘函数分析提示

### 🔴 Critical Issues 1. **Edge Function Cold Start Stacking on App Launch** - The `auth-validate` Edge Function is called synchronously during session restore. If the Edge Function is cold (e.g., after a period of inactivity), the user sees a blank or loading screen for 1–3 seconds on a slow network. This is UX-breaking. - **Why**: The function imports `@supabase/supabase-js` and `crypto` eagerly, adding ~500ms–1s to cold start. The mobile app has no timeout or fallback to local session validation. 2. **Blocking UI on Edge Responses in `profile-fetch`** - The profile screen awaits the Edge Function response before rendering any content. On a cold start (e.g., first open of the day), the screen is blank for 2–4 seconds. No optimistic UI or cached profile is shown. - **Why**: The function performs an external API call (e.g., to a CRM) inside the Edge Function, adding network latency on top of cold start. The mobile client does not use a local cache or placeholder. 3. **Heavy AI Call in `recommendation-engine`** - This Edge Function runs a large language model inference (e.g., GPT-4) synchronously. On mobile, this can take 5–10 seconds, and the user is left staring at a spinner. The function is called from the home screen on every app open. - **Why**: AI inference is not suitable for a serverless Edge Function with a 10-second timeout. It should be a background job or a dedicated server with streaming. ### 🟠 Moderate Risks 1. **Eager Imports in `payment-webhook`** - The function imports `stripe` and `axios` at the top level. This increases cold start time by ~300ms. Since this is called from Stripe (not the mobile app), the impact is backend-only, but it still delays payment confirmation notifications to the user. 2. **No Lazy Loading in `image-optimizer`** - The function imports `sharp` eagerly, which is a heavy native dependency. Cold start is ~1.5s. This is called when a user uploads a photo, which is a frequent action. The user sees a "uploading" state for longer than necessary. 3. **Session Restore Without Local Cache** - The mobile app does not cache the session token locally (e.g., in AsyncStorage). Every app launch triggers a full Edge Function validation, even if the token is still valid. This adds unnecessary network round-trips and cold start risk. 4. **Unnecessary Synchronous Waits in `order-status`** - The app polls this Edge Function every 5 seconds while the user is on the order tracking screen. Each poll is a synchronous network call. On a slow network, this can cause UI jank and battery drain. ### 🟢 Acceptable / Well-Designed Areas 1. **`auth-validate` Uses JWT Verification** - The function verifies the JWT locally using `crypto` instead of making a database call. This is efficient and reduces cold start impact. 2. **`profile-fetch` Has a Timeout** - The mobile client has a 5-second timeout on the Edge Function call. This prevents infinite loading, though it still blocks the UI. 3. **`recommendation-engine` Is Called Only on Home Screen** - It is not called during app launch or critical navigation, so the impact is limited to one screen. --- ## 3. Edge Function Classification | Function | Role | Correct Runtime? | Should Be | |----------|------|------------------|-----------| | `auth-validate` | Auth / Guard | Yes | Edge (fast, stateless) | | `profile-fetch` | Orchestration | No | Server (external API calls) | | `recommendation-engine` | Heavy compute | No | Server or Worker (AI inference) | | `payment-webhook` | External API proxy | Yes | Edge (webhook, low latency) | | `image-optimizer` | Heavy compute | No | Worker (CPU-bound, long-running) | | `order-status` | Validation / Policy | Yes | Edge (simple DB read) | --- ## 4. Mobile-Specific Flow Analysis ### Flow 1: App Cold Start → First Edge Call - **Blocking**: `auth-validate` is called synchronously. If cold, user sees splash screen for 1–3s. - **Cold Start Stacking**: The Edge Function cold start + network latency + JWT verification = 2–4s total. - **Unnecessary Synchronous Waits**: The app does not proceed until the Edge Function responds, even if the token is locally valid. ### Flow 2: Session Restore → Edge Validation - **Blocking**: Same as above. The app does not use a local cache. - **Cold Start Stacking**: If the user opens the app after 10 minutes, the Edge Function is likely cold. - **Unnecessary Synchronous Waits**: The app could validate the token locally first and only call Edge if the token is expired. ### Flow 3: User-Triggered Action → Edge Request - **Example**: User taps "Upload Photo" → `image-optimizer` is called. - **Blocking**: The UI shows a spinner until the Edge Function returns the optimized image URL. Cold start + sharp import = 2–3s. - **Cold Start Stacking**: If the user uploads multiple photos in a row, each call may hit a cold instance. ### Flow 4: Background → Foreground Resume - **Blocking**: The app re-validates the session via `auth-validate` on every foreground resume. This is unnecessary if the token is still valid. - **Cold Start Stacking**: Frequent background/foreground cycles can cause repeated cold starts. --- ## 5. Performance & Latency Budget | Function | Cold Start Impact | Hot Start Behavior | Worst-Case Perceived Latency | |----------|-------------------|--------------------|------------------------------| | `auth-validate` | Medium (~1s) | Fast (~100ms) | UX-breaking (2–4s on cold) | | `profile-fetch` | Medium (~1s) | Moderate (~500ms) | UX-breaking (3–5s on cold) | | `recommendation-engine` | High (~2s) | Slow (~5s) | UX-breaking (7–10s on cold) | | `payment-webhook` | Medium (~1s) | Fast (~200ms) | Noticeable (backend only) | | `image-optimizer` | High (~1.5s) | Moderate (~1s) | Noticeable (2–3s on cold) | | `order-status` | Low (~500ms) | Fast (~100ms) | Invisible (if cached) | --- ## 6. Findings Format ### 🔴 Critical Issues 1. **Cold start stacking on app launch** – `auth-validate` blocks the UI, and the app does not use a local session cache. 2. **Blocking UI on `profile-fetch`** – No optimistic UI or cached data; the screen is blank during cold start. 3. **Heavy AI call in `recommendation-engine`** – Synchronous AI inference is unsuitable for Edge and causes 5–10s waits. ### 🟠 Moderate Risks 1. **Eager imports in `payment-webhook` and `image-optimizer`** – Increase cold start time unnecessarily. 2. **No local session cache** – Every app launch triggers a full Edge validation. 3. **Polling `order-status` every 5s** – Causes network churn and potential UI jank on slow networks. ### 🟢 Acceptable / Well-Designed Areas 1. **JWT verification in `auth-validate`** – Efficient and avoids database calls. 2. **Timeout on `profile-fetch`** – Prevents infinite loading. 3. **`order-status` is a simple DB read** – Appropriate for Edge. --- ## 7. Recommendations 1. **Add a local session cache in the mobile app** - **What**: Store the JWT and its expiry in AsyncStorage. On app launch, validate the token locally first. Only call `auth-validate` if the token is expired or missing. - **Why**: Eliminates the cold start stacking on app launch and session restore. - **Impact**: Reduces perceived launch time from 2–4s to <500ms. 2. **Move `recommendation-engine` to a background job** - **What**: Trigger the AI inference via a queue (e.g., Supabase Edge Function that enqueues a job) and have the mobile app poll or receive a push notification when results are ready. - **Why**: AI inference is too slow for synchronous Edge calls and will cause UX-breaking waits. - **Impact**: Home screen loads instantly; recommendations appear asynchronously. 3. **Use optimistic UI for `profile-fetch`** - **What**: Show cached profile data immediately, then update in the background when the Edge Function responds. - **Why**: The user does not need to wait for a cold start to see their profile. - **Impact**: Perceived latency drops from 3–5s to <100ms. 4. **Lazy-load heavy imports in `image-optimizer`** - **What**: Import `sharp` only inside the request handler, not at the top level. - **Why**: Reduces cold start time by ~1s. - **Impact**: Faster image uploads, especially on first use. 5. **Replace polling with push notifications for `order-status`** - **What**: Use Supabase Realtime or a push notification service to update the order status. - **Why**: Polling every 5s is wasteful and causes UI jank on slow networks. - **Impact**: Reduced battery drain and smoother UI. --- ## 8. Final Verdict - **Is this architecture mobile-appropriate?** No. The architecture treats Edge Functions as a general-purpose backend, which is inappropriate for mobile apps where cold start latency and network instability are first-class concerns. - **Is Edge overused, underused, or correctly used?** Overused. Edge Functions are used for heavy compute (AI, image optimization) and orchestration (external API calls) that should be on a server or worker. Edge should be reserved for lightweight, stateless operations like auth validation and simple DB reads. - **What is the single highest-impact improvement?** **Add a local session cache and validate the JWT on the device before calling any Edge Function.** This eliminates the most common cold start stacking scenario (app launch) and reduces perceived latency from seconds to milliseconds.

移动性能与Supabase边缘函数分析提示

提示词内容收藏

用法

参考资料

讨论