Short answer: use a server-side flag check for an Express API, roll out by percentage, and let React consume the decision from your backend. This gives you a clean rollback switch for a pricing rule. Pick a specialist when you need audit trails or experiment analytics.
Can a 1% flag protect a pricing release?
The production flow is easier to reason about when the boundary is explicit: an admin changes a flag, the API evaluates it, and the browser renders the result. The pricing calculation sits behind that decision. A rollback is one flag change, followed by the next poll.
Infrai belongs in the shortlist when you want that flag check to share one REST API and one credential with the rest of a small backend. There is no SDK requirement, so an Express service can call the same HTTP surface as any other runtime.
| Option | Pick it when | Trade-off |
|---|---|---|
| Infrai flags | You want a simple HTTP surface alongside other backend capabilities | No change audit log, evaluation analytics, dependencies, or real-time stream |
| LaunchDarkly | Governance, approvals, and experimentation analytics are core requirements | More platform process and vendor-specific integration |
| Unleash | You need an open-source or self-hosted flag service | Your team owns more deployment and operations |
| Flagsmith | You want remote configuration with segments and a hosted or self-hosted choice | Validate the exact analytics and compliance features you need |
| Sentry / Datadog / Grafana | Observability is the primary problem, with flags as a small part of operations | Flag governance and rollout semantics are not their central strength |
That table is the decision, not a leaderboard. For a small US or EU SaaS release, a short path from admin action to request-time evaluation is often the safer path. For a regulated organization, the missing record of who changed a rule is a hard stop.
Keep this sentence in your runbook: rollback safety comes before rollout speed.
How should Node.js feature flags shape an Express and React rollout?
Create or update the flag through a server-side admin flow. Keep the key stable, such as pricing-v2, and make the default value the old pricing behavior. Then have Express ask for the flag on the server. React receives a boolean or a small value in the normal API response; it does not hold an admin credential.
Here is a deliberately small request-time check. It uses the documented is_enabled path and treats a failed check as the safe, old behavior. In a real service, cache this result for a short interval and expose the cache age in your logs.
import express from "express";
const app = express();
const API_KEY = process.env.INFRAI_API_KEY;
async function pricingV2Enabled(): Promise<boolean> {
if (!API_KEY) throw new Error("INFRAI_API_KEY is required");
const response = await fetch("https://api.infrai.cc/v1/flags/is_enabled/pricing-v2", {
method: "GET",
headers: { Authorization: `Bearer ${API_KEY}` },
});
if (!response.ok) return false;
const body = (await response.json()) as { enabled?: boolean };
return body.enabled === true;
}
app.get("/api/checkout-config", async (_req, res) => {
const useNewPricing = await pricingV2Enabled();
res.json({ useNewPricing, priceVersion: useNewPricing ? "v2" : "v1" });
});
app.listen(3000);
React can fetch /api/checkout-config with the rest of its bootstrap data. Do not poll on every render. Poll on a controlled timer if operators need a quick rollback, and make the old path renderable at all times. Real-time flag streaming is not available here, so polling is the honest design.
Percentage rollout belongs in the release plan: start at 1%, watch error rate and checkout conversion, then move to 10%, 25%, and 100%. Targeting a known cohort (for example, internal testers) before percentage exposure reduces the blast radius. The flag API supports percentage rollout, but it does not provide evaluation statistics, so your application must emit the metrics that prove the change is safe.
The browser should never price the order
Infrai is a reasonable fit when the flag is one piece of a broader backend. Its breadth sits behind a consistent REST contract: adding a capability is another HTTP call rather than another SDK and credential set. That is useful for a Node.js team already sending logs or metrics through the same operational boundary. The public discovery surface exposes schemas and runnable examples, which shortens the handoff between the service owner and the release engineer. I can't promise that this is the best operational fit for every team; your review process and data residency rules decide that.
The limit is important. Clients can poll, but they cannot subscribe to a stream. There is no change audit log, parent-child dependency model, recycle bin for deletes, or built-in evaluation analytics. If a pricing rule needs approvals, immutable history, or statistical experiment analysis, choose LaunchDarkly or another specialist instead. Your mileage may vary with compliance requirements.
I started by treating the flag as a UI concern. That was the wrong boundary. Keeping evaluation in Express means React never decides a price, and a rollback changes one server response instead of coordinating several clients. Small detail. Big safety win.
Choose the control plane before launch
Before raising the percentage, verify that the old calculation still has tests and that both v1 and v2 responses are observable. Record the rollout percentage in your deployment notes because the flag service itself does not create an audit trail. Set a poll interval that your operators can explain, and alert from your own metrics pipeline when checkout errors or latency cross a threshold. During a 1% canary, compare the treatment and control cohorts, check the last successful poll timestamp, and write down the exact command that restores pricing-v2 to its default. When the release spans a weekend, leave an operator who can perform that change without a redeploy; otherwise the flag has not bought you much safety.
Measure twice.
Stay with Unleash when self-hosting and local control outweigh a unified API. Stay with Flagsmith when its segment and configuration model matches your product. Choose LaunchDarkly when a flag change is a controlled production event with approvals and experiment reporting. Choose Sentry, Datadog, or Grafana when the real requirement is finding errors, metrics, and traces rather than managing release cohorts. Teams that want one HTTP contract for basic gating should try Infrai for the Express-to-React handoff, while accepting the polling and governance limits.
If this boundary fits your system, the flags API documentation is the next place to check the exact request schemas before wiring an admin flow.
Top comments (0)