Czy do API transkrypcji używać webhooków czy pollingu?

Zadania transkrypcji są zwykle asynchroniczne: przesyłasz plik, API zwraca `transcription.id`, a wynik pojawia się później. Skąd wiesz, że jest gotowy?

Polling Twój kod okresowo pyta API: „Czy zadanie X jest gotowe?\" Typowo: GET `/v1/transcriptions/{id}/status` co 2-5 sekund. Gdy status zmienia się na `completed`, pobierasz wynik.

Zalety: proste, nie potrzeba publicznego URL, działa za zaporami i w zadaniach w tle. Wady: wiele pustych żądań (plik 1-godzinny przetwarzany w 2 min to 60-100 odpytań), ryzyko limitu zapytań, maks. opóźnienie = interwał pollingu.

Webhooki Rejestrujesz URL; API wywołuje go po zakończeniu zadania. POST z ciałem typu `{ "event": "transcription.completed", "id": "…", "result": { … } }`. Podpisany HMAC-SHA256, byś mógł zweryfikować, że to naprawdę dostawca.

Zalety: brak pustych żądań, opóźnienie poniżej sekundy, skaluje się do milionów zadań. Wady: wymaga publicznego URL (lub tunelu jak ngrok w dev), musisz samodzielnie zaimplementować ponawianie, idempotencję i weryfikację podpisu. Jeśli dostarczenie webhooka się nie powiedzie (serwer offline, awaria sieci), zdarzenie może zostać utracone.

Właściwa odpowiedź: oba Systemy produkcyjne łączą oba. Webhooki do głównego dostarczania – szybkie, wydajne. Polling jako zabezpieczenie co 5-10 minut dla zadań oczekujących dłużej niż 30 min – wychwytuje przypadki, gdy webhook został utracony.

Konkretny wzorzec ``` // Przy wgrywaniu const job = await api.transcribe({ file, webhook_url: "https://…" }) await db.insert({ id: job.id, status: "queued" })

// Endpoint webhooka app.post("/webhook", (req) => { if (!verifySignature(req)) return 401 await db.update(req.body.id, { status: "completed", result: req.body.result }) })

// Zadanie zapasowe (cron, co 10 min) const stuck = await db.where("status", "queued").and("createdAt", "<", now-30min) for (const j of stuck) { const fresh = await api.getStatus(j.id) if (fresh.status === "completed") await db.update(j.id, fresh) } ```

Specyfika DeepScript Obsługujemy oba: rejestruj webhooki przez `POST /v1/webhooks` (zdarzenia: `transcription.completed`, `transcription.failed`, `balance.low`), odpytuj przez `GET /v1/transcriptions/{id}/status`. Do interfejsu w czasie rzeczywistym w przeglądarce udostępniamy też SSE (`GET /v1/transcriptions/{id}/events`) – server-sent events przesyłają aktualizacje statusu prosto do klienta bez otwierania kanału WebSocket.