Project Templates

What every template sets up

• SQLite with Pro The database is a file next to the app, created on the first run. Pro is free for the whole 4.x line.
• PVT prefilter and change tracking Both on in Program.cs. A selective filter does not read the whole scheme; a save writes only the fields that changed.
• Props cache, one comment away Off by default. EnablePropsCache, PropsCacheMaxSize and PropsCacheTtl sit in a comment next to the other settings.
• Docker and compose A Dockerfile, and compose files for PostgreSQL and SQL Server in deploy/.

Another database

Only redb takes --db. In the other templates the switch is three edits, and each compose file repeats them at the top:

1. in the .csproj, replace redb.SQLite.Pro with redb.Postgres.Pro or redb.MSSql.Pro;
2. in Program.cs, replace .UseSqlite(...) with the commented .UsePostgres(...) or .UseMsSql(...);
3. put the connection string into appsettings.json. The database must exist: RedBase creates its tables, not the database.

Own host or Tsak module

redb-worker, redb-chat and the servers of redb-app and redb-bff are a module plus a host. The module holds the routes and a public static InitRoute.main(IRouteContext). The host builds a route context and calls that method, exactly as a Tsak worker does, so the route code exists once.

Settings travel the same way in both: the module's *.config.json first, then the Tsak:Contexts:<context>:Override section of the host configuration, which wins. So one environment variable, for example Tsak__Contexts__myworker__Override__Folders__Inbox (the context is the project name in lower case), works in the own host and on a Tsak worker.

cp deploy/.env.example deploy/.env      # fill in the Tsak values
pwsh deploy/pack-tpkg.ps1               # -> deploy/output/<Name>.tpkg
docker compose -f deploy/docker-compose.tsak.yml up -d

A redb: console app

The basics of RedBase in one Program.cs: create an object, load it, change it, query with LINQ over your own properties, aggregate in the database, build a three-level tree and delete it with its children.

dotnet new redb -n MyApp
cd MyApp
dotnet run

B redb-razor: Razor Pages site

A product list with search by name, an in-stock filter, sorting and paging, all in the database: the page never loads more than one page of objects. A create / edit form with validation, and sample data on the first run.

dotnet new redb-razor -n MySite
cd MySite
dotnet run            # http://localhost:5080

C redb-blazor: Blazor site

The same list and form as an interactive Blazor Server site, plus a category tree: top-level nodes from a tree query, subtrees, add a child, delete a node with its subtree.

dotnet new redb-blazor -n MySite
cd MySite
dotnet run            # http://localhost:5081

D redb-worker: integration worker

Order files arrive in a folder, are checked against an XSD schema, stored in RedBase in one .Transacted() step and answered with a receipt file. The order id is the object's unique key, so a repeated order is answered as a duplicate, even when two copies arrive at once.

dotnet new redb-worker -n MyWorker
cd MyWorker
dotnet run --project MyWorker.Host
# in a second terminal:
cp samples/order-1001.xml data/inbox/

For another source replace one From(...) line: Sftp.Directory(...) from redb.Route.Sftp, As2.Receive(...) from redb.Route.As2, Sql.Poll(...) from redb.Route.Sql.

E redb-chat: LLM chat

A chat on redb.Route.Llm. The conversation history is kept in RedBase, so a chat goes on after a restart. You talk to it in the console, or over HTTP with X-Chat-Id naming the conversation.

dotnet new redb-chat -n MyChat
cd MyChat
# put your API key into MyChat.Host/appsettings.json (ApiKey)
dotnet run --project MyChat.Host
curl -d "hello" -H "X-Chat-Id: my-chat" http://localhost:5090/api/chat

F redb-app: Blazor WebAssembly app

A WebAssembly client that runs in the browser, and an API on the redb.Route REST DSL: sign-in, the product list and form, the category tree. Two processes, as in production.

dotnet new redb-app -n MyApp
cd MyApp
dotnet run --project MyApp.Host     # API on http://localhost:5092
dotnet run --project MyApp.Web      # client on http://localhost:5082, admin / admin

POST /api/auth/login returns a signed token. Every other route is declared with InboundAuth = Bearer: a request without a valid token gets 401 before the route runs. In development the API answers CORS for the client's port; in a deployment nginx serves the client and forwards /api/, so the browser sees one origin.

cp deploy/.env.example deploy/.env   # APP_SIGNING_KEY, APP_ADMIN_PASSWORD
docker compose -f deploy/docker-compose.yml up --build   # http://localhost:8080

G redb-bff: Blazor BFF

A Blazor Server web server where users sign in with a cookie session, and a backend of redb.Route controllers that only the web server may call. The browser never sees the backend or its key.

dotnet new redb-bff -n MyApp
cd MyApp
dotnet run --project MyApp.Host     # backend on http://127.0.0.1:5093
dotnet run --project MyApp.Web      # web server on http://localhost:5083, admin / admin

The controllers take their IRedbService from the request, Context.GetRedbService("", Exchange), so parallel requests never share a connection. The web server sends the service key as a bearer token; any other caller gets 401.

Comparison