Download all docs

Recipe: API-to-SPA Dashboard

This recipe ingests data from an external API and serves it as a custom single-page app. An http endpoint (buffered through a queue) lands the data in sql, and a spa hosts the dashboard your users actually see — your own React/Vue/Svelte front end, built and served by the platform.

The problem it solves

You have data arriving over HTTP and you want a real, branded front end on top of it — not a generic admin table, but the dashboard your team designed. The usual answer is a separate hosting stack, a separate deploy, and glue code to connect the two. This recipe keeps ingest, storage, and the custom UI as elements in one circle, so the front end and its data live together.

Elements

ElementRole
httpReceives inbound API requests / payloads.
queueBuffers bursts so ingest never overwhelms the database.
sqlStores the structured data the dashboard reads.
spaHosts your custom single-page app (React, Vue, Svelte, Solid, Astro, or vanilla).

Flow

  1. Create an http element to receive inbound requests — it connects flows to HTTP endpoints for receiving and sending.
  2. Put a queue between ingest and storage. publish each incoming payload to the queue so spikes are absorbed; check depth any time with queue_stats.
  3. Create a sql element. As messages drain from the queue, insert them; shape the tables with migrate and read them back with query (bind parameters supported).
  4. Create a spa for the front end. build it (BuildForce auto-detects the framework — react/vue/svelte/angular/solid/astro/vanilla), then serve the assets; use build_status to watch the build and preview before you publish.
  5. Have the SPA read its data from the sql element’s query operation, so the dashboard always reflects what ingest landed.

What this shows

The spa element means “custom front end” is a first-class building block, not an afterthought bolted onto an API — you bring your own framework and the platform builds and serves it. The ingest path stays honest about load: the queue gives you backpressure between a bursty HTTP source and a database that prefers steady writes, and sql is the durable middle the UI reads from. Three layers — receive, store, present — each a real element you can deploy and inspect on its own.

Next pages