Backend

“Backend” in HiveCFM is a fuzzier term than in a typical ASP.NET shop. There is no dedicated backend service for the web app — the backend is Next.js, running under apps/web/ in the same process that renders the UI. The Go Hub is a separate service, documented in Hub.

What this section covers

Everything the Node.js runtime executes on the server side of hivecfm-core:

API routes under apps/web/app/api/ — REST handlers invoked by the Survey Widget, the JS SDK, third parties, and webhooks.
Server Actions — functions marked "use server" that the UI calls directly.
Shared workspace packages in hivecfm-core/packages/ — the typed libraries (@hivecfm/database, @hivecfm/logger, @hivecfm/types, etc.) that the routes and actions import.

It does not cover the Go Hub, which handles async work, embeddings, and semantic search — see Hub for that.

What runs where

Responsibility	Where it lives	Runtime
UI rendering + page data reads	`apps/web/app/(app	auth)/…/page.tsx`
Mutations triggered from the UI	`apps/web/app/.../actions.ts`	Node (Server Actions)
REST for external callers	`apps/web/app/api/v1/` and `apps/web/app/api/v2/`	Node (route handlers)
Webhook receivers (incoming)	`apps/web/app/api/v1/webhooks/`	Node (route handlers)
Webhook dispatch (outgoing)	`hivecfm-hub/internal/workers/webhook_dispatch.go`	Go
Embeddings, sentiment, semantic search	`hivecfm-hub/internal/service/`	Go
Scheduled jobs	`apps/web/app/api/cron/` (invoked by Azure scheduler)	Node

The request/response shape (.NET analogy)

A HiveCFM API route is a single function per HTTP verb, exported by name:

export const GET = async (req: Request) => { … }
export const POST = async (req: Request, ctx: { params }) => { … }

Compare to ASP.NET Core:

Piece	ASP.NET Core	HiveCFM
Route binding	`[HttpGet("/api/v2/…")]` attribute	Folder path `app/api/v2/…/route.ts`
Input validation	DataAnnotations / FluentValidation	`zod` schemas (`ZResponseInputV2`)
Auth	`[Authorize]` attribute	Helper at top of handler (e.g. `getEnvironmentAuth`)
Response helpers	`Ok()`, `BadRequest()`	`responses.successResponse(...)`, `responses.badRequestResponse(...)`
Dependency injection	`IServiceProvider`	Plain imports — no container

There is no global DI container. Shared state (the Prisma client, the logger) is a module-level singleton exported from the relevant workspace package.

Shared packages worth knowing

Found in hivecfm-core/packages/:

@hivecfm/database — the generated Prisma client, migration runner, and seed scripts.
@hivecfm/logger — the pino-backed structured logger (see DevOps / Observability).
@hivecfm/types — shared zod schemas + TypeScript types used across routes.
@hivecfm/cache — Redis wrapper for short-lived caches and rate-limit counters.
@hivecfm/email — email templates and the send abstraction.
@hivecfm/storage — MinIO/S3 client.

Every route handler is a thin orchestrator: it validates with zod types, calls a helper from one of the packages above, and returns.

Coming from .NET? The best mental model is “a minimal-APIs app where the endpoints are a filesystem of route.ts files, and the services are imported directly instead of resolved from a DI container.”