Integrating Gemini AI Logic into Firebase Functions – Best Practices

Putting a Gemini API key in a mobile or web client is not a minor security nit — it means anyone who decompiles the app or inspects network traffic has your API key and can run up your bill on someone else's account. A Cloud Function exists here for exactly one reason: it's a place to hold the secret and add authorization before the model ever sees a request, not just a convenient place to put backend code.

That reasoning also sets the shape of the function correctly: an onCall function that accepts a narrow, typed input ({ reviewText: string }), validates it, calls Gemini with a fixed prompt template, and returns a typed result. It is deliberately not a generic proxy that forwards arbitrary prompts from the client — a generic pass-through hands an attacker the same blank check a client-side key would, just routed through your infrastructure instead of directly to Google's.

Firebase Functions integrates with Google Cloud Secret Manager for exactly this case: the API key is stored outside your source tree, referenced by name in the function's configuration, and injected as an environment variable at runtime — never committed, never visible in the Firebase console's function source view. Loading it any other way (a hardcoded string, an .env file bundled into the deployed function source) reintroduces the same leak risk a client-side key has, just one hop removed.

App Check adds the other half: it verifies that a request actually comes from your registered app (via device attestation — Play Integrity, App Attest, or reCAPTCHA for web) rather than an arbitrary script that discovered your function's URL. Without it, an onCall function checks Firebase Auth for who the caller claims to be, but nothing verifies what is making the call — a script with a stolen or freely-created anonymous auth token can call it exactly like your real app can.

Cloud Functions has its own startup cost — a cold instance can add a second or two before your handler code even runs, on top of whatever the Gemini call itself takes. The default function timeout (60 seconds, configurable) sounds generous until you account for both costs stacking: a cold start plus a slow model response plus any retry logic can exceed it, and the client sees a generic DEADLINE_EXCEEDED with no useful signal about which part was slow.

Design the function's own internal timeout shorter than the platform timeout, and make it explicit — call Gemini with a bounded timeout (using an AbortSignal or the SDK's own request timeout option) well under the function's configured timeoutSeconds, so your code controls the failure and can return a clear, actionable error instead of the platform cutting the connection with no context.

Firebase Functions is the right home for this pattern when the workload is request/response, bursty, and low enough in per-call latency budget to tolerate occasional cold starts — most single-model-call features (summarize, classify, extract) fit. Reach for a longer-running compute layer like Cloud Run background workers when the task is a multi-step agent loop, needs to hold state across a long-running job, or regularly exceeds a function's maximum timeout — retrofitting a long agent loop into a request/response function usually means fighting the platform's timeout instead of using it.

Measure before choosing: track p50/p95 latency for the Gemini call alone in a staging environment, add your realistic cold-start distribution, and compare the sum against your function's configured timeout with margin to spare. A design that only just clears the timeout on average will fail intermittently under any provider latency spike — plan for the tail, not the median.