DEV Community: RapidKit

I Spent 45 Minutes Setting Up a Backend… Before Writing a Single Line of Logic

RapidKit — Tue, 28 Apr 2026 10:36:15 +0000

Last week, I spun up a new FastAPI service.

45 minutes later… I still hadn’t written a single line of business logic.

Not because coding is hard —
but because everything around the code is broken.

Missing .env keys
Docker half-working
DB migrations out of sync
One internal service silently failing

If you’ve built more than one backend, you’ve lived this.

We don’t have a coding problem

We have a setup problem disguised as engineering.

Most of our time isn’t spent writing logic.

It’s spent:

reconfiguring environments
fixing invisible dependencies
debugging things we already debugged before

The “Context Gap”

Tools like Copilot help you write code faster.

But backend work doesn’t happen at the file level.

It happens at the workspace level.

Your tools don’t know:

your architecture
your running services
your conventions
your dependencies

So you end up with:

👉 Faster code
👉 Same broken systems

I tried a different approach

I got tired of this loop… so I started experimenting with a different idea:

What if the workspace understood the system?

Not just syntax.

Not just files.

But the actual backend state.

What changed

1. No more blind debugging

Missing .env → detected instantly
Broken service → flagged before runtime
Dependency issues → visible early

2. Scaffolding that respects architecture

Not just boilerplate:

clean structure
production-ready setup
enforced conventions

3. Change impact awareness

Before refactoring:

“This will affect 3 modules and 2 endpoints.”

4. Debugging with context

No more copy-pasting logs into AI.

The system already understands the error.

The shift we’re ignoring

We’re not just writing code anymore.

We’re managing systems.

But our tools are still stuck in:

“write this function”

instead of:

“understand this system”

Curious how others deal with this

What’s the most frustrating part of your backend setup?

boilerplate?
debugging?
environment issues?

Would love to hear real workflows.

(If you're curious, I shared more details here: https://www.workspai.com/)

The Best AI Feature for Backend Developers Is a Resolution Loop

RapidKit — Sun, 26 Apr 2026 07:36:05 +0000

AI devtools usually market themselves around a single visible surface:

chat
code generation
agent mode
autocomplete

Those matter.

But if you work mostly on backend systems, the feature that changes your day is usually not a standalone prompt box.

It is a workflow that helps you go from incident to verified fix faster and with less risk.

That is why I think the strongest AI pattern for backend tooling is a resolution loop:

detect
diagnose
plan
verify
learn

This is the product direction behind Workspai's Chat Brain surfaces.

Why backend work needs more than chat

Backend incidents usually start from a live signal, not a blank question.

Examples:

a failing startup command
a broken health check
an environment mismatch
a change that might break routing or module wiring
a repeated team convention the AI keeps forgetting

If the AI only sits in a generic chat surface, the developer still has to manually package the problem.

That means:

copying terminal output
explaining the project structure
listing installed modules
describing the framework conventions
guessing what action is safest next

That is extra work exactly when the user wants less.

The killer features only make sense as a connected system

1. Terminal bridge

This is the best entry point because it captures the pain moment directly.

Instead of asking the user to translate terminal noise into a prompt, the product can turn terminal evidence into a structured diagnosis and next action.

2. Change impact before fix

One of the fastest ways to lose trust in an AI tool is to let it jump from idea to mutation with no guard rails.

Impact analysis gives the user a chance to understand blast radius first.

3. Fix preview before apply

Preview matters because backend teams need inspectable changes, not magic.

The AI should make the intended path visible before asking for trust.

4. Verification after action

This is the most underrated part.

A tool is not trustworthy because it sounds correct. It is trustworthy because it helps prove whether the suggested change actually worked in this workspace.

5. Workspace memory

The last step is compounding.

If the same team keeps facing the same kinds of incidents, the tool should get better at routing and suggesting based on accumulated conventions and decisions.

That is how AI moves from helper to operating layer.

What makes this stronger than a generic assistant

A generic assistant answers.

A backend resolution loop does four extra things:

starts from real workspace evidence
constrains risky actions
encourages verification
saves useful context for future incidents

That combination is much more valuable than just adding another AI command.

Product takeaway

If you are building AI tooling for developers, do not just ask:

how do we make the chat better?

Ask:

where does the real pain begin?
what is the safest next action?
how do we verify success?
how do we keep the learning?

That is where the real killer feature lives.

Closing

For backend developers, the best AI feature is not a smarter chat window.

It is a tighter resolution loop.

That is the difference between an AI tool that looks impressive and one that becomes part of the daily workflow.

What would you prioritize most in that loop: diagnosis, preview, verification, or memory?

🔗 Workspai

🔗 Workspai on VS Code Marketplace

🔗 RapidKit open-source platform

🔗 GitHub

Why Do Backend Teams Need a Workspace-Based AI Layer?

RapidKit — Fri, 24 Apr 2026 05:09:45 +0000

Backend development breaks AI out of the file-level model fast. Here is why backend teams need a workspace-based AI layer, and how Workspai uses that architecture to make generation, debugging, health checks, module operations, and team context actually useful.

Why Do Backend Teams Need a Workspace-Based AI Layer?

The AI workspace for backend teams.

Build backend systems with AI that knows your workspace.

Backend AI usually breaks on context, not raw model quality.

Most AI coding tools operate at file level. That is enough for isolated tasks. It is not enough for real backend work, where the useful context lives across the workspace:

project structure
framework, kit, and runtime
whether the service is FastAPI, NestJS, Spring Boot, Go/Fiber, or Go/Gin
installed modules
runtime state
health issues
recent changes
team conventions

That is why backend teams need a workspace-based AI layer. The workspace is the unit that makes the answers useful.

Without that layer, AI for backend development keeps falling back to generic suggestions, missing project conventions, and answers that sound right but do not fit the actual system.

Why file-level AI breaks down so quickly in backend development

Backend work is rarely one file deep. When you ask for help with a bug, a module decision, a startup issue, or a safe refactor, the real answer depends on more than the code under your cursor:

whether the project is FastAPI, NestJS, Spring Boot, Go/Fiber, or Go/Gin
whether the structure is standard or more layered
which modules are already installed
what the workspace doctor has already flagged
what conventions your team has decided to keep

If the AI does not know that context, it can still sound smart while being operationally wrong.

That is exactly the kind of failure Workspai is trying to reduce for backend teams.

What the workspace-based model changes for users

From the user side, the value is simple: instead of re-explaining your backend every time you ask AI for help, the product already understands the surrounding system.

The easiest way to see that is to walk through the feature surface.

1. The non-AI workspace platform features

These are the features that make the workspace itself actionable inside VS Code.

Workspace Explorer

The dedicated sidebar tree is the structural backbone of the extension. It exposes:

workspaces
projects
RapidKit modules
quick actions

Because Workspai understands the workspace hierarchy, users do not have to jump between terminal commands, file explorers, and docs just to stay oriented.

Project Scaffolding

Workspai supports one-command project creation for:

FastAPI
NestJS
Spring Boot
Go/Fiber
Go/Gin

That matters because the generated structure becomes part of the AI context later.

On the runtime side, the broader RapidKit stack now also supports Java-oriented workspace profiles such as java-only, plus polyglot workspaces that include Java alongside Python, Node, and Go. That makes the workspace model even more important, because once a backend team is working across runtimes, file-level AI loses context even faster.

Module System

Workspai exposes the RapidKit module system directly in the IDE, so users can browse and manage modules in a workspace-aware way instead of treating dependencies as disconnected package installs.

The current surface highlights 100+ RapidKit modules, with examples like:

auth_core
db_postgres
stripe_payment

This is a major architectural advantage because AI advice can be grounded in the real module ecosystem that the workspace already uses.

Health Doctor

The doctor feature checks:

environment variables
dependencies
port conflicts
kit configuration

This matters because backend AI should not operate blind to system health.

Dev Server Control

Start, stop, and restart backend dev servers directly from the VS Code sidebar.

This keeps operational state inside the same product surface that AI features rely on.

Workspace Dashboard

The dashboard acts as the single pane of glass for:

project tree
health status
module inventory
AI launch points

This is where the workspace-based model becomes visible to the user.

2. The current AI feature surface

The AI side of Workspai only works because it sits on top of the workspace platform.

AI Create

AI Create starts from product intent in plain language.

Example prompt:

Build a SaaS billing API with auth, Stripe, and Postgres

From there, Workspai proposes:

workspace direction
project kit
likely modules

That only works well when the product treats generation as a workspace problem, not just a code snippet problem.

Project Assistant

This is context-aware Q&A grounded in the actual project files, modules, and architecture.

Example:

What breaks if I change this settings model?

The important part is that it answers in relation to the workspace.

Workspace Brain

AI appears inline on every item in the workspace explorer:

workspaces
projects
modules

That is a very specific product choice. It means AI is embedded inside the structure of the backend system, not floating outside it.

`@workspai` in Chat

The native VS Code Chat participant exposes:

/ask
/debug

Example:

@workspai /debug Why does this endpoint return 500?

The chat surface becomes more useful because the product already knows the project context behind the question.

AI Debug Actions

The editor lightbulb gives contextual AI debugging directly on files with issues.

Example:

Why does this endpoint return 422 Unprocessable Entity?

This works better than generic debugging chat because the action starts from the local error and the broader workspace at the same time.

The same idea matters for Java teams too. If part of your backend runs on Spring Boot, you still want debugging help to start from the real workspace context instead of a detached code sample or pasted error.

Doctor Fix with AI

Each health issue can open a context-rich AI fix flow.

Example:

Fix missing environment variable in billing-platform

This is useful because it is anchored to an issue the workspace doctor already found.

Fix Preview Lite

Example:

Preview the safest fix for this 500 error

This matters because backend teams need inspectable actions, not blind mutations.

Change Impact Lite

Example:

If I change this auth middleware, what might break?

This treats the codebase as an interconnected workspace where changes have operational impact beyond one file.

Terminal → AI Bridge

Example:

Analyze this pytest failure and suggest the fastest safe fix

Terminal output without workspace context is noisy. With workspace context, it becomes much more actionable.

Workspace Memory

Teams can write conventions into .rapidkit/workspace-memory.json and have them injected into every AI prompt.

Example memory:

Always use async SQLAlchemy and avoid sync session in routes

This is one of the strongest reasons the workspace model matters: AI becomes cumulative instead of stateless.

Memory Wizard

The wizard helps capture:

project overview
conventions
architecture decisions

That lowers the cost of making the workspace smarter over time.

AI Recipe Packs

Example:

Run ship-readiness recipe for this workspace

Recipe Packs make more sense in a workspace product than in a generic assistant, because they can assume a richer backend context and a repeatable operational flow.

Module Advisor

Example:

How do I wire up db_postgres with auth_core?

The AI is not just answering abstract backend questions. It is guiding users through the real module system that exists in the workspace.

For mixed-runtime teams, that matters even more. Once you have Python, Node, Go, and Java services inside one operational environment, the workspace becomes the only reliable context boundary.

Telemetry Insights

Example:

Show telemetry summary for the last 7 days

Telemetry helps the team understand:

which AI actions are used
which onboarding flows convert
what becomes habit vs novelty

This is part of the model too. A workspace-based AI product needs evidence about how the actions are actually used.

3. The upcoming Pro and Team layer

The roadmap also follows the same logic. These are not random upsells. They are natural extensions of the workspace-based model.

Module Generator (Pro)

Example:

Add OTP login with Redis rate limiting and tests

This is a multi-file, multi-concern operation that only works safely if the system understands project structure and module relationships.

AI Debugger (Advanced) (Pro)

Example:

Why is this endpoint returning 500 in staging?

Advanced debugging becomes much more valuable when it is grounded in the workspace rather than limited to pasted logs.

Test Generator (Pro)

Example:

Generate tests for the booking cancellation endpoint

Test generation depends on understanding workspace boundaries and project conventions.

DevOps Assistant (Pro)

Example:

Generate a production-ready Compose file for this API

This is workspace-aware operations and environment design, not just code generation.

Architecture Advisor (Pro)

Example:

How should I scale this service for 10x traffic?

Architecture guidance without workspace context is generic. With it, guidance becomes much more useful.

Team AI Memory (Team)

Example:

Enforce our naming conventions across all new modules

This extends the current Workspace Memory model from one workspace to a shared team layer.

Why backend teams need this architecture, not just better prompts

There are three reasons backend users benefit from this model.

1. Less context re-explaining

Without the workspace as the core unit, users still have to manually restate:

what stack they are using
what modules are installed
what conventions matter
what the system health already says

That repetition is one of the biggest taxes in AI-assisted backend work, and the workspace layer removes a big part of it.

2. Better backend-specific answers

The model can only be as grounded as the context it receives.

File-level AI misses too much backend reality. Workspace-level AI is not perfect, but it removes a large class of generic or contradictory responses.

3. More trust in real workflows

Backend teams need more than helpful answers. They need:

bounded actions
previews
health-aware reasoning
operational context
team memory

Those are user workflow problems as much as AI problems.

Closing

Backend teams need a workspace-based AI layer because backend development itself is workspace-shaped.

The product has to understand:

the system structure
the module ecosystem
the operational state
the memory of past decisions

That becomes even more true as Java and Spring Boot enter the same ecosystem. The moment backend teams start mixing FastAPI, NestJS, Spring Boot, Go/Fiber, and Go/Gin across one working environment, the workspace stops being a convenience and becomes the only context boundary that actually matches how the system is built.

That is what allows project scaffolding, module operations, health checks, AI assistance, debugging, preview flows, telemetry, and future pro features to feel useful in one connected workflow.

The AI workspace for backend teams.

Build backend systems with AI that knows your workspace.

If you are using AI for backend development, the question is not just how smart the model is.

It is this:

What is the real unit of context your product is built around?

Backend AI Needs an Action Surface, Not Just a Chat Box

RapidKit — Thu, 23 Apr 2026 21:39:12 +0000

Most AI developer tooling still assumes the main interface should be a chat box.

That makes sense for open-ended questions. It makes less sense for day-to-day backend work.

Backend workflows usually do not begin with a blank prompt. They begin with a broken startup command, a noisy terminal, a health check issue, a confusing project tree, a module decision, or a team convention that the AI does not know yet.

That is why the latest Workspai release matters.

Workspai v0.21.0 is not just a list of new commands. It is a step toward a different model for AI in VS Code: not just chat, but a workspace-aware action surface for backend teams.

The problem with chat-first AI in backend work

If an AI tool only waits in one prompt box, the user still has to do the routing.

They have to decide:

what context matters
what the right question is
what file or output to paste
what action should happen next

That is friction.

It gets worse in backend projects because the useful context usually lives outside the current file:

project structure
installed modules
framework conventions
runtime state
workspace health
recent changes
team decisions

Even when the model is strong, the workflow is weak if everything has to pass through a generic prompt box.

What changed in Workspai v0.21.0

The new release expands the AI action surface across the command palette, sidebar actions, and quick-action views.

The new flows include:

AI Quick Actions
Smart Route
Fix Preview Lite
Change Impact Lite
Analyze Terminal Output with AI
Guided Workspace Memory Setup
AI Recipe Packs

This changes the shape of the product.

Instead of asking the user to translate every problem into a freeform prompt, the extension increasingly exposes backend-specific AI actions in the exact places where the problem already exists.

Why small AI actions matter

Each of these actions solves a different kind of backend friction.

1. Terminal Output Analysis

Terminal output is one of the worst places to manually transfer context into AI.

You run a command, get a wall of text, then copy the relevant part into another tool and explain what project you are in.

If the AI already knows the workspace, terminal analysis becomes much more useful. The output is not interpreted in isolation. It is interpreted against the actual backend project it came from.

2. Fix Preview Lite

One reason teams hesitate to use more AI in backend workflows is trust.

They do not want a tool that jumps straight from suggestion to mutation.

Fix Preview Lite moves in a safer direction. It treats the AI as a planning and preview layer first. That is a much better fit for real engineering workflows than magic auto-apply behavior.

3. Change Impact Lite

Backend changes are rarely local. Even a small edit can have downstream effects across routing, modules, services, or startup flows.

An AI tool that helps users reason about likely impact before they change code is more valuable than one that only answers after the fact.

4. Smart Route

Sometimes the problem is not generating code. It is getting to the right place to act.

Routing is one of the most underrated uses of workspace-aware AI. If the tool understands the project shape, it should be able to direct the user toward the right file, action, or flow without forcing them to search blindly.

5. Workspace Memory Wizard

One of the biggest recurring costs in AI-assisted development is repeating team context.

What architecture does this team use?
What naming rules matter?
What decisions have already been made?

The workspace memory wizard matters because it makes that context easier to capture and reuse. This is how AI moves from session memory to workspace memory.

6. Recipe Packs

Recipe Packs push the product further toward guided workflows.

That matters because backend teams do not always want a blank canvas. Sometimes they want a known sequence of steps shaped around a recurring task.

Telemetry is not just analytics vanity

Another important part of v0.21.0 is the telemetry layer.

The release adds:

telemetry summaries
onboarding experiment stats
structured success, error, and cancel outcomes for key AI surfaces

In AI products, telemetry is often treated like growth reporting.

But for a tool like Workspai, telemetry is also product learning.

If you are expanding the AI action surface, you need to know:

which actions people actually use
where they drop off
what onboarding path leads to repeat usage
which surfaces are noisy and which become habitual

That is especially important for backend AI because the winning interface probably will not be one monolithic surface. It will be a set of context-aware actions that earn their place in the workflow over time.

Reliability work matters as much as visible features

The release also fixes three less glamorous but more important issues:

doctor metadata fetch safety
bounded port probing for dev startup
startup race conditions around workspace path initialization

This matters because backend teams will not trust AI features if the surrounding runtime is fragile.

Reliable scaffolding, stable startup flows, predictable health checks, and safe network behavior are part of the product, not separate from it.

If Workspai is positioning itself as the AI workspace for backend teams, the trust layer cannot be optional.

The bigger product direction

The most important thing about v0.21.0 is not any one command.

It is the direction it reveals.

Workspai is moving beyond "AI chat in the editor" toward a workspace-aware backend operating layer inside VS Code.

That means:

more actions that begin from real workspace context
more inspectable AI behavior
more telemetry to understand which actions become useful habits
more runtime hardening so the product feels dependable under daily use

This is a better direction for backend AI than simply adding more prompt surfaces.

Backend teams do not just need AI that can answer.

They need AI that can show up in the right place, with the right context, in the right form.

Closing

If AI is going to become part of real backend workflows, it needs more than a better model and a nicer prompt box.

It needs a better action surface.

That is what Workspai v0.21.0 pushes forward.

The AI workspace for backend teams.

Build backend systems with AI that knows your workspace.

If you use AI in backend work, what would you want one click away first: terminal analysis, fix preview, change impact, routing, or something else?

AI Coding Tools Have a Context Problem — Here's the Fix

RapidKit — Tue, 21 Apr 2026 08:11:47 +0000

The Wrong Unit of Context

Most AI coding tools work at the file level.

That's fine for a React component. A component is self-contained — the context needed to help you fits in the file.

Backend services aren't self-contained. They live inside environments. They share infrastructure. They depend on modules installed at the workspace level.

This is why AI backend debugging suggestions are often... almost right. They're missing environment context.

What a Backend AI Actually Needs

Take this error:

redis.exceptions.ConnectionError: Error 111 connecting to localhost:6379

A file-level AI tells you: Redis isn't running.

A workspace-aware AI knows:

You have redis-cache module installed in auth-api
Your Workspace Health check already flagged this
You're using Docker Compose conventions (RapidKit workspace)

The second answer is specific. The first is a starting point you still have to work from.

The Workspace as Context Unit

In Workspai, when AI responds to a debug action, it receives:

{
  "project": "auth-api",
  "type": "fastapi.standard", 
  "modules": ["jwt-auth", "redis-cache"],
  "python": "3.12.3",
  "health_warnings": ["Redis not reachable at localhost:6379"],
  "error": "ConnectionRefusedError at line 89"
}

Not file contents. A structured workspace snapshot. The response is grounded from the first message.

Why the Workspace Format Matters

This only works because RapidKit defines a structured workspace format. It knows:

Which projects exist and what type they are
Which modules are installed at each project
The runtime version
The current health state

Without this structure, you'd have to infer context from file contents — slow, unreliable, incomplete.

With it, context assembly is deterministic. The AI starts informed.

What's Available Now (v0.20)

@workspai Chat Participant — use @workspai /ask for full-context Q&A scoped to your active project, or @workspai /debug for structured root-cause + fix + prevention, directly in the VS Code Chat panel
AI Create with presets — describe a project in plain language (or pick a smart preset), and AI plans the workspace, picks a kit, and selects modules
AI Debug Actions — lightbulb in Python/TS/JS/Go files with workspace-aware context
Doctor Fix with AI — one-click AI resolution for workspace health issues
Module Advisor — compatible module suggestions based on what you're building
Workspace Memory — persistent AI context scoped to the workspace, carried across sessions

All on top of the existing RapidKit workspace platform. No changes to CLI, kits, or modules.

The Bigger Picture

The teams that establish workspace structure now will leverage AI more effectively as the tools improve. Workspace-aware AI will become the baseline expectation — the file level will feel like working blind.

🔗 workspai.com

🔗 Workspai — VS Code Marketplace

🔗 getrapidkit.com

Stop Copy-Pasting Errors into ChatGPT — Use AI That Knows Your Backend Stack

RapidKit — Sat, 18 Apr 2026 08:53:21 +0000

Workspai's AI Debug Actions feed structured workspace context to the language model — project type, installed modules, Python version, health status. The result: debugging suggestions that actually apply to your setup.

You know the loop.

1. Error appears in FastAPI service
2. Open ChatGPT/Claude/Copilot Chat
3. Paste traceback
4. Type: "I'm using FastAPI 0.115, Python 3.12, SQLAlchemy 2.0, 
         repository pattern, RapidKit workspace..."
5. Get generic answer
6. Iterate

Steps 3-4 are manual reconstruction of context your IDE already has.

Here's how we closed that loop in Workspai.

What the AI Actually Receives

When you click a debug action on a diagnostic error, Workspai sends this to the language model:

{
  "project_type": "fastapi.standard",
  "python_version": "3.12.3",
  "installed_modules": ["jwt-auth", "redis-cache"],
  "rapidkit_cli_version": "0.25.4",
  "rapidkit_core_version": "0.3.9",
  "error": {
    "message": "AttributeError: 'NoneType' object ...",
    "file": "src/users/services/user_service.py",
    "line": 47
  },
  "workspace_health": "warning: Redis not running"
}

Not raw text. Structured context. The model's first response is already grounded in your setup.

Two Editor Surfaces

In any Python, TypeScript, JavaScript, or Go file with diagnostics:

Click the lightbulb → you'll see:

✦ Debug with Workspai AI — opens AI modal with error + full workspace context pre-filled
✦ Explain error with AI — plain-language explanation tailored to your stack

Both appear in the standard VS Code Code Actions menu — no new panel, no context switch.

Doctor Fix with AI

The Workspace Health sidebar runs a system check. When it finds an issue:

⚠️ Redis not reachable
Module: redis-cache (installed in auth-api)
Expected: localhost:6379
Status: connection refused

There's now a ✨ button. Click it. The AI gets the full failure context — module name, expected config, error type — and tells you exactly how to fix it for your specific workspace setup.

No more: Google → StackOverflow → "does this apply to me?" → iterate.

The Tech

Uses GitHub Copilot's vscode.lm API locally. No separate key. No data beyond what Copilot normally sends. Configurable model (modern Copilot/GitHub lineup, including GPT-5 family, GPT-4.1/4o, and Claude Sonnet family, depending on account access).

Install

Search Workspai in VS Code Extensions.

Publisher: rapidkit | Requires GitHub Copilot.

🔗 workspai.com · Marketplace · GitHub · getrapidkit.com

We Rebuilt Our VS Code Extension with AI — Meet Workspai

RapidKit — Fri, 17 Apr 2026 16:23:25 +0000

The Problem with Generic AI Assistants

Every AI tool I've used in the past year has the same blind spot:

It doesn't know what I'm building.

Ask GitHub Copilot to help debug a FastAPI error and it gives you a correct-but-generic answer. It doesn't know you're running inside a RapidKit workspace. It doesn't know which modules you've installed. It doesn't know your project uses DDD architecture.

You end up spending as much time explaining context as you save generating code.

That's what we wanted to fix.

What Is Workspai?

Workspai is the AI-powered VS Code extension built on top of RapidKit — the open-source workspace platform for backend development. Learn more at workspai.com.

Think of it as: your workspace knows everything about your backend setup, and the AI taps into that.

Four AI Features That Use Your Workspace Context

✦ AI Create

Describe a project in plain language. Workspai selects the right kit, suggests relevant modules, pre-fills configuration. Works for FastAPI, NestJS, Go.

"A FastAPI authentication service with JWT, Redis sessions, and email verification"
→ Kit: fastapi.standard
→ Suggested modules: jwt-auth, redis-cache, email-smtp
→ Project scaffolded with modules pre-selected

✦ AI Debug Actions

See a diagnostic error in your Python/TypeScript/Go file? The lightbulb now includes:

✦ Debug with Workspai AI — pre-fills the error + workspace context
✦ Explain error with AI — plain language explanation with fix suggestions

The difference: it knows you're on FastAPI 0.115 in a RapidKit workspace on Python 3.12. The fix it gives you actually applies.

✦ Doctor Fix with AI

The Workspace Health sidebar runs a system check. When it finds an issue, a ✨ button appears next to it.

Click → AI gets the full issue context → suggests exact fix steps.

No more copy-pasting error messages into ChatGPT.

✦ Module Advisor

When creating a project, describe what you're building. Workspai suggests which modules fit your stack, which are compatible, which are already installed elsewhere in your workspace.

Under the Hood

Uses GitHub Copilot's local language model API (vscode.lm). No separate API key. No data beyond what Copilot normally sends. Works with GPT-4o, Claude Sonnet, or whatever model you have access to.

The AI receives structured workspace context plus targeted file excerpts. Project types, installed modules, health status, selected errors, and key entry files. Focused, not noisy.

What Stayed Unchanged

RapidKit's workspace platform is exactly the same:

npx rapidkit create workspace my-backend
cd my-backend
npx rapidkit create project fastapi.standard auth-api
npx rapidkit create project nestjs.standard notifications

All kits. All modules. All CLI commands. Unchanged.

Workspai is a product layer built on top — specifically for VS Code users who want the AI layer.

Install

Search Workspai in VS Code Extensions, or:

Publisher: rapidkit · Extension ID: rapidkit.rapidkit-vscode

Requires GitHub Copilot for AI features.

🔗 workspai.com

🔗 VS Code Marketplace

🔗 getrapidkit.com

🔗 GitHub

Stop Managing 10 Virtual Environments. Use a Workspace.

RapidKit — Sat, 21 Feb 2026 07:56:28 +0000

How RapidKit's workspace architecture eliminates environment drift, cuts setup time to minutes, and lets you manage FastAPI, NestJS, and Go services from a single shared environment.

I used to manage backend projects like this:

/projects/
  auth-api/       ← Python 3.10, venv, poetry
  billing-api/    ← Python 3.11, venv, pip
  user-service/   ← Python 3.10, venv, poetry (different poetry version)
  ai-agent/       ← Python 3.11, conda (someone on the team liked conda)
  notifications/  ← NestJS (fine, no env problem here)

Every project had its own environment. Every new service meant 20–30 minutes of setup. Every git clone from a teammate ended in "it works on my machine."

Sound familiar?

The Fix: Shared Workspace Environment

The concept is simple: one environment hosts multiple services.

my-workspace/
├── .venv/                  ← shared Python env (~150 MB, once)
├── pyproject.toml          ← shared dependency config
├── .rapidkit-workspace     ← workspace marker
├── auth-api/               ← FastAPI project
├── billing-api/            ← FastAPI DDD project  
├── notifications/          ← NestJS project
└── ai-agent/               ← FastAPI + AI module

All services share the same Python version, the same virtualenv, the same tooling. But each service is independently deployable with its own Dockerfile, pyproject.toml, and CI pipeline.

From Zero to Multi-Service Backend

Here's how fast this actually is with RapidKit:

# 1. Create the workspace
npx rapidkit create workspace my-workspace
cd my-workspace

# 2. Scaffold services (pick your kits)
npx rapidkit create project fastapi.standard auth-api
npx rapidkit create project fastapi.ddd billing-api
npx rapidkit create project nestjs.standard notifications
npx rapidkit create project gofiber.standard high-perf-proxy

# 3. Init all services at once (from workspace root)
npx rapidkit init

# 4. Check everything
npx rapidkit doctor --workspace

That last command gives you this:

📊 Health Score:
   100% ████████████████████
   ✅ 12 passed | ⚠️ 0 warnings | ❌ 0 errors

System Tools:
✅ Python: Python 3.11.8
✅ Poetry: Poetry 2.3.1
✅ Go: Go 1.24.4
✅ RapidKit Core: 0.3.8

Projects:
✅ auth-api          FastAPI Standard  | Tests ✅ | Docker ✅ | Deps ✅
✅ billing-api       FastAPI DDD       | Tests ✅ | Docker ✅ | Deps ✅
✅ notifications     NestJS Standard   | Tests ✅ | Docker ✅ | Deps ✅
✅ high-perf-proxy   Go/Fiber Standard | Tests ✅ | Docker ✅ | Deps ✅

One command. Full workspace health report.

What Each Scaffolded Project Includes

Every rapidkit create project gives you a production-ready base:

	FastAPI Standard	FastAPI DDD	NestJS Standard	Go/Fiber Standard
Clean Architecture	✅	✅ DDD layers	✅	✅
Docker + Compose	✅	✅	✅	✅ multi-stage
GitHub Actions CI	✅	✅	✅	✅
Tests	✅ pytest	✅ pytest	✅ Jest	✅ Go test
Linting	✅ ruff	✅ ruff	✅ ESLint	✅ golangci-lint
.env handling	✅	✅	✅	✅
Health endpoint	✅	✅	✅	✅
Makefile	✅	✅	✅	✅

Zero config. All baked in.

The Module System: Composable Features

Once your project exists, add features with one command:

cd auth-api
rapidkit add module auth          # JWT/session auth
rapidkit add module db_postgres   # async SQLAlchemy + Alembic
rapidkit add module redis         # caching layer
rapidkit add module rate_limiting # route-level rate limits
rapidkit add module observability # Prometheus metrics + tracing

cd billing-api
rapidkit add module auth          # same auth module, same interface
rapidkit add module stripe        # Stripe webhooks + billing logic

cd ai-agent
rapidkit add module ai_assistant  # multi-provider AI (OpenAI, local)

27+ modules available. Each module:

Adds pre-configured code in the right layers
Updates pyproject.toml / package.json automatically
Includes tests
Follows the same clean architecture conventions

Live Example: AI Workspace

The my-ai-workspace in rapidkit-examples has two services:

ai-agent — FastAPI with ai_assistant module (multi-provider: OpenAI, echo, support)
ai-agent-nest — NestJS equivalent

# Clone and run the example
git clone https://github.com/getrapidkit/rapidkit-examples
cd rapidkit-examples/my-ai-workspace

# One command to init everything
npx rapidkit init

# Run the AI agent
cd ai-agent && rapidkit dev

# Test it
curl -X POST http://127.0.0.1:8000/ai/assistant/completions \
  -H "Content-Type: application/json" \
  -d '{"prompt": "What is RapidKit?", "provider": "echo"}'

Works without an OpenAI key — falls back to local providers automatically.

The VS Code Extension: Workspace Without the Terminal

If CLI isn't your primary workflow, the RapidKit VS Code Extension gives you:

Workspace Explorer tree — all services visible at a glance
One-click service creation — no npx needed
Module browser — search, preview, install from the UI
Live health indicators — real-time service status
Integrated doctor output — health checks without leaving the editor

Open workspace folder → see all services → click to create/manage. That's it.

Why This Matters for Scaling

The workspace model pays off exponentially as you grow:

Services	Traditional (separate envs)	Workspace
1	30 min setup	2 min setup
3	90 min + env drift	5 min, zero drift
5	150 min + conflict debugging	8 min, single health check
10	Week of onboarding per engineer	1 day onboarding for all services

Onboarding a new engineer to the entire workspace:

git clone <workspace-repo>
cd my-workspace
npx rapidkit init  # installs shared env + all project deps
npx rapidkit doctor --workspace  # ✅ everything green

Done. One command. Full environment.

Key Takeaways

Workspace = one venv, many services — no environment drift, consistent tooling
npx rapidkit create project <kit> <name> — production-ready service in under 2 minutes
rapidkit add module <slug> — features composed consistently across services
npx rapidkit doctor --workspace — full workspace health in one command
Supports FastAPI, FastAPI DDD, NestJS, Go/Fiber — mixed-language workspaces supported
VS Code Extension — visual interface for the full workflow

Get Started

npx rapidkit create workspace

→ getrapidkit.com
→ Examples repo
→ VS Code Extension

Have you dealt with environment drift in a multi-service backend? What was your solution? Drop it in the comments.

Build a Production-Ready FastAPI E-Commerce API with RapidKit (Step-by-Step)

RapidKit — Tue, 17 Feb 2026 07:44:56 +0000

Let's Build Something Real

Not a hello-world demo. A real FastAPI project you can deploy.

We'll build a Product Management API with:
• Authentication
• PostgreSQL database
• Redis caching
• Email notifications
• Production deployment

Let's begin.

Before We Begin: Three Ways to Create Projects

🎯 Approach 1: Workspace-First (Recommended)

npx rapidkit my-workspace
cd my-workspace
rapidkit create project fastapi.standard product-api

Best for: Teams, multiple services, production

🚀 Approach 2: Direct Project Creation

npx rapidkit create project fastapi.standard product-api
cd product-api
npx rapidkit init

Best for: Single project, learning, prototyping

🎨 Approach 3: VS Code Extension

Install extension
Ctrl+Shift+P → "RapidKit: Create Project"
Choose FastAPI
Enter name

Best for: Visual learners, GUI preference

We'll use Approach 1 (workspace) for this tutorial.

Prerequisites

You need:
• Node.js 20+
• Python 3.10+
• Docker (for PostgreSQL/Redis)

That's it. RapidKit handles the rest.

Step 1: Create Workspace and Project

# Create workspace
npx rapidkit my-workspace
cd my-workspace

# Create FastAPI project
rapidkit create project fastapi.standard product-api
cd product-api

What you get:
• Clean src/ architecture
• Health check endpoint (/health)
• Testing setup (pytest)
• Docker configs
• CI/CD templates

Step 2: Initialize Project

rapidkit init

This installs:
• Poetry (if needed)
• All dependencies
• Development tools

Then start the server:

rapidkit dev

Output:

INFO: Uvicorn running on http://127.0.0.1:8000

Visit: http://localhost:8000/docs

You see Swagger UI with /health endpoint.

Step 3: Add Configuration Module

rapidkit add module settings

Settings module provides:
• Multi-source config (.env, env vars, CLI)
• Type-safe with Pydantic
• Environment-specific overrides

Create .env:

APP_NAME=Product API
APP_ENV=development
LOG_LEVEL=INFO

Health check now shows:

{
  "status": "healthy",
  "modules": {
    "settings": "ok"
  }
}

Step 4: Add Database (PostgreSQL)

rapidkit add module db_postgres

Update .env:

POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_USER=myuser
POSTGRES_PASSWORD=mypass
POSTGRES_DB=productdb

Start PostgreSQL:

docker-compose up -d postgres

The module provides:
• Async SQLAlchemy setup
• Connection pooling
• Health checks
• Alembic migrations

Test connection:

curl http://localhost:8000/health

{
  "status": "healthy",
  "modules": {
    "db_postgres": "ok",
    "settings": "ok"
  }
}

Step 5: Create Product Model

src/app/models/product.py:

from sqlalchemy import Column, Integer, String, Float, Boolean
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class Product(Base):
    __tablename__ = "products"

    id = Column(Integer, primary_key=True)
    name = Column(String(100), nullable=False)
    description = Column(String(500))
    price = Column(Float, nullable=False)
    stock = Column(Integer, default=0)
    active = Column(Boolean, default=True)

Run migration:

rapidkit db migrate "Create products table"
rapidkit db upgrade

Step 6: Add Redis Caching

rapidkit add module redis

Update .env:

REDIS_URL=redis://localhost:6379

Start Redis:

docker-compose up -d redis

Use for caching:

from app.modules.redis import get_redis

async def get_product_cached(product_id: int):
    redis = await get_redis()
    cached = await redis.get(f"product:{product_id}")
    if cached:
        return json.loads(cached)

    # Fetch from DB
    product = await fetch_from_db(product_id)

    # Cache for 5 minutes
    await redis.setex(
        f"product:{product_id}",
        300,
        json.dumps(product)
    )
    return product

Step 7: Add Authentication

rapidkit add module auth_core

Features:
• PBKDF2 password hashing
• JWT token generation
• Token validation middleware

Create user:

from app.modules.auth_core import hash_password, create_token

# Hash password
hashed = hash_password("secure123")

# Store in DB
user = User(email="user@example.com", password=hashed)
db.add(user)
await db.commit()

# Generate token
token = create_token({"user_id": user.id})

Protected endpoint:

from app.modules.auth_core import require_auth

@app.post("/products")
@require_auth
async def create_product(
    product: ProductCreate,
    current_user: User = Depends(get_current_user)
):
    # Only authenticated users can create
    new_product = Product(**product.dict())
    db.add(new_product)
    await db.commit()
    return new_product

Step 8: Add Email Module

rapidkit add module email

Update .env:

SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=your-email@gmail.com
SMTP_PASSWORD=your-app-password
SMTP_FROM=noreply@productapi.com

Send email:

from app.modules.email import send_email

await send_email(
    to="customer@example.com",
    subject="Product Added to Cart",
    body="Your product is ready!",
    html=True
)

Step 9: Add Security Headers & CORS

rapidkit add module cors
rapidkit add module security_headers

Update .env:

CORS_ORIGINS=http://localhost:3000,https://yourapp.com

Your API now has:
• CSP, HSTS, X-Frame-Options
• Origin whitelisting
• Credential support
• Preflight handling

Step 10: Add Logging

rapidkit add module logging

Features:
• Structured JSON logs
• Correlation IDs
• Multi-sink (console, file, HTTP)

Logs look like:

{
  "timestamp": "2026-02-14T10:30:00Z",
  "level": "INFO",
  "message": "Product created",
  "correlation_id": "abc123",
  "user_id": 42,
  "product_id": 123
}

Step 11: Run Tests

rapidkit test

Output:

===== test session starts =====
collected 24 items

tests/test_products.py ........
tests/test_auth.py ....
tests/test_cache.py ....
tests/test_health.py ....

===== 24 passed in 3.2s =====

Every module includes tests.

Step 12: Deploy

Build Docker image:

docker build -t product-api .

Run container:

docker run -p 8000:8000 \
  -e POSTGRES_HOST=db.example.com \
  -e REDIS_URL=redis://cache.example.com \
  product-api

Or use GitHub Actions (already configured in .github/workflows/).

Project Structure (Final)

product-api/
├── src/
│   ├── app/
│   │   ├── main.py
│   │   ├── models/
│   │   │   └── product.py
│   │   ├── routes/
│   │   │   └── products.py
│   │   └── modules/
│   │       ├── settings/
│   │       ├── db_postgres/
│   │       ├── redis/
│   │       ├── auth_core/
│   │       ├── email/
│   │       ├── cors/
│   │       ├── security_headers/
│   │       └── logging/
│   └── tests/
├── docker-compose.yml
├── Dockerfile
├── .env
└── pyproject.toml

What You Built

✅ Product CRUD API

✅ PostgreSQL database

✅ Redis caching

✅ JWT authentication

✅ Email notifications

✅ CORS protection

✅ Security headers

✅ Structured logging

✅ Docker deployment

✅ CI/CD ready

✅ Tests passing

Time spent: ~2 hours

Lines written: ~200

Lines generated: ~3,000

Key Takeaways

1. Modules are composable

rapidkit add module X
rapidkit add module Y
# They work together automatically

2. Everything is configurable
All settings via .env — no code changes needed.

3. Health checks included
Every module reports health at /health.

4. Tests included
Every module brings its own tests.

5. Standard FastAPI code
No lock-in. Modify anything. It's your code.

🧩 Explore More Modules

This tutorial used 8 modules, but RapidKit offers 27 free modules:

Authentication & Security (9):
auth_core, api_keys, oauth, passwordless, session, rbac, cors, security_headers, rate_limiting

Database & Caching (4):
db_postgres, db_mongodb, db_mysql, redis

Payments & E-commerce (3):
stripe_payment, paypal_payment, cart

Communication (2):
email, email_templates

Business (3):
storage (S3/MinIO), deployment, observability_core

Essentials (4):
settings, logging, celery, users_core

AI (1):
ai_recommender

Don't know which module?
🤖 Use AI:

npx rapidkit modules recommend "I need user authentication and email"

Read full AI guide →

🚀 Clone Example Projects

RapidKit VS Code Extension connects to real production-style workspaces:

Quickstart Product API (quickstart-workspace/product-api)
E-Commerce API (quickstart-workspace/ecommerce-api)
AI Agent Workspace (my-ai-workspace)
SaaS Starter Workspace (saas-starter-workspace)

Clone from VS Code:

Open Welcome Panel → Example Workspaces
Select workspace
Run rapidkit init && rapidkit dev

Clone from terminal:

git clone https://github.com/getrapidkit/rapidkit-examples
cd rapidkit-examples/quickstart-workspace/ecommerce-api
source .rapidkit/activate
rapidkit init
rapidkit dev

E-Commerce Flow (Visual Summary)

If you run quickstart-workspace/ecommerce-api, this is the core payment lifecycle:

stateDiagram-v2
  [*] --> Cart
  Cart --> Confirmed: POST /checkout
  Confirmed --> Paid: POST /payments/intents/{id}/confirm
  Confirmed --> Paid: webhook payment.succeeded
  Confirmed --> PaymentFailed: webhook payment.failed

And the request sequence:

sequenceDiagram
  participant C as Client
  participant A as ecommerce-api
  participant P as Payment Provider (Mock)

  C->>A: Add items to cart
  C->>A: POST /checkout
  A-->>C: order.status=confirmed

  C->>A: POST /payments/intents
  C->>A: POST /payments/intents/{id}/confirm
  A-->>C: order.status=paid

  P->>A: POST /webhooks/payments
  A-->>P: 202 accepted

What's Next?

Next: Build a NestJS microservice and see how it compares to FastAPI.

After that: New AI tracks (support triage, provider failover, cost control).

Learn More

You just built a production API.

Now ship it.

Tags:

rapidkit #fastapi #tutorial #python #backend #api #postgresql #redis #docker #beginners

Build Production SaaS: Code Walkthrough

RapidKit — Mon, 16 Feb 2026 08:18:49 +0000

Most tutorials show you how to run commands.

This one shows you how the code works.

We'll build and dissect a 4-service SaaS backend with real implementation patterns used in production.

📦 Get the code: saas-starter-workspace

What We're Building

4 microservices with clear separation:

saas-api (FastAPI) — Product API
saas-admin (FastAPI) — Admin ops
saas-nest (NestJS) — Polyglot service
saas-webhooks (FastAPI) — Billing events + replay

Key features:

Dual auth (JWT + session cookies)
Webhook signature verification
Event replay for billing corrections
DDD structure with module injection

Prerequisites

python3 --version  # 3.10+
node --version     # 20+
pip install poetry
npm install -g rapidkit
git clone https://github.com/getrapidkit/rapidkit-examples.git
cd rapidkit-examples/saas-starter-workspace

💡 Faster Setup: RapidKit VS Code Extension

Skip manual cloning. Install the RapidKit VS Code Extension:

What you get:

Clone workspaces from GitHub with one click (Welcome Page → Example Workspaces)
Download & import workspaces directly
Run/test projects from the sidebar
Install modules via GUI
Integrated terminal with RapidKit commands

Install:

code --install-extension rapidkit.rapidkit-vscode

Open Command Palette (Cmd/Ctrl+Shift+P) → RapidKit: Import Workspace → done.

Architecture Pattern: DDD with Injection Markers

Project structure:

saas-api/src/
├── main.py              # Entry point with injection markers
├── app/main.py          # FastAPI factory
├── routing/
│   └── saas.py          # Business logic (485 lines)
└── modules/free/        # RapidKit modules
    ├── auth/core/       # Password hashing + JWT
    ├── auth/session/    # Cookie sessions
    ├── users/users_core/
    └── security/rate_limiting/

Entry point pattern (main.py):

@asynccontextmanager
async def lifespan(app: FastAPI) -> AsyncIterator[None]:
    # <<<inject:startup>>> — modules add startup hooks here
    try:
        yield
    finally:
        # <<<inject:shutdown>>> — cleanup hooks
        pass

app: FastAPI = create_app(
    title="saas-api",
    lifespan=lifespan,
)
# <<<inject:routes>>> — modules mount routes here

Why this works:

Modules inject code at generation time
Clean separation of concerns
Easy to add/remove features

Code Deep Dive 1: Authentication Flow

Register endpoint (routing/saas.py):

@router.post("/auth/register", status_code=201)
async def register(
    payload: RegisterRequest,
    response: Response,
    users_service: UsersService = Depends(get_users_service),
    auth_runtime: AuthCoreRuntime = Depends(get_auth_core_runtime),
    _: Any = Depends(rate_limit_dependency()),
) -> dict[str, Any]:
    # 1. Hash password (PBKDF2, 100K iterations)
    password_hash = auth_runtime.hash_password(payload.password)

    # 2. Create user in database
    try:
        user_dto = UserCreateDTO(
            email=payload.email,
            password_hash=password_hash,
            full_name=payload.full_name,
        )
        created_user = await users_service.create_user(user_dto)
    except UserEmailConflictError:
        raise HTTPException(409, "Email already registered")

    # 3. Issue JWT token
    token_payload = {"sub": created_user.id, "email": created_user.email}
    access_token = auth_runtime.issue_token(token_payload)

    # 4. Create session + set cookie
    session_runtime = _get_session_runtime()
    session_token = session_runtime.create_session(user_id=created_user.id)
    _set_session_cookie(response, session_runtime, session_token)

    return {
        "user": created_user.model_dump(),
        "access_token": access_token,
        "token_type": "bearer",
    }

Pattern breakdown:

PBKDF2 hashing: 100K iterations prevents brute force
Service layer: Business logic isolated from HTTP
Dual auth: JWT (stateless) + session (server-side validation)
Rate limiting: Dependency injection pattern

Code Deep Dive 2: Authentication Resolution

How we resolve users from JWT OR cookies:

async def _get_current_user(
    request: Request,
    users_service: UsersService,
    auth_runtime: AuthCoreRuntime,
    session_runtime: SessionRuntime,
) -> UserDTO:
    user_id = None
    auth_header = request.headers.get("authorization")

    # Strategy 1: JWT Bearer Token
    if auth_header and auth_header.lower().startswith("bearer "):
        bearer_token = auth_header.split(" ", 1)[1]
        payload = auth_runtime.verify_token(bearer_token)
        user_id = payload.get("sub")

    # Strategy 2: Session Cookie
    else:
        session_token = request.cookies.get(session_runtime.settings.cookie.name)
        if not session_token:
            raise HTTPException(401, "Authentication required")

        session = session_runtime.verify_session_token(session_token)
        user_id = session.user_id

    # Fetch user from database
    return UserDTO.from_entity(await users_service.get_user(user_id))

Why dual auth?

Mobile apps → JWT (stateless, offline validation)
Web browsers → Cookies (server-side revocation)
Single function handles both

Usage in protected routes:

@router.get("/auth/me")
async def get_profile(
    request: Request,
    users: UsersService = Depends(get_users_service),
    auth: AuthCoreRuntime = Depends(get_auth_core_runtime),
    session: SessionRuntime = Depends(_get_session_runtime),
):
    user = await _get_current_user(request, users, auth, session)
    return {"user": user.model_dump()}

Code Deep Dive 3: Webhook Processing

Signature verification (saas-webhooks/routing/webhooks.py):

def _verify_signature(body: bytes, header: str, secret: str) -> bool:
    """Verify Stripe webhook signature using HMAC-SHA256."""

    timestamp, signature = _parse_signature_header(header)
    if not timestamp or not signature:
        return False

    # Reconstruct: "{timestamp}.{body}"
    signed_payload = f"{timestamp}.{body.decode()}"
    expected = hmac.new(
        secret.encode(),
        signed_payload.encode(),
        hashlib.sha256
    ).hexdigest()

    # Constant-time comparison (prevents timing attacks)
    return hmac.compare_digest(expected, signature)

Ingestion endpoint:

@router.post("/stripe", status_code=202)
async def receive_webhook(
    payload: StripeWebhookRequest,
    request: Request,
    background_tasks: BackgroundTasks,
):
    # 1. Verify signature
    raw_body = await request.body()
    signature = request.headers.get("stripe-signature")
    if signature and not _verify_signature(raw_body, signature, WEBHOOK_SECRET):
        raise HTTPException(400, "Invalid signature")

    # 2. Check idempotency
    if payload.id in _EVENTS:
        return {"status": "duplicate", "event_id": payload.id}

    # 3. Persist log
    _EVENTS[payload.id] = WebhookLogEntry(
        event_id=payload.id,
        event_type=payload.type,
        status="queued",
        received_at=_utc_now(),
    )

    # 4. Queue background processing
    background_tasks.add_task(_process_event, request, payload)
    return {"status": "accepted", "event_id": payload.id}

Why this pattern?

Signature first → reject fakes immediately
Idempotency → Stripe sends duplicates
Background tasks → don't block response
Logs → audit trail for billing events

Code Deep Dive 4: Webhook Replay

Critical for billing correctness:

@router.post("/replay/{event_id}")
async def replay_event(
    event_id: str,
    request: Request,
    background_tasks: BackgroundTasks,
):
    """Reprocess failed event without calling Stripe."""

    event = _EVENTS.get(event_id)
    if not event:
        raise HTTPException(404, "Event not found")

    event.replay_count += 1
    event.status = "replay_queued"

    # Reconstruct payload from stored data
    replay_payload = StripeWebhookRequest(
        id=event.event_id,
        type=event.event_type,
        data=event.metadata,
    )

    # Queue for processing
    background_tasks.add_task(_process_event, request, replay_payload)
    return {"status": "replay_accepted", "replay_count": event.replay_count}

When you need replay:

Handler had a bug → fix code, replay events
Database was down → replay after recovery
Need to backfill subscription states

Production upgrade:

Replace _EVENTS dict with PostgreSQL
Add exponential backoff for retries
Implement dead-letter queue

Code Deep Dive 5: NestJS Implementation

Auth service (saas-nest/src/auth/auth.service.ts):

@Injectable()
export class AuthService {
  private usersByEmail = new Map<string, UserRecord>();
  private tokens = new Map<string, string>();

  register(payload: { email: string; password: string }) {
    const email = payload.email.trim().toLowerCase();

    if (this.usersByEmail.has(email)) {
      throw new Error('Email already registered');
    }

    const user: UserRecord = {
      id: `user_${randomBytes(8).toString('hex')}`,
      email,
      passwordHash: this.hash(payload.password),
    };

    this.usersByEmail.set(email, user);
    const token = this.issueToken(user.id);

    return {
      user: this.publicUser(user),
      access_token: token,
      token_type: 'bearer'
    };
  }

  private hash(raw: string): string {
    return createHash('sha256').update(raw).digest('hex');
  }

  private issueToken(userId: string): string {
    const token = randomBytes(24).toString('hex');
    this.tokens.set(token, userId);
    return token;
  }
}

Controller:

@Controller('auth')
export class AuthController {
  constructor(private readonly authService: AuthService) {}

  @Post('register')
  register(@Body() payload: { email: string; password: string }) {
    try {
      return this.authService.register(payload);
    } catch (error) {
      throw new HttpException(error.message, HttpStatus.CONFLICT);
    }
  }

  @Get('me')
  me(@Headers('authorization') authorization?: string) {
    const token = extractBearer(authorization);
    if (!token) {
      throw new HttpException('Auth required', HttpStatus.UNAUTHORIZED);
    }
    return this.authService.me(token);
  }
}

Comparison with FastAPI version:

Same flow: hash → store → issue token
NestJS: TypeScript types + dependency injection
FastAPI: Async/await + Pydantic validation
Both: Service pattern isolates business logic

Run the Complete System

Terminal 1 — Product API:

cd saas-api && poetry shell && rapidkit init && rapidkit dev
# → http://127.0.0.1:8000

Terminal 2 — Admin API:

cd saas-admin && poetry shell && rapidkit init && rapidkit dev --port 8001
# → http://127.0.0.1:8001

Terminal 3 — NestJS:

cd saas-nest && npm install && rapidkit init && rapidkit dev --port 8002
# → http://127.0.0.1:8002

Terminal 4 — Webhooks:

cd saas-webhooks && poetry shell && rapidkit init && rapidkit dev --port 8003
# → http://127.0.0.1:8003

Test the Implementation

Auth flow:

import requests

# Register
r = requests.post('http://127.0.0.1:8000/api/auth/register', json={
    'email': 'dev@example.com',
    'password': 'SecurePass123!',
})
token = r.json()['access_token']

# Get profile
headers = {'Authorization': f'Bearer {token}'}
me = requests.get('http://127.0.0.1:8000/api/auth/me', headers=headers)
print(me.json())

Webhook flow:

# Send event
curl -X POST http://127.0.0.1:8003/api/webhooks/stripe \
  -H 'Content-Type: application/json' \
  -d '{"id":"evt_test","type":"customer.subscription.updated","data":{}}'

# View logs
curl http://127.0.0.1:8003/api/webhooks/logs | jq

# Replay
curl -X POST http://127.0.0.1:8003/api/webhooks/replay/evt_test

Key Patterns You Learned

1. Injection Marker System

# <<<inject:startup>>> — modules contribute code here
# <<<inject:routes>>> — dynamic route mounting

2. Service Layer Pattern

# Controller → calls → Service → calls → Repository
# Keeps business logic testable and framework-independent

3. Dependency Injection

async def endpoint(
    service: Service = Depends(get_service),
    auth: Auth = Depends(get_auth),
):
    # FastAPI resolves dependencies automatically

4. Background Processing

background_tasks.add_task(process_event, payload)
return {"status": "accepted"}  # Immediate response

5. Dual Authentication

# Check Bearer token first, fall back to session cookie
# Enables mobile (JWT) + web (session) clients

Production Hardening

Before going live:

1. Replace in-memory storage:

# Current: _EVENTS = {}
# Production: PostgreSQL with SQLAlchemy

2. Add retry logic:

for attempt in range(max_retries):
    try:
        await process()
        break
    except Exception:
        await asyncio.sleep(2 ** attempt)

3. Implement dead-letter queue:

if attempts >= max_retries:
    await send_to_dlq(event)

4. Add observability:

Structured logging with request IDs
APM (Sentry/DataDog)
Prometheus metrics

What You Built

✅ Multi-service architecture (4 services, independent scaling)

✅ Dual authentication (JWT + session cookies)

✅ Secure webhooks (signature verification + replay)

✅ DDD structure (clean separation of concerns)

✅ Polyglot support (FastAPI + NestJS coexist)

✅ Production patterns (background tasks, rate limiting, error handling)

This is the foundation real SaaS companies use to process millions in ARR.

Next Steps

Want Part 2 - Production Deployment?

Docker Compose orchestration
PostgreSQL + Redis setup
CI/CD with GitHub Actions
Kubernetes manifests
Secrets management

Drop a comment if interested 👇

Resources:

Found this useful? Follow for more production engineering patterns.

The Hidden Cost of Backend Boilerplate (And How to Eliminate It)

RapidKit — Sun, 15 Feb 2026 07:39:17 +0000

Everyone Counts the Same Cost

Ask any backend developer:

"How long to start a new API project?"

Answer:
"30 minutes with a template."

"A few hours from scratch."

But that's not the real cost.

That's just Day 1.

The Real Cost Shows Up Later

Let me show you what actually happens.

Week 1: The Setup

You start a new FastAPI project.

You copy your "starter template":
• Project structure
• Docker configs
• CI/CD workflows
• Auth boilerplate
• Database setup
• Logging config

Time: 2 hours (not bad!)

What you don't notice:
• JWT v1 from 6 months ago (now there's v2)
• Database pool settings from different project
• Logging format doesn't match team's new standard
• Docker compose has hardcoded values from old project

Cost so far: 2 hours + unknown future bugs

Week 3: The Divergence

Your teammate starts another project.

They copy YOUR template.

But make "improvements":
• Different folder structure (src/ vs app/)
• Different error handling
• Different env variable naming
• Updated packages (breaking changes!)

Problem:

Now you have two projects that look similar but work differently.

When you fix a bug in Project A, do you remember to fix it in Project B?

Cost: Code duplication + inconsistency tax

Month 2: The Onboarding

A new developer joins.

You: "Just look at user-api to understand our structure."

New Dev: (Looks at user-api, then payment-api)

New Dev: "These structure auth differently. Which is correct?"

You: "Uh... let me check."

Cost: Confusion + lost productivity + rework

Month 4: The Maintenance Nightmare

You discover a security issue in auth logic.

Question: Which projects have this issue?

Answer:

Search codebase (30 minutes)
Find 6 projects with copied auth
Each has slightly different implementation
Fix takes 4 hours (not 30 minutes)

Cost: 4+ hours + risk you missed one

Month 6: The "Which Version?" Problem

You have 8 APIs now:
• 3 use Pydantic v1
• 4 use Pydantic v2
• 1 nobody knows

Why?

Templates capture a snapshot in time.

They don't evolve.

Each copy drifts further from the source.

The Hidden Costs (Quantified)

Setup cost (what you measure):
• Template: 2 hours
• From scratch: 6 hours

Drift cost (what you miss):
• Fixing bugs across 8 copies: 4 hours × 8 = 32 hours
• Onboarding confusion: 2 hours per developer × 5 devs = 10 hours
• "Which version?" debugging: 6 hours
• Architectural inconsistency: Ongoing pain

Real cost:
• Initial: 2 hours
• Ongoing: 48+ hours over 6 months

That's 24× the initial cost.

The Problem Isn't Templates

Templates are great for:
• UI components
• Boilerplate-free tools (like Swagger)
• One-time setups

Templates fail for:
• Evolving codebases
• Team consistency
• Bug fixes and updates
• Architectural standards

Because once you copy a template, you're on your own.

What If You Could Eliminate Drift?

Imagine:

Create a project
A bug is found in auth logic
One command updates all projects
No searching, no manual fixes

This is what RapidKit modules solve.

How RapidKit Changes This

Traditional approach:

# Copy template
cp -r starter-template/ new-api/
cd new-api

# Modify everything
# (Hope you remember what to change)

# 6 months later: bug found in auth
# Fix manually in 8 projects

RapidKit approach:

# Create project
rapidkit create project fastapi.standard new-api
cd new-api

# Add modules
rapidkit add module auth_core
rapidkit add module db_postgres
rapidkit add module logging

# 6 months later: auth bug fixed in module
rapidkit upgrade
# ↳ Fixed across all projects

The Difference: Managed vs Copied

Templates:
• Copied code
• No connection to source
• Manual updates
• Drift inevitable

RapidKit Modules:
• Versioned modules
• Tracked installations
• Automatic updates
• Consistency enforced

Think:
• Templates = copy-paste code
• Modules = npm packages for backend

Real Example: Auth Bug Fix

Scenario: Security vulnerability in JWT validation

Template approach:

Identify affected projects (30 min)
Fix project 1 (30 min)
Fix project 2 (30 min)
Fix project 3 (30 min)
...repeat for 8 projects
Test each (2 hours)

Total: 6+ hours

RapidKit approach:

Fix auth_core module
Release v0.1.5
Run in each project:

   rapidkit upgrade

Module updates automatically

Total: 30 minutes

Saved: 5.5 hours (per bug!)

The Compounding Effect

After 1 year:
• 12 bug fixes in shared modules
• 5.5 hours saved × 12 = 66 hours saved

After 2 years:
• 24 bug fixes
• 132 hours saved

Plus:
• Zero onboarding confusion
• Zero "which version?" problems
• Zero architectural drift

But Isn't This Lock-In?

No.

RapidKit generates standard FastAPI/NestJS code.

You can:
• Modify any file
• Remove RapidKit entirely
• Continue without it

You own the code.

RapidKit just manages the boring parts.

What About Customization?

Templates: Everything is customizable (because everything is yours)

RapidKit: Everything is customizable too:

Modify generated code
RapidKit tracks your changes
When upgrading, it: • Shows diffs • Preserves your customizations • Merges updates safely

Best of both worlds:
• Evolution without drift
• Customization without chaos

The Mental Model Shift

Old way:
"Copy this template and make it yours."

New way:
"Install these modules and add your features."

Old way: Start by deleting/modifying

New way: Start by building features

Try It Yourself

Create two projects with templates:

# Project 1
cp -r template/ api-1/
cd api-1
# Spend 2 hours customizing

# Project 2
cp -r template/ api-2/
cd api-2
# Spend 2 hours customizing

# 3 months later: find a bug in template
# Now fix it manually in both

Create two projects with RapidKit:

# Project 1
rapidkit create project fastapi.standard api-1
cd api-1
rapidkit add module auth_core db_postgres

# Project 2
rapidkit create project fastapi.standard api-2
cd api-2
rapidkit add module auth_core db_postgres

# 3 months later: bug fixed in auth_core
cd api-1 && rapidkit upgrade
cd api-2 && rapidkit upgrade
# Done.

The Real Cost of Boilerplate

It's not the initial setup time.

It's:
• Drift (projects become inconsistent)
• Duplication (fix same bugs multiple times)
• Confusion (teammates don't know which is canonical)
• Maintenance (updates take forever)
• Onboarding (new devs lost in inconsistency)

RapidKit eliminates all of these.

What's Next?

Next article: "Your First FastAPI Project with RapidKit" — a complete tutorial building a real API.

Learn More

Stop copying templates.

Start managing modules.

From Zero to Production API in 5 Minutes

RapidKit — Sat, 14 Feb 2026 20:04:33 +0000

Let's Stop Talking. Let's Build.

Enough theory. We're building a real, production-ready FastAPI project from absolute zero.

Not a toy example. Not a template.

Timer starts now. ⏱️

📌 Source Code: github.com/getrapidkit/rapidkit-examples/tree/main/quickstart-workspace

Minute 0:00 — Prerequisites Check

You need:
• Node.js 20+
• Python 3.10+
• 5 minutes

That's it.

RapidKit handles:
• Poetry (auto-installed)
• Docker (configs provided)
• Dependencies (auto-managed)

Minute 0:30 — Create the Workspace

Workspace-based approach (recommended for multiple projects):

npx rapidkit quickstart-workspace
cd quickstart-workspace
npx rapidkit create project fastapi.standard product-api
cd product-api

What you get:
• Clean src/ architecture
• Health check endpoint
• Docker & docker-compose ready
• CI/CD templates (GitHub Actions)
• Testing setup (pytest)
• Environment management (.env.example)
• Makefile for common tasks
• Shared .venv for all workspace projects

Generated code, not templates.

Minute 1:00 — Install Dependencies

# Activate workspace environment
source .rapidkit/activate

# Initialize project
rapidkit init

What happens:

Detects workspace environment
Installs Poetry (if needed)
Uses shared workspace .venv/
Installs all project dependencies
Sets up pre-commit hooks

Output:

✓ Poetry detected
✓ Using workspace virtualenv
✓ Installing dependencies
✓ Project ready!

Minute 1:30 — First Run

rapidkit dev

Output:

INFO: Uvicorn running on http://127.0.0.1:8000
INFO: Application startup complete.

Open browser: http://localhost:8000/docs

You see Swagger UI with health endpoints:
• GET /health — Overall health check
• GET /api/health/livez — Liveness probe
• GET /api/health/readyz — Readiness probe

Your API is running.

Minute 2:00 — Add Essential Modules

rapidkit add module settings
rapidkit add module auth_core  
rapidkit add module logging

Settings module:
• Multi-source config (.env, env vars, YAML)
• Type-safe with Pydantic
• Environment-specific overrides

Auth Core module:
• PBKDF2 password hashing
• HMAC token signing
• Secure credential management

Logging module:
• Structured JSON logs
• Request/correlation tracking
• Configurable log levels

Check health endpoints:

{
  "status": "healthy",
  "timestamp": "2026-02-14T...",
  "modules": {
    "auth_core": "healthy",
    "settings": "healthy"
  }
}

Minute 2:30 — Add Database

rapidkit add module db_postgres

What you get:
• Async & sync SQLAlchemy engines
• Connection pooling with configurable limits
• Health checks with connection testing
• Alembic migrations ready
• Docker Compose with Postgres service

Environment configured in .env:

RAPIDKIT_DB_POSTGRES_URL=postgresql://postgres:postgres@localhost:5432/app_db
RAPIDKIT_DB_POSTGRES_TEST_URL=postgresql://postgres:postgres@localhost:5433/app_db_test
RAPIDKIT_DB_POSTGRES_POOL_SIZE=10
RAPIDKIT_DB_POSTGRES_MAX_OVERFLOW=20

Start database:

docker-compose up -d postgres

Check health:
http://localhost:8000/api/health/module/postgres


---

## Minute 3:00 — Add Redis Caching

bash
rapidkit add module redis


**Redis features:**
• Async Redis client with connection pooling
• Automatic retry logic with exponential backoff
• Health monitoring with connection testing
• Configurable TTL and preconnection

**Environment configured in `.env`:**

bash
REDIS_URL=redis://localhost:6379/0
REDIS_HOST=localhost
REDIS_PORT=6379
REDIS_DB=0
CACHE_TTL=3600
REDIS_CONNECT_RETRIES=3


**Start Redis:**

bash
docker-compose up -d redis


**Check health:**
http://localhost:8000/api/health/module/redis

---

## Minute 3:30 — Add Security & Middleware

bash
rapidkit add module cors
rapidkit add module security_headers
rapidkit add module middleware


**CORS:**
• Whitelist origins for production
• Credential support enabled
• Preflight request handling

**Security Headers:**
• CSP, HSTS, X-Frame-Options configured
• Production-ready secure defaults

**Middleware:**
• Request ID tracking
• Response time recording
• Custom middleware support

**Your API now has enterprise-grade security.**

---

## Minute 4:00 — Add Deployment Config

bash
rapidkit add module deployment


**Deployment features:**
• Production-ready Dockerfile (multi-stage builds)
• Docker Compose with all services
• GitHub Actions CI/CD workflows
• Makefile with common tasks
• Health check integration
• Environment-based configuration

---

## Minute 4:30 — Run Tests

bash
rapidkit test


**Output:**

===== test session starts =====
collected 15 items

tests/test_health.py ✓✓✓✓
tests/test_auth_core.py ✓✓✓
tests/test_db.py ✓✓✓✓
tests/test_redis.py ✓✓
tests/test_integration.py ✓✓

===== 15 passed in 3.2s =====


**All modules have tests included automatically.**

---

## Minute 5:00 — Deploy

**Using Makefile commands:**

bash

Build Docker image

make docker-build

Run with docker-compose (all services)

make docker-up

Or manual Docker build

docker build -t product-api .
docker run -p 8000:8000 --env-file .env product-api


**Production deployment:**
• GitHub Actions workflows (auto-generated by deployment module)
• Multi-stage Dockerfile (optimized for production)
• Docker Compose with all services
• Health checks integrated
• Environment-based configuration

**Your API is production-ready.**

---

## ⏱️ Timer: 5:00

**What you built:**
✅ Workspace-based FastAPI project with clean architecture  
✅ JWT Authentication (register, login, refresh)  
✅ Database (PostgreSQL with async + sync engines)  
✅ Caching (Redis with retry logic)  
✅ Security (CORS + security headers)  
✅ Middleware (request tracking)  
✅ Logging (structured JSON with correlation IDs)  
✅ Configuration (multi-source with type safety)  
✅ Tests (passing with 15 test cases)  
✅ Docker (production-ready multi-stage builds)  
✅ CI/CD (GitHub Actions workflows)

**Lines of code written by you:** ~60 (configs)  
**Lines of code generated:** ~2,500+

---

## Project Structure

quickstart-workspace/
├── .rapidkit/
│ ├── activate # Workspace activation script
│ └── .venv/ # Shared virtual environment
├── product-api/
│ ├── src/
│ │ ├── main.py # FastAPI app entrypoint
│ │ ├── cli.py # CLI commands
│ │ ├── health/ # Health check routes
│ │ ├── routing/ # API routes
│ │ └── modules/ # Installed modules
│ │ ├── settings/
│ │ ├── auth_core/
│ │ ├── db_postgres/
│ │ ├── redis/
│ │ ├── cors/
│ │ ├── security_headers/
│ │ ├── logging/
│ │ ├── deployment/
│ │ └── middleware/
│ ├── tests/ # Tests for all modules
│ ├── docker-compose.yml # Postgres + Redis services
│ ├── Dockerfile # Production multi-stage image
│ ├── pyproject.toml # Project dependencies
│ ├── .env.example # Environment template
│ └── Makefile # Common development tasks
└── README.md # Workspace documentation


**Every module:**
• Has its own directory
• Brings tests
• Updates health endpoint
• Configurable via `.env`

---

## What Makes This Different?

**Templates give you:**
• Example files
• You modify everything
• No upgrade path

**RapidKit gives you:**
• Production code
• Working integrations
• Upgradable modules
• Health checks included
• Tests included

**Key difference:**

Templates = **delete and modify**  
RapidKit = **add and build**

---

## Next Steps

**Add more features:**

bash

Email sending

rapidkit add module email

Background tasks

rapidkit add module celery

File storage

rapidkit add module storage

Observability

rapidkit add module observability_core


**Each module integrates cleanly** — working together seamlessly.

---

## Troubleshooting: Health Check

**Something not working?**

bash
npx rapidkit doctor


**Checks:**
• Python version
• Poetry installation
• RapidKit Core version
• Dependencies status

**Example output:**

✅ Python: Python 3.10.19
✅ Poetry: Poetry 2.3.2
✅ pipx: pipx 1.8.0
✅ RapidKit Core: RapidKit Core 0.3.2
• Global (pipx): /home/user/.local/bin/rapidkit -> 0.3.2

✅ All required tools are installed!


**Instant diagnosis.** For detailed project checks, use `rapidkit doctor --workspace`.

---

## Try It Yourself

**Clone the example:**

bash
git clone https://github.com/getrapidkit/rapidkit-examples.git
cd rapidkit-examples/quickstart-workspace/product-api
source ../.rapidkit/activate
rapidkit init
rapidkit dev


**Or create from scratch:**

bash
time npx rapidkit create workspace my-workspace
cd my-workspace
time npx rapidkit create project fastapi.standard my-api
cd my-api
source ../.rapidkit/activate
time rapidkit init
time rapidkit dev




**Challenge:** Can you beat 5 minutes?

---

## FAQs

**Q: Is this production-ready?**  
Yes. Companies use generated projects in production.

**Q: Can I customize the code?**  
Yes. It's your code. Modify anything. RapidKit tracks changes and helps merge updates.

**Q: What if I add a module later?**  
RapidKit integrates it cleanly, preserving your custom code.

**Q: Do I need to learn RapidKit patterns?**  
No. It's **standard FastAPI code**. If you know FastAPI, you know this code.

---

## What's Next?

Next article: **"The Hidden Cost of Backend Boilerplate"** — why "just use a template" isn't good enough.

---

### Learn More

* 🌐 [getrapidkit.com](https://www.getrapidkit.com)
* 📦 [npm: rapidkit](https://www.npmjs.com/package/rapidkit)
* 🐍 [PyPI: rapidkit-core](https://pypi.org/project/rapidkit-core/)
* 🧩 [VS Code Extension](https://marketplace.visualstudio.com/items?itemName=rapidkit.rapidkit-vscode)
* 📂 [GitHub: rapidkit-examples](https://github.com/getrapidkit/rapidkit-examples)

---

**You just built a production-ready API in 5 minutes.**

Now go ship something.

DEV Community: RapidKit

I Spent 45 Minutes Setting Up a Backend… Before Writing a Single Line of Logic

We don’t have a coding problem

The “Context Gap”

I tried a different approach

What changed

1. No more blind debugging

2. Scaffolding that respects architecture

3. Change impact awareness

4. Debugging with context

The shift we’re ignoring

Curious how others deal with this

The Best AI Feature for Backend Developers Is a Resolution Loop

Why backend work needs more than chat

The killer features only make sense as a connected system

1. Terminal bridge

2. Change impact before fix

3. Fix preview before apply

4. Verification after action

5. Workspace memory

What makes this stronger than a generic assistant

Product takeaway

Closing

Why Do Backend Teams Need a Workspace-Based AI Layer?

Why Do Backend Teams Need a Workspace-Based AI Layer?

Why file-level AI breaks down so quickly in backend development

What the workspace-based model changes for users

1. The non-AI workspace platform features

Workspace Explorer

Project Scaffolding

Module System

Health Doctor

Dev Server Control

Workspace Dashboard

2. The current AI feature surface

AI Create

Project Assistant

Workspace Brain

@workspai in Chat

AI Debug Actions

Doctor Fix with AI

Fix Preview Lite

Change Impact Lite

Terminal → AI Bridge

Workspace Memory

Memory Wizard

AI Recipe Packs

Module Advisor

Telemetry Insights

3. The upcoming Pro and Team layer

Module Generator (Pro)

AI Debugger (Advanced) (Pro)

Test Generator (Pro)

DevOps Assistant (Pro)

Architecture Advisor (Pro)

Team AI Memory (Team)

Why backend teams need this architecture, not just better prompts

1. Less context re-explaining

2. Better backend-specific answers

3. More trust in real workflows

Closing

Backend AI Needs an Action Surface, Not Just a Chat Box

The problem with chat-first AI in backend work

What changed in Workspai v0.21.0

Why small AI actions matter

1. Terminal Output Analysis

2. Fix Preview Lite

3. Change Impact Lite

4. Smart Route

5. Workspace Memory Wizard

6. Recipe Packs

Telemetry is not just analytics vanity

Reliability work matters as much as visible features

The bigger product direction

Closing

AI Coding Tools Have a Context Problem — Here's the Fix

The Wrong Unit of Context

What a Backend AI Actually Needs

The Workspace as Context Unit

Why the Workspace Format Matters

`@workspai` in Chat