firebase / firebase/firebase-admin-dart

Support for Remote Config

Open
#323 1 comment 1 reaction 1 assignee Claimed by @demolaf View on GitHub
enhancement
Dominant language
Dart
Stars
177
Forks
70
Avg merge
5d 14h
Merged PRs (30d)
6

Description

**Is your feature request related to a problem? Please describe.**

The support matrix lists Remote Config as 🔴. That's the one gap that currently forces us to keep part of our backend in TypeScript.

We run a production Dart Cloud Functions codebase (`firebase_functions` 0.6.0, `firebase_admin_sdk` 0.5.3, `google_cloud_firestore` 0.5.2) alongside a legacy Node codebase, and we've been migrating `onCall` endpoints to Dart as capabilities land. Our internal rule is "write it in Dart unless something forces JS".

Every new endpoint we ship carries an emergency kill switch driven by server-side Remote Config, so we can disable a feature from the console without a redeploy:

```js
const template = await getRemoteConfig().getServerTemplate({
defaultConfig: {[key]: false},
});
return template.evaluate().getBoolean(key);
```

There is no Dart equivalent — not in `firebase_admin_sdk` (no `remote_config` library), not in `firebase_functions` (`firebase.remoteConfig` is the `onConfigUpdated` trigger, not a template reader), and not in `package:googleapis` (`firebaseremoteconfig` isn't in the generated set — I checked `config.yaml` on `google/googleapis.dart`). So a whole endpoint that otherwise only needs Firestore admin + `package:http` + secrets has to stay in TypeScript purely for three lines of kill switch.

**Describe the solution you'd like**

A `remote_config` module in `firebase_admin_sdk`, at minimum the server-side read path (`getServerTemplate` / `evaluate`) — that's what backend feature flags need. Template management (`getTemplate` / `publishTemplate` / `validateTemplate` / `rollback` / `listVersions`) would be a bonus.

**Describe alternatives you've considered**

Calling the Remote Config REST API by hand from Dart, with an ADC token from the metadata server. It works, but re-implementing the server-template fetch *and* the condition/percent-rollout evaluation logic in every app is exactly what an Admin SDK is supposed to prevent — and getting percent-rollout bucketing subtly wrong is a silent, hard-to-notice bug.

**Additional context**

#249 already implements this, including server-side evaluation with a condition evaluator, ~1.8k lines of tests, docs and an example. It's been open since 2026-04-26 with no review.

The stated blocker there was that Firebase services route through the `googleapis` generated package. The contributor answered that in the thread: `firebaseremoteconfig` was dropped from `googleapis` between 13.2.0 and 14.0.0 and isn't in current versions, and four of the five admin endpoints need `ETag` / `If-Match` request and response headers, which the generated clients don't surface — so raw REST is required regardless of whether `firebaseremoteconfig` comes back. They offered three concrete paths and asked which one the project prefers; there's been no reply since 2026-04-29.

Filing this so there's a trackable issue for the capability itself (there is currently none — #249 is the only reference to Remote Config in the repo, and a PR isn't something users can find or subscribe to easily). Happy to test a branch against a real project if that helps.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.