feat: add server-side data access

[olliethedev]

Changes in this PR:

• open up plugin level data access without going through api router. useful for ssr/ssg

Closes #32 #52

---

Note

Medium Risk
Touches core stack() typing/return shape and adds a new server-side data access path that bypasses authorization hooks, plus changes list endpoint response shapes for blog/kanban which could break consumers if missed.

Overview
Adds a typed server-side stack().api surface by extending BackendPlugin with an optional api(adapter) factory and returning both the shared adapter and per-plugin APIs from stack().

Introduces standalone DB getter modules (and exports/tests/docs) for blog, cms, form-builder, kanban, and ai-chat, and wires these getters into each plugin’s api namespace; cms also shares its one-time content-type sync between HTTP routes and the new getters.

Refactors blog and kanban list endpoints (and corresponding client/query code + e2e tests) to return paginated envelopes ({ items, total, limit, offset }) and moves list logic into getters (including DB-level tagSlug filtering for blog). Also adjusts form submission parsing to allow parsedData: null and updates UI call sites accordingly. Bumps @btst/stack to 2.2.0.

^{Written by Cursor Bugbot for commit 72ddce7. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
better-stack-docs	Ready	Preview, Comment	Feb 20, 2026 10:03pm

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Inconsistent where parameter between count and findMany

Medium Severity

In getAllPosts, adapter.count receives dbWhere (which converts an empty whereConditions array to undefined), but adapter.findMany on line 114 receives whereConditions directly (potentially an empty array []). If an adapter implementation treats where: [] differently from where: undefined, the total count and the returned items would be filtered inconsistently, producing incorrect pagination metadata. The other new getter functions (kanban, form-builder) all consistently use whereConditions.length > 0 ? whereConditions : undefined for both calls. The findMany call here likely intended to use dbWhere instead of whereConditions.

Additional Locations (1)

• packages/stack/src/plugins/blog/api/getters.ts#L103-L107

 

[cursor]

Blog handler duplicates tag queries before calling getter

Low Severity

When tagSlug is provided, the listPosts handler performs two database queries (tag lookup + postTag lookup) as a guard, then calls getAllPosts which repeats the exact same two queries internally. This doubles the DB roundtrips for every tag-filtered request. The guard exists solely to skip the onPostsRead hook when results are empty — a simpler approach would be to call getAllPosts once and conditionally invoke the hook based on result.items.length, eliminating the redundant queries entirely.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}