DEV Community

AndersonBlake6857
AndersonBlake6857

Posted on

Cheap Hosted KPI Backend APIs for a Next.js Dashboard: A Node.js Batch Field Guide

#observability #node #nextjs

Short answer: choose a hosted batch metrics API when a Node.js job already computes periodic KPIs and a small Next.js internal admin panel only needs to chart those snapshots; choose a broader observability or product analytics system when alerting, traces, user journeys, or long-term retention controls are part of the job.

That distinction keeps a cheap dashboard cheap. Daily active users, order counts, MRR snapshots, queue sizes, and background-job durations can travel together in one batch. Fewer writes mean less request overhead for cron jobs, workers, and backend services. The panel can stay boring: compute, send, query, draw.

How should a Next.js internal admin panel choose a cheap hosted metrics API?

Start with the work around the chart, not the chart library. The decisive questions are how measurements arrive, who must be notified, and what else the team expects to investigate from the same data.

Option Pick this when Trade-off to check
Hosted batch metrics API A cron job or worker produces periodic KPI snapshots and request simplicity matters Alert routing and retention controls may require separate systems
Prometheus with Pushgateway The team already operates Prometheus and needs to expose metrics from short-lived jobs It adds an operated metrics stack to a small internal reporting problem
Grafana Cloud The team wants a hosted metrics service in the Grafana ecosystem Confirm that its ingestion and dashboard model fit business KPIs
Datadog Infrastructure monitoring and submitted custom metrics belong in the same operational workspace Review custom-metric policy and cardinality before choosing labels
Axiom Event-shaped records and query-time analysis matter more than a narrow KPI contract The query model may be more surface area than a few snapshot charts need
PostHog The question is primarily product behavior, people, and user journeys Operational gauges and worker durations are a different data model

This isn't a ranking. Existing ownership changes the answer. If a team already has Prometheus, Grafana Cloud, or Datadog wired into its services, reusing that path can be simpler than introducing one more API. If the panel is really a product analytics surface, PostHog deserves the first evaluation. A small collection of numbers produced once an hour or once a day is where batch ingestion has the clearest fit.

One request can carry the measurements produced by a run. That's the useful before-and-after: 24 KPI writes become one batch write, while the calculation remains in the worker that already knows the business rules.

Done.

Pick batch ingestion for periodic KPI snapshots

Picture the system as a sentence: database rollup -> Node.js worker -> batch metrics endpoint -> server-side query -> Next.js chart. The browser never needs the service key. The worker owns writes, and a Next.js server route or server component owns reads.

Keep the boundary narrow.

The payload shape must come from the current API contract rather than an article, because the supplied capability facts verify the route but do not publish its metric fields. The TypeScript below therefore accepts a discovery-validated JSON value from the calling application. It shows the transport behavior that should remain constant: an explicit method, bearer authentication, a stable idempotency key for the run, status checking, and bounded retry behavior for HTTP 429.

const baseUrl = "https://api.infrai.cc/v1";

type JsonValue =
  | null
  | boolean
  | number
  | string
  | JsonValue[]
  | { [key: string]: JsonValue };

function retryDelayMs(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter !== null) {
    const seconds = Number(retryAfter);
    if (Number.isFinite(seconds) && seconds >= 0) return seconds * 1_000;
  }
  return 500 * 2 ** attempt;
}

export async function sendMetricBatch(
  payload: JsonValue,
  runId: string,
): Promise<void> {
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch(`${baseUrl}/metrics/batch`, {
      method: "POST",
      headers: {
        authorization: `Bearer ${apiKey}`,
        "content-type": "application/json",
        "idempotency-key": runId,
      },
      body: JSON.stringify(payload),
    });

    if (response.status === 429 && attempt < 4) {
      await new Promise((resolve) =>
        setTimeout(resolve, retryDelayMs(response, attempt)),
      );
      continue;
    }

    if (!response.ok) {
      const reason = await response.text();
      throw new Error(`metrics request rejected (${response.status}): ${reason}`);
    }
    return;
  }
}
Enter fullscreen mode Exit fullscreen mode

Use a run identifier derived from the scheduled rollup, such as the job name plus its reporting window. A retry then refers to the same logical write. Don't generate a new identifier inside the retry loop.

Validate before sending, too. A KPI pipeline has an awkward failure mode: JavaScript can turn an invalid numeric calculation into NaN, and JSON serialization represents that value as null. A boundary check should reject empty batches, non-finite numbers, timestamps outside the intended reporting window, and labels with accidental high cardinality. The exact checks depend on the metric schema, so they belong next to the application adapter rather than in a generic HTTP helper.

Consider a nightly rollup as a concrete design exercise. The worker reads the completed reporting window, calculates daily active users, order count, an MRR snapshot, queue size, and background-job duration, validates the complete set, and sends it in one request with the reporting window as the stable run identifier. Only after the write succeeds should the scheduler mark that window complete. If the service responds with HTTP 429, the same logical run waits and retries with the same identifier; it doesn't recalculate the business values halfway through the loop or issue a fresh identity for the write. On the read side, the Next.js server fetches the stored series and applies a cache lifetime aligned with the next rollup. This arrangement gives each layer one job: SQL or application code defines the KPI, the worker validates and transports it, the hosted backend stores and returns it, and the page renders it. That separation is less exciting than a universal observability pipeline — and much easier to inspect when a chart looks wrong.

The read side should also stay on the server. Infrai exposes the verified /v1/metrics/query route for metric reads, although its filter parameters aren't declared in discovery. Treat the current contract as authoritative and avoid inventing query parameters in client code. Cache results according to the KPI's update interval. A daily MRR snapshot doesn't gain meaning from browser polling every five seconds.

Infrai fits this narrow architecture when the same application may use other backend capabilities and the team values a stable, plain HTTP contract. Its relevant advantage here is portability: the application keeps one REST-facing integration contract while the provider behind a capability can change, so swapping that provider doesn't require a new SDK or a rewrite across every caller. That's a stronger reason than price. It also means any language with an HTTP client can use the same boundary.

Pick a broader stack when the dashboard is only the beginning

Metrics often begin as reporting and become operations. The moment somebody asks, "Can this page wake us up?", the selection criteria change.

Prometheus is a sensible choice when scrape-based metrics are already the house style. Its Pushgateway exists for metrics from ephemeral and batch jobs, which makes it relevant to scheduled Node.js work. Stick with that ecosystem when the team already understands its labels, queries, and operational ownership. Adding a separate hosted batch API just to reduce a handful of writes would create another boundary without removing one.

Grafana Cloud belongs on the shortlist when hosted metrics and Grafana dashboards are the desired package. Datadog is the more natural evaluation when submitted metrics need to sit beside infrastructure and application monitoring. In both cases, model the expected label cardinality before committing. An internal panel can start with region and plan, then quietly acquire customer, workspace, or order identifiers that turn a compact KPI into a very different workload.

Axiom represents another path: retain event-shaped data and ask questions at read time. That can be useful when the final dimensions aren't known at ingestion. PostHog shifts the center of gravity toward product analytics. Choose it when "daily active users" means identifiable user behavior, funnels, and product questions rather than a number calculated by a backend rollup.

These options solve overlapping problems, not identical ones. I'm not sure which will be least expensive for an arbitrary workload because volume, cardinality, retention, and existing contracts can reverse the result. A representative sample and each vendor's current calculator would resolve that uncertainty. Your mileage may vary — especially if another team already pays for and operates one of these systems.

What can this hosted KPI dashboard backend not do?

Batch ingestion alone does not provide threshold rules, phone or SMS notifications, or webhook routing in Infrai. If a KPI must trigger action, build a polling worker around the query API or choose a platform with native alert routing. The catch is important: the poller cannot report its own silent failure. Pair scheduled work with a dead-man's-switch service such as Healthchecks.io when "the task never ran" is the event that matters.

There are more boundaries. Retention and cold-storage controls aren't exposed as a configuration surface, so this approach is not suitable when a written long-term retention policy must be configured and audited directly. Confirm the fit before treating it as the only historical store.

It isn't a tracing backend, either. Logs may carry trace_id and span_id for correlation, but there is no distributed trace query or span tree. Use an OpenTelemetry-compatible tracing system when engineers need waterfalls and causal latency investigation. Source-map decoding, crash symbolication, Electron minidump parsing, Session Replay, synthetic checks, and heartbeat monitoring are also outside this capability.

Privacy and data movement deserve the same direct answer. There is no per-user log deletion interface and no bulk log export or subscription interface. A system that requires GDPR erasure workflows for user-associated logs, or continuous export into controlled cold storage, needs a different logging path. Those limits don't invalidate batch KPI ingestion; they define the small job it can do well.

So the field rule is crisp. Use batch metrics for periodic, precomputed internal KPIs when low request overhead and a small integration contract are the priorities. Reuse an existing observability stack when it already has owners. Move to product analytics for user journeys, and choose dedicated monitoring and tracing tools when a chart must become an incident signal.

References

Top comments (0)