Email bypass: enable all boolean Remote Config flags for @mobilitydata.org users #99
Email bypass: enable all boolean Remote Config flags for @mobilitydata.org users #99
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…ta.org users in production Agent-Logs-Url: https://github.com/MobilityData/mobilitydatabase-web/sessions/e6a580fe-9b54-4e2a-86ce-65951372163a Co-authored-by: Alessandro100 <18631060+Alessandro100@users.noreply.github.com>
|
|
There was a problem hiding this comment.
Pull request overview
This PR introduces an internal-user “feature flag bypass” so authenticated users can have all boolean Firebase Remote Config flags forced to true, and updates the Remote Config fetching/caching approach to use Next.js Data Cache primitives.
Changes:
- Switched server-side Remote Config caching from in-memory to
unstable_cache+revalidateTag, and added user-aware helpers (getRemoteConfigValuesForUser,getUserRemoteConfigValues,applyAdminBypass). - Updated Remote Config context/provider flow to apply bypass client-side after auth resolves; reordered top-level providers to support this.
- Added Jest coverage for the bypass logic and documented Remote Config behavior in the README.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
src/lib/remote-config.server.ts |
Introduces Next.js Data Cache-backed Remote Config fetch + user-aware bypass helpers. |
src/lib/remote-config.server.spec.ts |
Adds unit tests for bypass matching, bypass application, and refresh behavior. |
src/app/screens/Feed/components/DataQualitySummary.tsx |
Fetches Remote Config using request-user-aware helper for server rendering. |
src/app/providers.tsx |
Reorders providers so RemoteConfigProvider can consume auth session state. |
src/app/interface/RemoteConfig.ts |
Adds matchesFeatureFlagBypass() parsing/matching helper for bypass rules. |
src/app/context/RemoteConfigProvider.tsx |
Applies bypass on the client once auth is ready to handle static/ISR output. |
Applied guidance: vercel-react-best-practices (custom)
| function applyAdminBypass(config: RemoteConfigValues): RemoteConfigValues { | ||
| const overridden = { ...config }; | ||
| for (const key of Object.keys(overridden) as Array< | ||
| keyof RemoteConfigValues | ||
| >) { | ||
| if (typeof overridden[key] === 'boolean') { | ||
| (overridden as Record<string, unknown>)[key] = true; | ||
| } | ||
| } | ||
| return overridden; | ||
| } |
There was a problem hiding this comment.
applyAdminBypass is implemented both here and in src/lib/remote-config.server.ts. This duplication risks the server/client behavior drifting over time (e.g., if new flag types are introduced). Consider extracting a shared helper (in a non-server-only module) that both server and client can import.
README.md
Outdated
|
|
||
| Firebase remoet configs help us toggle new features on and off. Due to the nature of static pages, there are some nuances. For static pages, the remote configs are called and set at build time and will be the same for the remainder of the static page's cache. | ||
|
|
||
| When remote configs change (they rarily do), it is recommended to redploy the app as that will trigger a new cache for all pages, that will include the updated remote configs |
There was a problem hiding this comment.
Typo: “rarily” should be “rarely”.
| When remote configs change (they rarily do), it is recommended to redploy the app as that will trigger a new cache for all pages, that will include the updated remote configs | |
| When remote configs change (they rarely do), it is recommended to redploy the app as that will trigger a new cache for all pages, that will include the updated remote configs |
README.md
Outdated
| Firebase remoet configs help us toggle new features on and off. Due to the nature of static pages, there are some nuances. For static pages, the remote configs are called and set at build time and will be the same for the remainder of the static page's cache. | ||
|
|
||
| When remote configs change (they rarily do), it is recommended to redploy the app as that will trigger a new cache for all pages, that will include the updated remote configs | ||
|
|
||
| What this also means is that client components will be able to access the firebase remote configs using the Context but server components will have to fetch them each time. This isn't a big deal as the firebase remote configs are cached (for 1 hour on the server) |
There was a problem hiding this comment.
The new README section states remote config is “called and set at build time” for static pages, but this PR also introduces server-side caching/revalidation (unstable_cache + revalidateTag) which updates values without a redeploy for dynamic/ISR renders. Consider clarifying that the “build time” limitation only applies to fully static routes, while server-rendered routes will revalidate per the cache settings.
| Firebase remoet configs help us toggle new features on and off. Due to the nature of static pages, there are some nuances. For static pages, the remote configs are called and set at build time and will be the same for the remainder of the static page's cache. | |
| When remote configs change (they rarily do), it is recommended to redploy the app as that will trigger a new cache for all pages, that will include the updated remote configs | |
| What this also means is that client components will be able to access the firebase remote configs using the Context but server components will have to fetch them each time. This isn't a big deal as the firebase remote configs are cached (for 1 hour on the server) | |
| Firebase remote configs help us toggle new features on and off. Due to the nature of static pages, there are some nuances. For fully static pages, the remote configs are fetched and set at build time and will remain the same for the lifetime of that static page cache. | |
| When remote configs change (they rarely do), redeploying the app is recommended for fully static pages because it triggers a new build/cache that includes the updated remote config values. However, this build-time limitation does not apply to server-rendered or revalidated routes: those routes use the server-side cached remote config values and will pick up updates based on the configured cache revalidation behavior, without requiring a full redeploy. | |
| In practice, client components can access the Firebase remote configs through Context, while server components read them on the server. Those server-side values are cached (for example, for up to 1 hour on the server), so they are not refetched on every request unless the cache is revalidated. |
|
*Lighthouse ran on https://mobilitydatabase-f0tospehw-mobility-data.vercel.app/ * (Desktop)
*Lighthouse ran on https://mobilitydatabase-f0tospehw-mobility-data.vercel.app/feeds * (Desktop)
*Lighthouse ran on https://mobilitydatabase-f0tospehw-mobility-data.vercel.app/feeds/gtfs/mdb-2126 * (Desktop)
*Lighthouse ran on https://mobilitydatabase-f0tospehw-mobility-data.vercel.app/feeds/gtfs_rt/mdb-2585 * (Desktop)
*Lighthouse ran on https://mobilitydatabase-f0tospehw-mobility-data.vercel.app/feeds/gbfs/gbfs-flamingo_porirua * (Desktop)
|
Alessandro100
changed the title
Closes #69
Summery
This PR handles an admin bypass for the firebase feature flags. The logic of this bypass are set in the remote config
featureFlagBypasswhich is currently just users with mobilitydata.org email addresses.This PR sets stronger standards on how server, client and static components consume firebase remote configs.
Client components: Get the firebase configs from the server
Server components: If not passed down, must fetch. (added improved server caching of the firebase remote configs 1h)
Static pages: Are set at build time. If firebase remote configs are changed, it's advisable to redeploy the app
Extra details (human)
To note
For static pages, the remote configs are called and set at build time and will be the same for the remainder of the static page's cache. (ex: About Us / Feed Detail (non auth))
When remote configs change (they rarily do), it is recommended to redploy the app as that will trigger a new cache for all pages (specifically the static pages), that will include the updated remote configs
What this also means is that client components will be able to access the firebase remote configs using the Context but server components will have to fetch them each time. This isn't a big deal as the firebase remote configs are cached (for 1 hour on the server)
Testing tips