# Server-side data (load on demand)
When the rows live behind an API and there are too many to ship to the browser,
the server does the work: **sorting**, **filtering**, and **paging** become query
params, and it returns only the current page plus a total count. The headless
engine wraps that page and nothing else - it never sees the rest of the dataset.
Try it: search, click a header to sort, page through. Each change fires exactly
one request (watch the counter climb):
> Live demo: Headless server-side - https://svgrid.com/demos/191-headless-server-side/
## The shape of it
There is no local pipeline here - just `coreRowModel`. You own three things:
1. **The query state** (`pageIndex`, `pageSize`, `sort`, `desc`, `q`) - the
inputs your API takes.
2. **A fetch that re-runs when that state changes** - an `$effect` is enough.
3. **The engine, wrapping only the page you got back.**
```svelte
```
Render `rows` however you like, and drive the query state from your controls:
```svelte
{ q = e.currentTarget.value; pageIndex = 0 }} />
{#each rows as r (r.id)}
{@const row = r.original as Row}
{row.name}
{row.dept}
{row.salary}
{/each}
Page {pageIndex + 1} of {pageCount}
```
## Why only `coreRowModel`?
Because the pipeline already ran - on the server. Adding
`filteredRowModel` / `sortedRowModel` / `paginatedRowModel` would make the engine
try to filter, sort and slice the **page** you already fetched, which is wrong: it
only has 8 of the 483 rows. Feed the engine the finished page and let it do the
one job left - wrap each item as a `Row` so your markup and any cell logic work
the same as everywhere else.
## Three things worth getting right
- **Reset the page on a new sort or filter.** A different sort or query produces a
different result set, so `pageIndex = 0` - otherwise you can land on an
out-of-range page.
- **Guard against out-of-order responses.** Fast typing fires overlapping
requests; without the `reqSeq` check an early response can overwrite a later
one. Increment a sequence number per request and ignore any response that is
not the latest.
- **Debounce the search** if each keystroke hits a real network. A short
`setTimeout` on `q` keeps you from firing a request per character.
## More examples
### Server-side rendering
SvelteKit-style SSR with a sandboxed pre-hydration snapshot.
> Live demo: Server-side rendering - https://svgrid.com/demos/19-ssr/
## Sort, filter and page on the server
The three `external*` flags say "report, do not apply". The grid then renders
exactly the rows you hand it, and `rowCount` is what lets the pager show a total
it cannot count itself.
```svelte
r.id}
sortable
externalSort
onSortingChange={(next) => { sorting = next; pageIndex = 0 }}
pageable
externalPagination
rowCount={ALL.length}
{pageIndex}
{pageSize}
onPaginationChange={(p) => { pageIndex = p.pageIndex; pageSize = p.pageSize }}
/>
```
## See also
- [Row models](https://svgrid.com/docs/help/headless/row-models/) - the local pipeline, for when the client owns the data
- [Controlled state](https://svgrid.com/docs/help/headless/controlled-state/) - `state` in, `onXxxChange` out
- [Build a table from scratch](https://svgrid.com/docs/help/headless/build-a-table/) - the rendering half
- [Server-side data (with ``)](https://svgrid.com/docs/help/server-side-data/) - the same idea, wired for you
---
SvGrid is the Svelte 5 data grid (`npm install @svgrid/grid`, MIT). This page: https://svgrid.com/docs/help/headless/server-side/ . All docs: https://svgrid.com/llms.txt