СТАТТЯ

BulkImagen async batches і nano-banana-2-1: Bubble workflow до cutover NB2 (29.10) без блокування WU

Віталій Дорошенко Опубліковано

Як у Bubble відправити BulkImagen batch, полити статус у backend workflow і прив’язати resultUrls до рядків каталогу — з чеклістом міграції на NB2.1 і чесним застереженням про WU та дати deprecations.

Навіщо зараз

Я генерую зображення для каталогу пакетами. Синхронний виклик на кнопці швидко упирається в таймаути сторінки і поганий UX. BulkImagen дає async batch (POST /api/v1/batches, модель nano-banana-2-1) — відповідь одразу, кредити списуються при створенні, завершення — через polling GET /api/v1/batches/{id} (у доках ~кожні 5 с, поки batch.done не стане true). OpenAPI не описує webhook — лише poll.

Паралельно Google вивів у GA gemini-nano-banana-2.1 (6 жовтня 2026), позначив gemini-3.1-flash-image (Nano Banana 2) deprecated з рекомендованою заміною NB2.1; у primary deprecations/changelog на момент Scout-пакета немає оголошеної дати shutdown для NB2. План редакції з 29.10 як hard cutover може не збігатися з поточною таблицею Google — перед релізом я перевіряю Gemini deprecations, а не внутрішній digest. Про це окремо: 29.10.2026: вимкнення Nano Banana 2.

Imagen 4 (imagen-4.0-*-generate-001) у тій же таблиці — shutdown 17 серпня 2026 (відносно 12.10.2026 це вже минуле). Будь-які залишки Imagen 4 — окремий аварійний cutover, не лише BulkImagen slug.

Що означає «без блокування WU»

Чесно: мова не про «нуль workload units на backend».

  • Так: не тримати довгий ланцюг API на page workflow після кліку; користувач отримує «job створено» і йде далі.
  • Ні: recursive Schedule API Workflow для polling також споживає WU (і може бути дорожчим за «schedule on list», якщо полити часто).

Заголовок статті — про UX і архітектуру, не про безкоштовний backend.

Production-патерн у Bubble

1. Data model (мінімум)

  • Catalog row — те, що малюєте (prompt, статус pending / ready / failed, опційно image).
  • Batch job (окремий Thing) — batchId, provider = BulkImagen, status, submittedAt, зв’язок з рядками (list або batch foreign key).

Зберігайте стабільний ключ рядка (unique id) у себе; BulkImagen у схемі Scout не показує custom key на task — мапінг часто через порядок promptів, task.id або дроблення batch так, щоб один task = один row.

2. Старт з UI (короткий page workflow)

  1. Користувач обирає рядки / натискає «Generate batch».
  2. Оновити рядки → pending.
  3. Schedule API Workflow (backend) «на зараз» — не чекати BulkImagen у page workflow.
  4. Показати batch id або «обробляється».

Outbound виклики — API Connector; ключі BulkImagen тільки server-side (не на клієнті).

3. Backend: створити batch

  • POST /api/v1/batches з моделлю nano-banana-2-1 і масивом tasks/prompts з вашого каталогу.
  • Зберегти batchId на Batch job; status = submitted.
  • Одразу schedule наступний крок «Poll batch» через ~5 с (узгоджено з їхніми рекомендаціями).

Обробіть коди з OpenAPI: rate_limited, concurrent_limit_exceeded — backoff (збільшити інтервал poll, не hammer кожні 5 с при 429).

4. Backend: poll loop (recursive schedule)

  1. GET /api/v1/batches/{id}.
  2. Якщо batch.done ≠ true — recursive API workflow: schedule self з Current date/time + 5 s (або 10–30 s під навантаження).
  3. Якщо done — розібрати tasks: status, resultUrls (публічні, без auth).

Ліміт Bubble: на нових апках з липня 2024 за замовчуванням ~10 ітерацій recursive workflow — poll довгого batch обірветься, якщо не підняти cap у налаштуваннях. Заклади в runbook.

Альтернатива Google Batch API для gemini-nano-banana-2.1: ~50% cost vs standard, polling + опційні webhooks batch.succeeded / batch.failed на HTTPS — тоді inbound через Workflow API, не API Connector. Ця стаття фокусується на BulkImagen poll-only; direct Gemini — окремий гілка, якщо тримаєте ключі Google і хочете webhook замість recursive poll.

5. Мапінг результатів на каталог

Практичні правила:

  • Один prompt → один row у одному batch — найпростіше.
  • Повторювані promptи / countPerCombo — не покладайтеся лише на текст prompt; тримайте масив (rowId, prompt) у Batch job і зіставляйте за індексом submission, якщо API гарантує порядок (перевірте на staging).
  • Часткові фейли: task-level failed — row лишається failed, batch job — completed_with_errors.

6. Зберігання зображень

resultUrls BulkImagen — публічні third-party links. Для приватного каталогу:

  • завантажити файл у Bubble storage (backend step після poll);
  • не логувати URL у публічні поля без потреби.

Cutover checklist: NB2 → NB2.1 (і Imagen 4)

Крок Дія
1 Відкрити deprecations — чи з’явилась дата shutdown для gemini-3.1-flash-image; не будувати прод на «29.10» без primary підтвердження.
2 У BulkImagen переконатися, що batch використовує slug nano-banana-2-1 (vendor ≠ Google SLA; routing до gemini-nano-banana-2.1 opaque).
3 Інвентаризація: чи лишились Imagen 4 або NB2 в інших конекторах — мігрувати на NB2.1-маршрут.
4 Staging: один малий batch, перевірити порядок tasks ↔ rows.
5 Production: увімкнути Batch job + poll; моніторити WU і recursive cap.
6 Pricing/batch economics (~50% batch у Google pricing tier) — окремі матеріали; тут лише orchestration.

Ризики (коротко)

  • Timeline: digest vs Google docs — завжди primary table.
  • Vendor boundary: refunds, parity, uptime — BulkImagen credits, не Google batch SLA.
  • WU: polling коштує; рідший інтервал + backoff дешевше за агресивні 5 с.
  • Security: public resultUrls — копіювати в private storage за потреби.

Що я залишаю в проді

Bubble production pattern: короткий page workflow → backend POST batch → зберегти batchId → recursive scheduled poll до batch.done → map tasks на catalog rows → опційно mirror у Bubble files. Cutover на nano-banana-2-1 / gemini-nano-banana-2.1 — через deprecations checklist, а не фіксований календар без primary джерела. «Без блокування WU» = не блокувати користувача на сторінці; backend плануйте з лімітами recursive workflow і чесним budget WU. Поруч із цим: gpt-image-1 вимикається 23.10.2026: міграція bulk-каталогів.

Схожі статті

← Усі статті