Как встроить Gemini Image API в приложение: Firebase AI Logic или backend

Если приложению действительно нужно вызывать Gemini image generation прямо из мобильного или веб-клиента, сначала выбирайте Firebase AI Logic. Если у вас есть доверенный backend и вам нужны более точные image controls, держите вызов Gemini API на сервере. Это самый надежный текущий ответ, потому что Firebase AI Logic является официальным direct-from-app маршрутом, а нижележащий Gemini image API по-прежнему дает больше явных настроек, чем сегодня открыто в Firebase.

Главная ошибка в этой теме связана не с синтаксисом. Она связана с неправильной границей доверия. Мобильное приложение и публичный frontend не должны содержать raw Gemini API key. В текущем getting started по Firebase AI Logic, перепроверенном 23 марта 2026 года, прямо сказано не добавлять Gemini API key в код приложения и как можно раньше включать App Check. Уже одного этого достаточно, чтобы большинство реальных client-side интеграций начинались с Firebase AI Logic, а не с вставки provider key в frontend.

Есть и второй факт, который важно вынести в начало. В гайде Firebase по image generation, также перепроверенном 23 марта 2026 года, Gemini image generation внутри Firebase AI Logic помечен как Preview, для image-моделей требуется Blaze, а явные aspect_ratio и image_size там пока не поддерживаются. Если вашему продукту нужны точные размеры, более строгая серверная валидация, аудит или более широкий Gemini API surface area, лучше сразу строить серверный маршрут.

Краткое содержание

• Выбирайте Firebase AI Logic, если мобильное или веб-приложение должно обращаться к Gemini image generation напрямую.
• Выбирайте доверенный backend route, если сервер у вас под контролем и вам нужны aspectRatio, imageSize, аудит, storage или более строгая quota policy.
• Не размещайте raw Gemini API key в мобильном приложении или frontend code.
• Для большинства новых интеграций стартуйте с gemini-3.1-flash-image-preview.
• К gemini-3-pro-image-preview переходите только тогда, когда text-heavy или premium assets действительно оправдывают цену.
• Для Firebase AI Logic image generation сегодня нужно учитывать Preview, Blaze и лимиты до выхода на реальный трафик.

Если вопрос шире, чем интеграция в приложение, начните с Gemini Image Generation Tutorial: App, AI Studio, and API. Если нужны в первую очередь копируемые backend examples, лучше сразу открыть Gemini Image Generation Code Examples. Если следующая проблема связана с бюджетом, а не с архитектурой, нужен Gemini image generation API pricing.

Как выбрать правильный маршрут интеграции Gemini Image API до того, как писать код

SERP по этому запросу шумный, потому что в нем смешаны три разных вопроса. Firebase documentation отвечает на вопрос "как вызвать Gemini из приложения". Gemini image docs отвечают на вопрос "что умеет нижележащий image API". Android docs отвечают на вопрос "как это выглядит в мобильном стеке". Если читать эти страницы по одной и без общего routing rule, легко решить, что они спорят друг с другом, хотя на самом деле они просто описывают разные слои.

Практическое правило простое: если именно клиент должен вызывать Gemini, используйте Firebase AI Logic; если запрос может безопасно принадлежать backend, переносите image generation на сервер. Это решение важнее, чем выбор фреймворка. Оно важнее, чем Next.js против Flutter или Android против Web.

Firebase AI Logic выигрывает там, где важен shortest secure path для пользовательской функции внутри приложения. Он создан именно для mobile and web apps, вписывает App Check в общую историю безопасности и хорошо ложится на сценарии вроде "сгенерировать картинку прямо в чате" или "отредактировать загруженное фото внутри интерфейса". Это route-first ответ для прямого interaction loop.

Backend route выигрывает там, где приложению не нужен прямой model access from the client. Если у вас уже есть API boundary, background worker или server-owned job system, нижележащий Gemini API дает более естественное место для quotas, prompt validation, storage, logging, moderation, billing controls и image settings, которых пока нет в Firebase AI Logic. Именно здесь большинство демонстрационных интеграций сталкивается с production reality.

Нормальный путь эволюции тоже существует. Некоторые команды начинают с Firebase AI Logic ради скорости итерации в client-side UX, а затем переносят image generation за backend, когда feature доказывает ценность и ограничения начинают мешать. Ошибка не в самом переходе. Ошибка в том, чтобы с первого дня считать оба маршрута взаимозаменяемыми.

Firebase AI Logic это дефолтный маршрут для прямых вызовов из мобильного и веб-клиента

Firebase overview page сегодня довольно прямо говорит: если вам нужно вызывать Gemini API непосредственно из мобильного или веб-приложения, а не server-side, используйте Firebase AI Logic client SDKs. Поэтому для вопроса "как встроить Gemini image API в app" это и должен быть дефолтный ответ для truly direct-client сценариев.

Здесь выигрывает не только удобство. Выигрывает security boundary. Тот же setup flow может создать Gemini API key в проекте Firebase, но тут же говорит не помещать этот key в код приложения. Он также рекомендует включить App Check как можно раньше, как только проект выходит за пределы локального прототипа. Это гораздо лучше, чем tutorial, который предлагает вставить long-lived provider key в frontend JavaScript и надеяться, что им никто не злоупотребит.

Ниже типовая web-shape интеграции через Firebase AI Logic. Структура следует официальному примеру, но для нового проекта вместо старого gemini-2.5-flash-image лучше использовать gemini-3.1-flash-image-preview как текущий default lane.

javascript
import { initializeApp } from "firebase/app";
import {
  getAI,
  getGenerativeModel,
  GoogleAIBackend,
  ResponseModality,
} from "firebase/ai";

const firebaseConfig = {
  // ...
};

const firebaseApp = initializeApp(firebaseConfig);
const ai = getAI(firebaseApp, { backend: new GoogleAIBackend() });

const model = getGenerativeModel(ai, {
  model: "gemini-3.1-flash-image-preview",
  generationConfig: {
    responseModalities: [ResponseModality.TEXT, ResponseModality.IMAGE],
  },
});

const prompt =
  "Create a clean onboarding illustration for a budgeting app. Use a calm blue palette and leave room for headline text.";

const result = await model.generateContent(prompt);
const imagePart = result.response.inlineDataParts()?.[0];

if (imagePart) {
  console.log(imagePart.inlineData.mimeType, imagePart.inlineData.data);
}

Здесь важно помнить две детали. Во-первых, Firebase AI Logic image generation сейчас возвращает текст и изображение вместе, поэтому клиент должен уметь обработать обе части ответа. Во-вторых, поскольку Firebase AI Logic пока не дает явных aspect_ratio и image_size, сам prompt по-прежнему должен нести композиционные подсказки вроде "оставь место под headline" или "сделай это как высокий poster". Это рабоче, но именно поэтому Firebase AI Logic лучше воспринимать как simpler route, а не как most controllable route.

Нужно честно проговорить и billing. Более общие тексты про Gemini Developer API внутри Firebase могут создавать ощущение, что ecosystem friendly to free-tier experimentation, но для данного use case правильнее смотреть узкий и более свежий image-generation guide: image-generating Gemini models внутри Firebase AI Logic сегодня требуют Blaze. Поэтому безопасная формулировка не "это бесплатно" и не "это всегда дорого". Безопасная формулировка такая: широкий onboarding можно начать дешево, но Gemini image generation в Firebase AI Logic сегодня является paid route.

Когда нужен доверенный backend, а не только клиентский SDK

Если у вашего приложения уже есть backend, нижележащий Gemini API часто оказывается лучшей long-term формой интеграции. Причина не в моде и не в "настоящем enterprise". Причина в контроле.

В официальной документации Gemini image generation доступны явные imageConfig controls, включая aspectRatio и imageSize. В то же время Firebase image-generation guide прямо пишет, что Firebase AI Logic эти настройки пока не выводит. Для многих продуктов одного этого достаточно, чтобы решение по архитектуре изменилось. Если вам нужны стабильные hero images в 16:9, product cards в 1:1, story assets в 9:16 или разные output sizes для cheap vs premium generation, серверный маршрут дает гораздо более чистый контракт.

Еще важнее то, что backend route позволяет превратить image generation в часть бизнес-процесса, а не в один prompt box. На сервере проще сделать abuse filtering, user-level billing, moderation hooks, storage в Cloud Storage или S3, audit logs, internal admin tools и prompt templates, которые не должны утекать на клиент. Все это критично, как только feature становится частью продукта, а не просто demo.

Ниже базовая server-side shape на JavaScript, которую удобно держать в собственном API route или worker:

javascript
import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

export async function createMarketingImage(prompt) {
  const response = await ai.models.generateContent({
    model: "gemini-3.1-flash-image-preview",
    contents: prompt,
    config: {
      responseModalities: ["IMAGE"],
      imageConfig: {
        aspectRatio: "16:9",
        imageSize: "2K",
      },
    },
  });

  const imagePart = response.candidates?.[0]?.content?.parts?.find(
    (part) => part.inlineData
  );

  if (!imagePart?.inlineData) {
    throw new Error("No image returned from Gemini");
  }

  return {
    mimeType: imagePart.inlineData.mimeType,
    data: imagePart.inlineData.data,
  };
}

Этот маршрут лучше масштабируется для production asset generation, admin-only creative tooling и любых функций, где нужны фиксированные размеры, storage, observability и server-owned throttling. Если вам нравится Firebase как surrounding stack, но orchestration вы хотите держать на сервере, сами Firebase docs направляют к Genkit как к server-side route. Это удобная mental model: Firebase AI Logic для direct client integrations, Genkit или собственный backend endpoint для более сложного server-owned AI behavior.

Веб-приложение: где проходит граница для Next.js и Firebase App Hosting

Для веб-приложения вопрос почти всегда связан не с брендом фреймворка, а с trust boundary.

Если пользователю нужно прямо внутри интерфейса мгновенно запускать image generation или image editing, Firebase AI Logic остается shortest secure path. Frontend идет через Firebase gateway, можно добавить App Check, а raw Gemini API key не попадает в публичный JavaScript. Это хороший вариант для creator tools, in-app chat plus image features и легких editing flows.

Если же функция больше похожа на business processing, чем на живой user interaction, правильнее иметь собственный server route. Next.js route handler, Cloud Function или App Hosting backend удобнее там, где результат нужно сохранять, нормализовать, пост-обрабатывать, проверять на policy violations или тарифицировать. Там же естественнее централизовать model choice, output size, storage path и audit trail.

Итоговая развилка выглядит так:

• Frontend Firebase AI Logic route: пользователь запрашивает результат, клиент получает ответ напрямую, а feature выигрывает от прямого conversational loop.
• Backend Gemini API route: клиент просит job у вашего сервера, а сервер выбирает модель, image size, aspect ratio, storage и quota behavior.

Большинству product teams стоит принять это решение до того, как они начинают строить reusable UI around the feature. Иначе client-side UX потом приходится спешно проталкивать за серверную границу.

Android: Firebase AI Logic плюс App Check

Android кажется самым естественным местом для Firebase AI Logic, потому что Google сам подает тему именно так. Страница Android Developers для Gemini Developer API направляет разработчиков к Firebase AI Logic, поэтому такие документы так хорошо ранжируются в SERP.

Kotlin shape довольно прямой. Как и в web-примере, важен не только сам SDK call, но и то, что код работает внутри Firebase AI Logic проекта с включенным App Check и реальным quota plan:

kotlin
val model = Firebase.ai(backend = GenerativeBackend.googleAI()).generativeModel(
    modelName = "gemini-3.1-flash-image-preview",
    generationConfig = generationConfig {
        responseModalities = listOf(ResponseModality.TEXT, ResponseModality.IMAGE)
    }
)

val prompt = "Create a 1:1 travel sticker of Seoul at night in a bright flat illustration style."
val response = model.generateContent(prompt)

val image = response.candidates
    .first()
    .content
    .parts
    .filterIsInstance<ImagePart>()
    .firstOrNull()
    ?.image

Это хороший first Android path, когда image feature действительно интерактивен и принадлежит пользовательской сессии. Но даже здесь нужно мыслить как operator. В документации Firebase AI Logic по quotas указано, что default limit для Firebase AI Logic API составляет 100 RPM per user, а provider limits по-прежнему применяются раньше. Значит, Android app с bursty image features не должен вечно жить на defaults. Уменьшайте per-user cap до уровня, который бизнес реально может оплатить, и относитесь к App Check как к части release checklist, а не как к post-launch hardening.

Если Android-приложение занимается не пользовательским prompt box, а back-office workflow, team asset generation или дорогостоящими infographic outputs, серверный маршрут обычно все равно чище. Платформенные документы создают ощущение, что direct SDK path подходит всем, но в действительности он лучше всего там, где direct client interaction и есть продукт.

Как выбирать модели и когда менять маршрут

Для большинства новых интеграций начинайте с gemini-3.1-flash-image-preview. Страница цен и страница deprecations, перепроверенные 23 марта 2026 года, поддерживают эту рекомендацию. Flash Image сейчас остается default fast lane, а gemini-2.5-flash-image уже является legacy route с указанной датой отключения 2 октября 2026 года.

Переходить на gemini-3-pro-image-preview имеет смысл только тогда, когда продуктовый результат действительно этого требует. Обычно это text-heavy graphics, infographic-like output или premium assets, где плохой first pass дорого переделывать. Если задача состоит в том, чтобы быстро генерировать social images внутри приложения, Flash Image разумнее как default. Если задача состоит в том, чтобы делать polished visuals с большим количеством текста на изображении, Pro становится более оправданным.

Выбор маршрута может поменяться и из-за editing workflows. Firebase AI Logic силен там, где достаточно его app-side contract. Но если workflow растет в сторону reference-heavy edits, file pipelines или стабильных output guarantees, server route становится привлекательнее. В FAQ и troubleshooting по Firebase AI Logic также указано, что Files API Gemini Developer API не поддерживается через Firebase AI Logic SDKs. Это еще один сигнал, что более сложные asset workflows логичнее держать на backend.

Перед запуском: безопасность, квоты и стоимость

Именно этот слой до сих пор чаще всего недооценивают ranking pages.

App Check это часть архитектуры, а не nice-to-have. В текущем setup guide Firebase сказано, что на самой первой минуте эксперимента App Check не обязателен, но как только приложение собираются показать миру, его нужно добавить как можно раньше. Если вы рекомендуете direct client-side route, App Check должен быть в основном build checklist.

Firebase AI Logic добавляет один слой квот, а Gemini еще один. В документации по Firebase AI Logic quotas сказано про default 100 RPM per user, но provider quotas применяются раньше. В документации Google по rate limits указано, что лимиты Gemini считаются на уровне project, а preview models ограничены строже. Практический вывод в том, что одно и то же приложение может ловить 429 по двум разным причинам: на уровне Firebase gateway и на уровне underlying Gemini provider.

Pricing должно превращаться в model policy, а не жить сноской внизу. По состоянию на 23 марта 2026 года pricing page указывает для gemini-3.1-flash-image-preview примерно $0.045 за 0.5K image, $0.067 за 1K, $0.101 за 2K и $0.151 за 4K. Для gemini-3-pro-image-preview страница показывает примерно $0.134 за 1K или 2K image и $0.24 за 4K. Эти числа должны менять ваши defaults. Большинству приложений не стоит незаметно отправлять любой пользовательский запрос в premium lane и на крупный size.

Preview status должен менять rollout plan. Image generation в Firebase AI Logic по-прежнему находится в Preview, а preview models имеют более строгие rate limits. Это не аргумент против feature. Это аргумент за feature flags, per-user caps, понятные fallback messages и осторожные default sizes.

Практический production checklist как минимум включает:

• включенный App Check
• lowered per-user RPM до уровня, который продукт реально выдерживает
• одну default model policy и одну optional premium upgrade path
• logging для model choice, success rate и quota failures
• решение, будут ли изображения жить только на клиенте или также сохраняться на сервере

Если этим пренебречь, первый painful bug report почти наверняка будет про economics или abuse, а не про качество изображения.

FAQ

Можно ли вызывать Gemini image generation прямо из frontend code без Firebase?

Не стоит размещать raw Gemini API key во frontend или mobile code. Если feature действительно требует direct client calls, используйте Firebase AI Logic, чтобы provider key не оказался в приложении. Если direct client calls не нужны, держите Gemini image generation за собственным backend.

Поддерживает ли Firebase AI Logic явные imageSize и aspectRatio?

Не для Gemini image generation по состоянию на 23 марта 2026 года. В текущем image-generation guide Firebase сказано, что эти настройки там пока не поддерживаются, поэтому backend Gemini API route лучше подходит там, где критичен exact output control.

Нужен ли платный план для Gemini image generation в Firebase AI Logic?

Да. Текущий guide Firebase по Gemini image generation говорит, что image-generating Gemini models требуют Blaze независимо от Gemini API provider. Именно это и является правильным current answer для данного use case.

Ошибки, из-за которых потом приходится переделывать интеграцию

Первая ошибка это встраивание raw Gemini API key в client. Текущие документы Firebase прямо говорят этого не делать. Если tutorial по-прежнему советует обратное, он уже ниже текущего quality bar для этой темы.

Вторая ошибка это предположение, что Firebase AI Logic и нижележащий Gemini API дают одинаковые image controls. Это не так. Firebase image guide говорит, что aspect_ratio и image_size там пока недоступны, а Gemini image docs показывают эти controls на нижнем уровне. Если exact output size важен, decision о backend route нужно принимать рано.

Третья ошибка это чтение общих onboarding текстов про Gemini Developer API как доказательства того, что Firebase image generation бесплатен. Это слишком широкий источник. Узкий и более свежий image-generation guide прямо говорит про Blaze.

Четвертая ошибка это копирование старого примера с gemini-2.5-flash-image так, как будто это лучший current default. В некоторых code samples Firebase он еще встречается, но supported-model list и deprecations page уже достаточно ясно подсказывают, что для новых интеграций лучше стартовать с gemini-3.1-flash-image-preview.

Пятая ошибка это откладывать quota planning на потом. И quotas page Firebase, и Gemini rate-limit docs показывают, что image features легко падают из-за project-level и per-user limits задолго до того, как сам код станет "неправильным". Поэтому квоты нужно проектировать в build phase, а не прятать в appendix.

Если вам теперь важнее implementation detail, а не architecture choice, откройте Gemini Image Generation Code Examples. Если вопрос уже сместился к image editing, полезнее будет Gemini image-to-image editing. Если вы дебажите quota failures, смотрите Gemini image generation API pricing и rate-limit docs, а не очередной общий tutorial.

Итог

Лучший текущий ответ на вопрос "как встроить Gemini Image API в приложение" это не имя одного SDK, а одно архитектурное решение.

Используйте Firebase AI Logic, когда приложению действительно нужны прямые вызовы Gemini image generation из мобильного или веб-клиента. Используйте доверенный backend route, когда сервер у вас под контролем и нужны точные image controls, observability и cost governance. Оставляйте gemini-3.1-flash-image-preview дефолтом для большинства новых задач, переходите к gemini-3-pro-image-preview только тогда, когда premium output этого стоит, и воспринимайте gemini-2.5-flash-image как legacy branch, которой он теперь и является.

Именно такой route-first подход позволяет не переделывать интеграцию позже. Как только граница доверия выбрана правильно, все остальное, от SDK call до quota policy, становится заметно проще.