developer guide
Backend Recipes for a Data Grid
A grid connects to whatever already holds your data. These five guides each take one wire shape, show the full source of a small reference server where one exists, and say exactly what pushes to your backend against what the grid finishes on its own. The reference servers live in one public repository, MIT-licensed, with no keys and nothing that phones home: lattice-grid-backend-recipes.
REST API paging for a data grid
One JSON request in, { rows, total } back. Zero-setup Node and SQLite.
Filters, sort and the total push to SQL; nothing past the page reaches the network.
SQL through your own endpoint
A filter and a sort become one parameterised statement behind your own API.
Pushes the filter tree, a sort and an exact count; grouping still finishes in the browser.
GraphQL cursor paging for a data grid
graphqlAdapter walks a Relay-style connection forward by cursor, not by offset.
Only the window and the total push by default; a filter or sort finishes client-side.
Stream a feed into the Data Router
One feed, many live grids: a partition value decides which view each record reaches.
The whole feed splits and updates in the browser; only a busy route's own backlog can lag.
A job-style search API for a data grid
Submit a job, poll it, read a window once it is done, Splunk's own search REST shape.
A filter and sort push into the job; grouping is refused by name, never silently wrong.
For the full request and answer shape every adapter here implements, see the pushdown developer guide, or the adapter contract for the precise, field-by-field version: what you declare, what you receive, what you return, and how a refusal is named.
How-to guides For a task-shaped, one-page example of a single grid feature rather than a backend, see the 21 how-to guides.