Forem: RapidKit

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.

Workspace-First Development: Why It Changes Everything

RapidKit — Sat, 14 Feb 2026 18:57:40 +0000

The Problem Nobody Talks About

You're building a modern backend. Not one API. Several:

Authentication service
User management API
Payment gateway
Notification service

Microservices done right?

Then why does it feel so painful?

The Hidden Tax of Multiple Services

Day 1: Create first service (3 hours)

Day 3: Copy-paste for second service → already diverging

Week 2: 4 services with different structures

Month 2: New developer: "Which service is the reference?"

The real problems:

4 separate virtualenvs (600MB each = 2.4GB)
Inconsistent structure across services
Version conflicts (Pydantic v1 or v2?)
20-step onboarding guide

This is what workspaces solve.

What Is a Workspace?

A shared environment for multiple backend projects.

my-workspace/
├── .venv/                     # Shared Python env
├── auth-service/              # FastAPI
├── user-api/                  # FastAPI
├── payment-gateway/           # NestJS
└── notification-service/      # FastAPI

Create it:

npx rapidkit my-workspace
cd my-workspace

Add projects:

rapidkit create project fastapi.standard auth-service
rapidkit create project nestjs.standard payment-gateway

Benefits:

One Python environment for all projects
Consistent structure
One CLI for everything
Auto-tracked registry

Why This Matters: Real Numbers

Traditional Approach (4 services):

Setup: 3 hours × 4 = 12 hours
Disk: 600MB × 4 = 2.4GB
Onboarding: 4-6 hours reading docs

Workspace Approach:

Setup: 5 minutes (workspace) + 2 minutes × 4 = 13 minutes
Disk: 150MB (shared) + 400MB (projects) = 550MB
Onboarding: 2 minutes (clone + ./bootstrap.sh)

Workspace saves you: 77% time, 77% disk space

How It Works: The Magic of Shared Environments

Create workspace:

npx rapidkit my-workspace
cd my-workspace

Behind the scenes:

Creates .rapidkit-workspace marker
Installs Poetry
Creates shared .venv/
Installs rapidkit-core (the Python engine)
Registers workspace in ~/.rapidkit/workspaces.json

Add projects:

rapidkit create project fastapi.standard api-one
rapidkit create project nestjs.standard api-two

Each project gets:

Own .venv/ for project dependencies (~100MB)
Access to workspace's rapidkit-core
Consistent structure
Independent configs

Command routing:

# Inside workspace:
rapidkit --version
# ↳ Uses workspace .venv/bin/rapidkit

# Inside project:
rapidkit dev
# ↳ Launches project's FastAPI/NestJS server

# Outside workspace:
npx rapidkit dev
# ↳ Uses npm bridge

Three Ways to Start

1️⃣ Workspace (Recommended)

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

Pros: Auto prerequisites, multi-project, disk efficient

Use when: 2+ projects, team development, production

2️⃣ Direct Project

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

Pros: Fastest for single project

Use when: Quick prototype, learning

3️⃣ VS Code Extension

Install extension
Ctrl+Shift+P → "RapidKit: Create Workspace"
Visual project creation

Pros: GUI, visual discovery

Use when: New to RapidKit, team onboarding

💾 Export Your Workspace: Share & Backup

Export:

rapidkit workspace export
# or: Right-click workspace in VS Code → Export

Result: ZIP file (1-10MB) with:

All projects + configs
Poetry lockfile
Smart exclusions (no node_modules, .venv)

Import:

# Extract ZIP
./bootstrap.sh
# Done in 2 minutes

Use cases:

Team onboarding: Share entire backend in one file
Disaster recovery: Restore from backup
Experimentation: Export before refactor

Traditional onboarding: 4+ hours

Workspace import: 2 minutes ✅

🩺 Workspace Health & Upgrades

Check health:

rapidkit doctor

Output:

✅ Python 3.11.5
✅ Poetry 1.7.0
✅ RapidKit Core v0.11.0
✅ 4 projects registered
⚠️  auth-service: missing dependencies

Check updates:

rapidkit check updates

VS Code shows orange "Upgrade Available" button when new version is released.

Real Example: SaaS Backend

Create workspace:

npx rapidkit saas-backend
cd saas-backend

Add services:

rapidkit create project fastapi.ddd auth-service
rapidkit create project nestjs.standard api-gateway
rapidkit create project fastapi.standard jobs-service

VS Code sidebar:

📁 SaaS Backend
 ├── 🐍 auth-service
 ├── 🟦 api-gateway
 └── 🐍 jobs-service

One click to:

Start any service
Run tests
Install modules
Check health

Developer Experience Benefits

1. Instant Discoverability

git clone company/backend-workspace
cd backend-workspace
code .

New developer sees all services, identical structure, ready to run.

2. Consistent Commands

cd auth-service
rapidkit dev

cd ../api-gateway
rapidkit dev      # Same command, different framework

3. Shared Updates

cd auth-service
rapidkit add module logging

cd ../api-gateway
rapidkit add module logging   # Same version, instant

Workspace Strategies

1. Monolithic (all projects):

company-backend/
├── auth-service/
├── user-api/
├── payment-api/
└── 10 more services/

2. Domain-Separated (recommended):

company-auth/          # Workspace
├── auth-service/
└── user-api/

company-payments/      # Workspace
├── payment-api/
└── billing-service/

3. Hybrid:

core-platform/         # Workspace for core services
├── auth/
├── users/
└── payments/

tools/                 # Standalone utilities
├── migration-script/
└── data-import/

When NOT to Use Workspaces

Use standalone when:

Single quick prototype
Learning RapidKit
Unrelated projects
Maximum control needed

Use workspace when:

2+ related projects
Team development
Production environments
Consistent architecture matters

The Hidden Superpower: Team Onboarding

Traditional:

Clone repos (4+)
Read 10-page guide
Install Python, Node, Docker, Poetry
Create virtualenvs
Configure .env files
Fix dependency conflicts
Debug for 2 hours

Time: 4-6 hours

Workspace:

Download ZIP
Extract
Run ./bootstrap.sh

Time: 2 minutes

Everything works. No questions. No debugging.

This Changes How Teams Collaborate

Before workspaces:

"Works on my machine"
Week-long onboarding
Inconsistent structures
Version conflicts

With workspaces:

Identical environments
2-minute onboarding
Enforced consistency
One source of truth

Try It Yourself

# Create workspace
npx rapidkit demo-workspace
cd demo-workspace

# Add two projects
rapidkit create project fastapi.standard api-one
rapidkit create project nestjs.standard api-two

# Open in VS Code
code .

Explore:

Sidebar shows both projects
Health check (pulse icon)
Install modules visually
See tracking in action

Comparison: Workspace vs Direct

Feature	Workspace	Direct
Prerequisites	✅ Auto	⚠️ Manual
Multi-Project	✅ Excellent	❌ No
Disk Usage	✅ Efficient	⚠️ Wasteful
Setup Time	🟢 Fast	🟡 Slow
Team-Friendly	✅ Yes	⚠️ Moderate
Learning Curve	🟢 Easy	🟡 Medium

Rule of thumb:

2+ related projects → Workspace
Single prototype → Direct
Not sure? → Workspace (you can ignore it)

What's Next?

Next article: "From Zero to Production API in 5 Minutes" — we build a real deployable API with timer running.

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

Learn More

Build Your First AI Agent with NestJS + RapidKit in 10 Minutes

RapidKit — Thu, 12 Feb 2026 12:16:50 +0000

Adding AI features to NestJS usually takes much longer than it should.

With RapidKit, you can scaffold a production-style AI assistant module in minutes.

What You Build

AI assistant endpoints in NestJS
Provider abstraction (echo by default)
Optional OpenAI provider via environment
Completion + stream APIs
Support ticket endpoint with urgency classification
Health + Swagger visibility

Source code: https://github.com/getrapidkit/rapidkit-examples/tree/main/my-ai-workspace/ai-agent-nest

Prerequisites

Node.js 20+
npm 10+
Python 3.10+

1) Create workspace and project

npx rapidkit my-ai-workspace
cd my-ai-workspace
rapidkit create project nestjs.standard ai-agent-nest
cd ai-agent-nest
rapidkit init

2) Add AI Assistant module

npx rapidkit add module ai_assistant

This generates:

src/modules/free/ai/ai_assistant/ai_assistant.module.ts
src/modules/free/ai/ai_assistant/ai_assistant.controller.ts
src/modules/free/ai/ai_assistant/ai_assistant.service.ts
src/modules/free/ai/ai_assistant/ai_assistant.validation.ts

3) Register module in `src/modules/index.ts`

For latest ai_assistant module versions this is injected automatically.
If you use an older generated project and routes are missing, add this entry to optionalModules:

registerOptionalModule(() => require('./free/ai/ai_assistant').AiAssistantModule as ModuleRef),

4) Run app

PORT=8013 npm run start:dev

or via RapidKit wrapper:

rapidkit dev -p 8013

To auto-register OpenAI provider:

OPENAI_API_KEY=your_key PORT=8013 npm run start:dev

5) Verify endpoints

curl http://127.0.0.1:8013/health
curl http://127.0.0.1:8013/ai/assistant/providers
curl http://127.0.0.1:8013/ai/assistant/health

Providers response:

["echo"]

Completion test:

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

Example response:

{
  "provider": "echo",
  "content": "[echo] What is RapidKit?",
  "latencyMs": 0,
  "cached": false
}

Stream test:

curl -X POST http://127.0.0.1:8013/ai/assistant/stream \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Give me a deployment checklist","provider":"echo"}'

Cache clear:

curl -X DELETE http://127.0.0.1:8013/ai/assistant/cache

Support ticket parity endpoint:

curl -X POST http://127.0.0.1:8013/support/ticket \
  -H "Content-Type: application/json" \
  -d '{"message":"Customer cannot complete payment"}'

Example response:

{
  "ticket_id": "TKT-12345",
  "urgency": "high",
  "ai_response": "[echo] Customer cannot complete payment",
  "latency_ms": 0,
  "next_action": "escalate",
  "provider": "echo"
}

6) Open API docs

http://127.0.0.1:8013/docs

Why this setup is useful

Fast baseline for real backend teams
Clear module boundaries for scaling
Easy to swap provider strategy later

FastAPI parity now exists in this example for the support-ticket flow and optional OpenAI path.

If you want, next step is adding OpenAI provider + retry/fallback in this same NestJS codebase.

Workspace-First Development: Why It Changes Everything

RapidKit — Wed, 11 Feb 2026 20:39:31 +0000

The Problem Nobody Talks About

You're building a modern backend.

Not one API. Several.

An authentication service
A user management API
A payment gateway
A notification service
Maybe a few more

Each service is small. Each service is focused.

That's microservices done right, right?

Then why does it feel so painful?

The Hidden Tax of Multiple Services

Here's what actually happens:

Day 1: Create the first service

30 minutes to set up the project
1 hour to configure Docker and CI
2 hours to wire up auth, database, logging
Finally start coding features

Day 3: Need a second service

Copy the first project as a template
Change names, ports, configs
Fix inconsistencies from the copy-paste
Realize you're already diverging from the first service

Week 2: Now you have 4 services

Each has a slightly different structure
Each has its own Python virtualenv (600MB each)
Each has its own dependencies (and version conflicts)
Each has its own way of doing logging, error handling, and config

Month 2: A new developer joins

"Which service should I look at as reference?"
"Why do these three services structure models differently?"
"Do we use Pydantic v1 or v2?"
"Which .env file is the source of truth?"

This Is What "Consistency at Scale" Really Means

It's not about code style.
It's not about linting rules.

It's about:

Structure: Every service follows the same architecture
Tooling: One environment, one CLI, one workflow
Dependencies: Shared Python environment across all services
Discovery: Every service is automatically tracked and accessible

This is what RapidKit Workspaces solve.

What Is a Workspace?

A workspace is a shared environment for multiple backend projects.

Think of it like a monorepo, but:

Each project is independent (no forced sharing)
Each project can use FastAPI or NestJS (or both)
One Python environment powers all Python projects
All projects are auto-tracked in a registry

In practice:

my-workspace/
├── .rapidkit-workspace        # Workspace marker
├── .venv/                     # Shared Python environment
├── poetry.lock                # Locked dependencies
├── auth-service/              # FastAPI project
├── user-api/                  # FastAPI project
├── payment-gateway/           # NestJS project
└── notification-service/      # FastAPI project

One command to create it:

npx rapidkit my-workspace
cd my-workspace

One command to add projects:

rapidkit create project fastapi.standard auth-service
rapidkit create project nestjs.standard payment-gateway

Result:

All FastAPI projects share the same .venv (~150MB once, not 600MB four times)
All projects are tracked in ~/.rapidkit/workspaces.json
VS Code extension auto-discovers everything
RapidKit Core version is consistent across all projects

Why This Matters: Real Numbers

Scenario: You're building 5 microservices for a SaaS app.

Without Workspaces (Traditional Approach)

5 separate virtualenvs: ~750MB of duplicated Python packages
5 independent setups: ~30 minutes × 5 = 2.5 hours
5 different dependency versions: Debugging nightmare
No central tracking: Manual documentation required
Onboarding time: 3-4 days for a new developer

With Workspaces (RapidKit Approach)

1 shared virtualenv: ~150MB total
1 workspace setup: ~2 minutes
Consistent dependencies: One poetry.lock for all Python projects
Auto-tracked registry: VS Code shows all projects instantly
Onboarding time: 1 day (open workspace, see everything)

Savings:

600MB disk space
2+ hours of setup time
Countless hours of debugging version conflicts
2-3 days of onboarding per developer

How It Works: The Magic of Shared Environments

When you create a workspace, RapidKit:

Creates a Poetry-managed Python environment

   .venv/
   ├── bin/
   │   ├── python3
   │   ├── rapidkit   # CLI available globally in workspace
   │   └── ...
   ├── lib/
   │   └── python3.11/site-packages/
   │       └── rapidkit_core/   # Shared engine

Installs RapidKit Core once

   poetry add rapidkit-core

Provides activation scripts

   source "$(poetry env info --path)/bin/activate"

Tracks everything in a registry

   // ~/.rapidkit/workspaces.json
   {
     "workspaces": [
       {
         "name": "my-workspace",
         "path": "/home/user/my-workspace",
         "projects": [
           {"name": "auth-service", "framework": "fastapi"},
           {"name": "user-api", "framework": "fastapi"},
           {"name": "payment-gateway", "framework": "nestjs"}
         ]
       }
     ]
   }

Every tool reads this registry:

VS Code extension shows your workspaces in the sidebar
CLI knows which projects exist
Commands auto-complete project names

Under the Hood: How Workspace Environments Work

Understanding workspace mechanics helps you make the right choice.

The Isolation Model

When you run npx rapidkit my-workspace:

my-workspace/
├── .venv/                    # Workspace virtualenv (Poetry-managed)
│   ├── bin/
│   │   ├── python3          # Python interpreter
│   │   ├── poetry           # Poetry CLI
│   │   └── rapidkit         # RapidKit Core CLI
│   └── lib/
│       └── python3.10/site-packages/
│           └── rapidkit_core/   # Core engine installed here
├── pyproject.toml            # Workspace Poetry config
├── poetry.lock               # Locked Core version
└── README.md

# After creating projects:
my-workspace/
├── .venv/                    # Workspace env (shared Core)
├── auth-service/
│   └── .venv/               # Project env (project deps only)
├── user-service/
│   └── .venv/               # Project env (project deps only)
└── payment-service/
    └── .venv/               # Project env (project deps only)

Key Benefits of This Architecture

1. Command Resolution:

# Inside workspace (any subdirectory)
$ rapidkit create project fastapi.standard api
# ↳ Uses workspace .venv/bin/rapidkit (shared Core)

# Outside workspace
$ npx rapidkit create project fastapi.standard api
# ↳ Downloads and uses temporary npm bridge

2. Disk Efficiency:

Workspace .venv/: ~150MB (rapidkit-core + Poetry deps)
Each project .venv/: ~100MB (FastAPI, SQLAlchemy, etc.)
Total for 4 projects: 150MB + (4 × 100MB) = 550MB

Without workspace:

Each project: ~150MB (rapidkit-core) + 100MB (deps) = 250MB
Total for 4 projects: 4 × 250MB = 1000MB
Savings: 450MB (45%)

3. Version Consistency:

# All projects use same Core version
$ cd auth-service && rapidkit --version
RapidKit Core 0.3.0

$ cd ../user-service && rapidkit --version  
RapidKit Core 0.3.0  # Same version!

4. Upgrade Scenarios:

# Upgrade Core for entire workspace
cd my-workspace
poetry update rapidkit-core
# ↳ All projects instantly use new version

# Upgrade individual project dependencies
cd auth-service
poetry update fastapi
# ↳ Only affects this project

Global Install Alternative

Instead of workspace, you can install Core globally:

# With pipx (recommended - isolated)
pipx install rapidkit-core

# Or with pip (system-wide)
pip install rapidkit-core

# Now rapidkit is available everywhere
$ rapidkit --version
RapidKit Core 0.3.0

$ rapidkit create project fastapi.standard api
# ↳ Uses global installation

Trade-offs:

✅ No workspace needed for single projects
✅ rapidkit available system-wide
⚠️ All projects use same global Core version
⚠️ Upgrading affects all projects simultaneously
⚠️ No per-workspace version pinning

Three Ways to Start: Which One Should You Choose?

RapidKit gives you flexibility. Here's how each approach compares:

1️⃣ Workspace Creation (Recommended)

npx rapidkit my-workspace
cd my-workspace
rapidkit create project fastapi.standard api
cd api
rapidkit init && rapidkit dev

Best for:

Multiple services (microservices)
Team environments
Production projects
Long-term maintenance

Advantages:

✅ Prerequisites auto-installed (Python, Poetry, RapidKit Core)
✅ Shared rapidkit-core in workspace virtualenv
✅ Each project gets its own .venv/ but shares Core
✅ rapidkit command uses workspace environment (faster)
✅ VS Code extension auto-discovers workspace
✅ Consistent Core version across all projects

Setup time: 2 minutes (first time), instant for additional projects

Disk: Workspace .venv/ ~150MB (once) + each project .venv/ ~100MB

Complexity: Low (everything automated)

2️⃣ Direct Project Creation

# Outside any workspace
npx rapidkit create project fastapi.standard api
cd api
npx rapidkit init
npx rapidkit dev

Best for:

Single service
Quick prototypes
Learning RapidKit
Temporary experiments

Trade-offs:

⚠️ Requires Python 3.10+ and Poetry pre-installed
⚠️ Each project gets its own virtualenv (~150MB each)
⚠️ No automatic dependency synchronization
✅ Faster initial setup (no workspace overhead)
✅ Good for experimentation

Setup time: 5 minutes (if prerequisites exist)

Disk per project: ~150MB (separate virtualenv)

Complexity: Medium (manual prerequisite management)

3️⃣ Python Core Direct

# Install globally
pipx install rapidkit-core
# Or: pip install rapidkit-core

# Create project
rapidkit create project fastapi.standard api
cd api
rapidkit init
rapidkit dev

Best for:

Advanced users
CI/CD pipelines
Custom tooling
Docker environments

Trade-offs:

⚠️ Full manual Python environment management
⚠️ No workspace features
⚠️ No npm bridge benefits
✅ Maximum control over environment
✅ Good for automation scripts
✅ Minimal dependencies (Python only)

Setup time: Varies (depends on your environment)

Disk per project: ~150MB (separate virtualenv)

Complexity: High (manual everything)

Visual Approach: VS Code Extension

All three approaches integrate with VS Code extension:

Install RapidKit extension
Use Command Palette:
- "RapidKit: Create Workspace" (Approach 1)
- "RapidKit: Create Project" (Approach 2)
Browse modules visually
Check setup status

Perfect for:

Visual learners
GUI preference
Team onboarding
Non-terminal workflows

Comparison Matrix

Feature	Workspace	Direct	Python Core	VS Code
Auto Prerequisites	✅ Yes	⚠️ Partial	❌ No	✅ Yes
Shared Virtualenv	✅ Yes	❌ No	❌ No	✅ (workspace)
Multi-Project Support	✅ Excellent	⚠️ Manual	⚠️ Manual	✅ Excellent
Disk Efficiency	✅ High	⚠️ Medium	⚠️ Medium	✅ High
Setup Complexity	🟢 Low	🟡 Medium	🔴 High	🟢 Low
Team-Friendly	✅ Yes	⚠️ Moderate	❌ No	✅ Yes
CI/CD Ready	✅ Yes	✅ Yes	✅ Yes	⚠️ GUI only
Learning Curve	🟢 Easy	🟡 Medium	🔴 Steep	🟢 Easiest

Real Scenario: Building a SaaS Backend

Task: Create 4 microservices (auth, users, payments, notifications)

Approach 1: Workspace

npx rapidkit my-saas
cd my-saas
rapidkit create project fastapi.standard auth-service
rapidkit create project fastapi.standard user-service
rapidkit create project fastapi.standard payment-service
rapidkit create project fastapi.standard notification-service

Result:

Workspace .venv/ with rapidkit-core (~150MB)
Each project has own .venv/ (~100MB each = 400MB total)
Total: ~550MB (vs 600MB+ without workspace)
Setup time: 5 minutes
All services use same RapidKit Core version
rapidkit command (no npx) uses workspace environment

Approach 2: Direct (Individual Projects)

npx rapidkit create project fastapi.standard auth-service
cd auth-service && npx rapidkit init && cd ..

npx rapidkit create project fastapi.standard user-service
cd user-service && npx rapidkit init && cd ..

npx rapidkit create project fastapi.standard payment-service
cd payment-service && npx rapidkit init && cd ..

npx rapidkit create project fastapi.standard notification-service
cd notification-service && npx rapidkit init

Result:

Four separate virtualenvs (~600MB total)
Each has its own rapidkit-core installation
Setup time: 20+ minutes
Potential Core version conflicts between projects
Must use npx rapidkit for every command

Approach 3: Python Core

pip install rapidkit-core
rapidkit create project fastapi.standard auth-service
cd auth-service && poetry install && cd ..

rapidkit create project fastapi.standard user-service
cd user-service && poetry install && cd ..
# ...repeat for remaining services

Result:

Four virtualenvs (~600MB total)
Each project manages its own environment
Setup time: 25+ minutes
Full manual control (good for experts)
Requires global rapidkit-core installation
No npm bridge benefits (no npx workflow)

Our Recommendation: Start with Workspace

For 90% of use cases, workspace approach wins:

Handles prerequisites automatically
Scales effortlessly (add projects instantly)
Team-friendly (consistent environments)
Disk-efficient (shared virtualenv)
Production-ready (used by real companies)

Switch to Direct/Core when:

Single prototype project
Experimenting with RapidKit
Custom CI/CD requirements
Need maximum control

This Is What "Consistency at Scale" Really Means

Rule of thumb:

Planning to build 2+ related projects? → Workspace
Just trying RapidKit? → Standalone
Not sure? → Workspace (you can always ignore it)

Real-World Example: SaaS Backend

Let's build a complete SaaS backend in a workspace.

Step 1: Create workspace

npx rapidkit saas-backend
cd saas-backend

Step 2: Create core services

# Authentication & user management
rapidkit create project fastapi.ddd auth-service
rapidkit add module auth --project auth-service
rapidkit add module users.core --project auth-service

# Main API gateway
rapidkit create project nestjs.standard api-gateway

# Background jobs service
rapidkit create project fastapi.standard jobs-service
rapidkit add module celery --project jobs-service

# Notification service
rapidkit create project fastapi.standard notifications
rapidkit add module email --project notifications
rapidkit add module notifications.unified --project notifications

Step 3: Open in VS Code

code .

Result:

VS Code sidebar now shows:

📁 SaaS Backend (Workspace)
 ├── 🐍 auth-service (FastAPI)
 ├── 🟦 api-gateway (NestJS)
 ├── 🐍 jobs-service (FastAPI)
 └── 🐍 notifications (FastAPI)

One click to:

Start any service's dev server
Run tests across all services
Install modules visually
Check workspace health

Developer Experience Benefits

1. Instant Discoverability

New developer joins your team:

git clone company/backend-workspace
cd backend-workspace
code .

VS Code opens. They see:

All 8 microservices in the sidebar
Project structure is identical across services
Modules are documented in each project's README
Docker Compose is already configured

No documentation needed.

2. Consistent Commands

Every project, same commands:

cd auth-service
rapidkit dev      # Start dev server

cd ../api-gateway
rapidkit dev      # Start dev server

cd ../jobs-service
rapidkit test     # Run tests

No learning curve between services.

3. Shared Module Updates

You add a new logging module to one service:

cd auth-service
rapidkit add module logging

RapidKit Core is shared across the workspace.

Now every developer on every project can use the same module:

cd ../api-gateway
rapidkit add module logging   # Same version, instant install

No "which version did we use?" questions.

Advanced: Workspace Strategies

Strategy 1: Monolithic Workspace

All company projects in one workspace:

company-backend/
├── auth-service/
├── user-api/
├── payment-api/
├── notification-service/
├── analytics-api/
└── admin-api/

Pros: Maximum consistency
Cons: Large workspace

Strategy 2: Domain-Separated Workspaces

One workspace per domain:

company-auth/
├── auth-service/
└── user-api/

company-payments/
├── payment-api/
└── billing-service/

company-operations/
├── notification-service/
└── analytics-api/

Pros: Smaller workspaces, clear boundaries
Cons: Requires more setup

Strategy 3: Hybrid (Recommended)

Core services in a workspace, utilities standalone:

core-platform/       # Workspace
├── auth-service/
├── user-api/
└── payment-api/

tools/
├── migration-script/    # Standalone
└── data-import/         # Standalone

Pros: Best of both worlds
Cons: Requires discipline

Workspace Anti-Patterns to Avoid

❌ Anti-Pattern 1: Mixing Unrelated Projects

Don't put your company backend and personal blog in the same workspace.

Workspaces are for related projects, not all projects.

❌ Anti-Pattern 2: Never Using Standalone

Workspaces are powerful, but not always necessary.

Quick prototype? Use standalone:

npx rapidkit create project fastapi.standard quick-api

❌ Anti-Pattern 3: Ignoring the Registry

RapidKit auto-tracks workspaces in ~/.rapidkit/workspaces.json.

Don't manually edit this file — let RapidKit manage it.

The Hidden Superpower: Team Onboarding

This is where workspaces really shine.

Traditional onboarding:

Clone repo
Read 10-page setup guide
Install Python 3.11 (or was it 3.10?)
Create virtualenv
Install dependencies (pray no conflicts)
Set up .env files (which template?)
Install Docker
Configure IDE
Finally run the project (if lucky)

Time: 4-6 hours (or 2 days if unlucky)

Workspace onboarding:

Clone workspace repo
Run ./bootstrap.sh (installs Poetry, activates env)
Open VS Code: code .

Time: 5 minutes

Everything else is automatic:

Python environment is ready
Dependencies are locked
All projects are visible
Structure is consistent
Commands work immediately

Try It Yourself

Create a workspace and see the difference:

# Create workspace
npx rapidkit demo-workspace
cd demo-workspace

# Add two projects
rapidkit create project fastapi.standard api-one
rapidkit create project nestjs.standard api-two

# Open in VS Code
code .

Now try:

Browse projects in the sidebar
Check workspace health (pulse icon)
Install a module to one project
See how everything is tracked

What's Next?

In the next article, we'll build a production API from scratch in 5 minutes — no shortcuts, no hand-waving.

You'll see exactly what you get, why the structure matters, and how to deploy it.

Learn More

Build Your First AI Agent with RapidKit in 10 Minutes

RapidKit — Tue, 10 Feb 2026 21:37:22 +0000

The Problem with AI Integration

You want to add AI to your FastAPI backend.

What usually happens:

Install 5 different packages (openai, anthropic, langchain, etc.)
Write wrapper code for each provider
Handle streaming, caching, retries manually
Debug configuration hell
Spend 2 days integrating what should take 10 minutes

There's a better way.

What We're Building

A production-ready AI Assistant Service with:

✅ Multiple AI providers (Echo, Template, OpenAI-ready)
✅ Chat completions API
✅ Streaming responses
✅ Conversation history
✅ Response caching
✅ Health monitoring
✅ Provider switching

Time to build: 10 minutes

Lines of custom code: ~50

Source code: https://github.com/getrapidkit/rapidkit-examples/tree/main/my-ai-workspace

Published article links:

Let's start.

Prerequisites

You need:

Node.js 20+ (node --version)
Python 3.10+ (python3 --version)
A terminal
(Optional) OpenAI API key for real AI

Time: 1 minute to verify

Minute 0-2: Create Workspace and Project

Step 1: Create workspace (handles Python/Poetry setup automatically)

npx rapidkit my-ai-workspace

Prompts you'll see:

? Author name: developer
? Select Python version: 3.10
? Install method: 🎯 Poetry (Recommended)

What happens:

Creates workspace directory
Installs Poetry if needed
Creates virtualenv in workspace root
Installs rapidkit-core

Step 2: Create FastAPI project

cd my-ai-workspace
rapidkit create project fastapi.standard ai-agent

Prompts:

Project name: ai-agent
Install essential modules? Y

Step 3: Initialize project

cd ai-agent
rapidkit init

Your structure:

my-ai-workspace/
├── .venv/                  # Workspace virtualenv
├── pyproject.toml
└── ai-agent/
    ├── .venv/             # Project virtualenv
    ├── src/
    │   ├── main.py
    │   └── modules/
    ├── tests/
    └── pyproject.toml

Minute 2-3: Add AI Assistant Module

rapidkit add module ai_assistant

What gets installed:

src/
├── modules/
│   └── free/
│       └── ai/
│           └── ai_assistant/
│               ├── ai_assistant.py          # Runtime engine
│               ├── ai_assistant_types.py    # Type definitions
│               └── routers/
│                   └── ai/
│                       └── ai_assistant.py  # FastAPI routes
└── health/
    └── ai_assistant.py                      # Health endpoint

tests/
└── modules/
    └── free/
        └── integration/
            └── ai/
                └── ai_assistant/
                    └── test_ai_assistant_integration.py

Key Components:

Runtime (ai_assistant.py):
- Provider management
- Chat completion logic
- Streaming support
- Conversation history
- Response caching
Routes (routers/ai/ai_assistant.py):
- POST /ai/assistant/completions — Get completions
- POST /ai/assistant/stream — Stream responses
- GET /ai/assistant/providers — List providers
- POST /ai/assistant/cache/clear — Clear cache
- GET /ai/assistant/health — Health check
Types (ai_assistant_types.py):
- AssistantMessage — Message structure
- AssistantResponse — Response structure
- ProviderConfig — Provider configuration
- AiAssistantConfig — Runtime config

Minute 3-4: Configure Providers

Create config/ai_assistant.yaml:

# AI Assistant Configuration
providers:
  # Echo Provider (for testing)
  - name: echo
    provider_type: echo
    enabled: true
    options:
      prefix: "[AI] "
      suffix: " (powered by Echo)"
      mirror_context: true

  # Template Provider (pre-defined responses)
  - name: support
    provider_type: template
    enabled: true
    options:
      responses:
        - "Thank you for contacting support. {prompt}"
        - "I understand your concern about {prompt}. Let me help."
        - "Based on '{context}', regarding {prompt}, here's what I suggest..."

  # OpenAI Provider (ready for real AI)
  # - name: openai
  #   provider_type: openai
  #   enabled: false
  #   options:
  #     api_key: ${OPENAI_API_KEY}
  #     model: gpt-4
  #     temperature: 0.7

default_provider: echo
conversation_window: 20
cache_enabled: true
request_timeout_seconds: 30

Provider Types Explained:

Echo Provider

Perfect for testing. Echoes back your prompt with optional prefix/suffix.

# Example response:
# Input: "Hello"
# Output: "[AI] Hello (powered by Echo)"

Template Provider

Returns pre-configured responses in rotation. Great for FAQ bots.

# First request: "How do I reset password?"
# Response: "Thank you for contacting support. How do I reset password?"
# 
# Second request: "Where is my order?"
# Response: "I understand your concern about Where is my order?. Let me help."

OpenAI Provider (Real AI)

Integrates with OpenAI API. You'll implement this in advanced section.

Minute 4-5: Integrate into FastAPI

Update src/main.py:

from fastapi import FastAPI
from src.modules.free.ai.ai_assistant.routers.ai.ai_assistant import (
    register_ai_assistant,
    build_config,
)

# Load config from YAML
import yaml
with open("config/ai_assistant.yaml") as f:
    config_data = yaml.safe_load(f)

app = FastAPI(
    title="AI Agent API",
    version="1.0.0",
    description="Production AI Assistant powered by RapidKit"
)

# Register AI Assistant
register_ai_assistant(app, config=config_data)

@app.get("/")
async def root():
    return {
        "message": "AI Agent API is running",
        "endpoints": {
            "completions": "/ai/assistant/completions",
            "stream": "/ai/assistant/stream",
            "providers": "/ai/assistant/providers",
            "health": "/ai/assistant/health"
        }
    }

Install PyYAML:

poetry add pyyaml

Minute 5-6: Test Basic Functionality

Start the server:

rapidkit dev

Server output:

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

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

You'll see Swagger UI with AI endpoints!

Minute 6-7: Test Echo Provider

List available providers:

curl http://localhost:8000/ai/assistant/providers

Response:

["echo", "support"]

Test echo completion:

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

Response:

{
  "provider": "echo",
  "content": "[AI] What is RapidKit? (powered by Echo)",
  "latency_ms": 0.234,
  "cached": false,
  "usage": {
    "prompt_tokens": 3,
    "completion_tokens": 8,
    "total_tokens": 11
  },
  "metadata": null
}

Minute 7-8: Test Template Provider

curl -X POST http://localhost:8000/ai/assistant/completions \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "How do I reset my password?",
    "provider": "support"
  }'

Response:

{
  "provider": "support",
  "content": "Thank you for contacting support. How do I reset my password?",
  "latency_ms": 0.156,
  "cached": false,
  "usage": {
    "prompt_tokens": 6,
    "completion_tokens": 8,
    "total_tokens": 14
  }
}

Test with conversation context:

curl -X POST http://localhost:8000/ai/assistant/completions \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Follow up question",
    "provider": "support",
    "context": [
      {"role": "user", "content": "I forgot my password"},
      {"role": "assistant", "content": "I can help reset your password"}
    ]
  }'

Response includes context:

{
  "provider": "support",
  "content": "Based on 'I forgot my password | I can help reset your password', regarding Follow up question, here's what I suggest...",
  "latency_ms": 0.189,
  "cached": false,
  "usage": {...}
}

Minute 8-9: Test Streaming

curl -X POST http://localhost:8000/ai/assistant/stream \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Tell me about AI agents",
    "provider": "echo"
  }'

Response streams word by word:

[AI] Tell me about AI agents (powered by Echo)

With Python client:

import requests

response = requests.post(
    "http://localhost:8000/ai/assistant/stream",
    json={"prompt": "Explain RapidKit", "provider": "echo"},
    stream=True
)

for chunk in response.iter_content(chunk_size=None, decode_unicode=True):
    print(chunk, end="", flush=True)

Minute 9-10: Test Caching

First request (not cached):

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

Response:

{
  "cached": false,
  "latency_ms": 0.245
}

Second identical request (cached):

# Same request again
curl -X POST http://localhost:8000/ai/assistant/completions \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "What is caching?",
    "provider": "echo"
  }'

Response:

{
  "cached": true,
  "latency_ms": 0.245
}

Notice: cached: true and same latency (from cache, not recomputed)

Clear cache:

curl -X POST http://localhost:8000/ai/assistant/cache/clear

Health Monitoring

Check AI assistant health:

curl http://localhost:8000/ai/assistant/health

Response:

{
  "vendor": {
    "module": "ai_assistant",
    "status": "ok",
    "version": "0.1.7"
  },
  "runtime": {
    "module": "ai_assistant",
    "status": "ok",
    "providers": [
      {
        "name": "echo",
        "status": "ok",
        "latency_ms": 0.245,
        "details": {
          "prefix": "[AI] ",
          "suffix": " (powered by Echo)",
          "mirror_context": true
        }
      },
      {
        "name": "support",
        "status": "ok",
        "latency_ms": 0.189,
        "details": {
          "responses": 3
        }
      }
    ],
    "cache_entries": 5,
    "history_length": 12,
    "timestamp": "2026-02-10T10:30:00"
  },
  "status": "ok"
}

Key metrics:

Provider status and latency
Cache hit count
Conversation history length
Overall health status

Advanced: Add OpenAI Provider

Step 1: Install OpenAI SDK

poetry add openai

Step 2: Create custom provider

Create src/modules/free/ai/ai_assistant/providers/openai_provider.py:

"""OpenAI provider implementation."""

from __future__ import annotations
import os
from typing import Any, Iterable, Mapping, Sequence

from openai import OpenAI
from src.modules.free.ai.ai_assistant.ai_assistant import ChatProvider
from src.modules.free.ai.ai_assistant.ai_assistant_types import (
    AssistantMessage,
    ProviderStatus,
)


class OpenAIProvider:
    """OpenAI chat completion provider."""

    def __init__(
        self,
        *,
        name: str = "openai",
        api_key: str | None = None,
        model: str = "gpt-3.5-turbo",
        temperature: float = 0.7,
    ) -> None:
        self.name = name
        self._model = model
        self._temperature = temperature
        self._client = OpenAI(api_key=api_key or os.getenv("OPENAI_API_KEY"))
        self._last_latency_ms: float | None = None

    def generate(
        self,
        prompt: str,
        *,
        conversation: Sequence[AssistantMessage],
        settings: Mapping[str, Any] | None = None,
    ) -> str:
        """Generate completion using OpenAI API."""
        messages = [
            {"role": msg.role, "content": msg.content}
            for msg in conversation
        ]
        messages.append({"role": "user", "content": prompt})

        response = self._client.chat.completions.create(
            model=settings.get("model", self._model) if settings else self._model,
            messages=messages,
            temperature=settings.get("temperature", self._temperature) if settings else self._temperature,
        )

        return response.choices[0].message.content

    def stream(
        self,
        prompt: str,
        *,
        conversation: Sequence[AssistantMessage],
        settings: Mapping[str, Any] | None = None,
    ) -> Iterable[str]:
        """Stream completion tokens from OpenAI."""
        messages = [
            {"role": msg.role, "content": msg.content}
            for msg in conversation
        ]
        messages.append({"role": "user", "content": prompt})

        stream = self._client.chat.completions.create(
            model=settings.get("model", self._model) if settings else self._model,
            messages=messages,
            temperature=settings.get("temperature", self._temperature) if settings else self._temperature,
            stream=True,
        )

        for chunk in stream:
            if chunk.choices[0].delta.content:
                yield chunk.choices[0].delta.content

    def note_latency(self, latency_ms: float) -> None:
        """Record latency for health metrics."""
        self._last_latency_ms = latency_ms

    def health(self) -> ProviderStatus:
        """Return provider health status."""
        return ProviderStatus(
            name=self.name,
            status="ok",
            latency_ms=self._last_latency_ms,
            details={
                "model": self._model,
                "temperature": self._temperature,
            },
        )

Step 3: Register OpenAI provider

Update src/main.py:

from src.modules.free.ai.ai_assistant.routers.ai.ai_assistant import (
    register_ai_assistant,
)
from src.modules.free.ai.ai_assistant.providers.openai_provider import OpenAIProvider
import os

import yaml
with open("config/ai_assistant.yaml") as f:
    config_data = yaml.safe_load(f)

app = FastAPI(title="AI Agent API")

# Register assistant
assistant = register_ai_assistant(app, config=config_data)

# Add OpenAI provider manually
openai_provider = OpenAIProvider(
    name="openai",
    api_key=os.getenv("OPENAI_API_KEY"),
    model="gpt-4",
    temperature=0.7,
)
assistant.register_provider(openai_provider)
assistant.set_default_provider("openai")

If OPENAI_API_KEY is not set, keep echo/support as default so local/demo flows still work.

Step 4: Set API key

export OPENAI_API_KEY="sk-..."

Step 5: Test real AI

curl -X POST http://localhost:8000/ai/assistant/completions \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Explain RapidKit in one sentence",
    "provider": "openai"
  }'

Response (real GPT-4):

{
  "provider": "openai",
  "content": "RapidKit is a developer toolkit that accelerates backend API development by providing pre-built modules, workspace management, and production-ready templates for FastAPI and NestJS frameworks.",
  "latency_ms": 1247.5,
  "cached": false,
  "usage": {
    "prompt_tokens": 7,
    "completion_tokens": 31,
    "total_tokens": 38
  }
}

Real-World Use Case: Customer Support Agent

Let's build a customer support AI agent:

Create src/agents/support_agent.py:

"""Customer support AI agent."""

from typing import Sequence
from src.modules.free.ai.ai_assistant.ai_assistant import AiAssistant
from src.modules.free.ai.ai_assistant.ai_assistant_types import (
    AssistantMessage,
    AssistantResponse,
)


class SupportAgent:
    """AI-powered customer support agent."""

    def __init__(self, assistant: AiAssistant) -> None:
        self._assistant = assistant
        self._system_prompt = """You are a helpful customer support agent.
Be concise, friendly, and solution-oriented.
If you don't know the answer, escalate to human support."""

    def handle_ticket(
        self,
        customer_message: str,
        ticket_history: Sequence[AssistantMessage] | None = None,
    ) -> AssistantResponse:
        """Process customer support ticket."""
        context = [
            AssistantMessage(role="system", content=self._system_prompt)
        ]
        if ticket_history:
            context.extend(ticket_history)

        return self._assistant.chat(
            customer_message,
            provider="openai",  # or "support" for template
            context=context,
        )

    def classify_urgency(self, message: str) -> str:
        """Classify ticket urgency using AI."""
        prompt = f"Classify urgency (low/medium/high): {message}"
        response = self._assistant.chat(
            prompt,
            provider="openai",
            settings={"temperature": 0.1},  # More deterministic
        )
        return response.content.strip().lower()

Add route in src/main.py:

from fastapi import Request
from src.agents.support_agent import SupportAgent

@app.post("/support/ticket")
async def handle_support_ticket(
    message: str,
    request: Request,
) -> dict:
    assistant = request.app.state.ai_assistant
    agent = SupportAgent(assistant)

    # Classify urgency
    urgency = agent.classify_urgency(message)

    # Generate response
    response = agent.handle_ticket(message)

    return {
        "ticket_id": "TKT-12345",
        "urgency": urgency,
        "ai_response": response.content,
        "latency_ms": response.latency_ms,
        "next_action": "escalate" if urgency == "high" else "monitor"
    }

Test support agent:

curl -X POST "http://localhost:8000/support/ticket?message=My%20payment%20failed"

Response:

{
  "ticket_id": "TKT-12345",
  "urgency": "high",
  "ai_response": "I understand your payment failed. Let me help you resolve this. Can you provide your order ID and the error message you received?",
  "latency_ms": 1156.3,
  "next_action": "escalate"
}

What You Built

A production-ready AI Agent API with:

Core Features:

✅ Multi-provider AI assistant (Echo, Template, OpenAI)
✅ Chat completion endpoint
✅ Streaming responses
✅ Conversation context handling
✅ Response caching (instant cache hits)
✅ Health monitoring with metrics
✅ Provider switching at runtime

Advanced Features:

✅ Custom OpenAI integration
✅ Customer support agent
✅ Urgency classification
✅ Ticket routing logic

Production Ready:

✅ Type-safe with Pydantic models
✅ Health checks for monitoring
✅ Performance metrics (latency, cache hits)
✅ Error handling
✅ Async/streaming support
✅ Integration tests included

Total time: 10 minutes

Custom code: ~50 lines

Everything else: Generated by RapidKit

Key Takeaways

1. Provider-Agnostic Design

Switch AI providers without changing your code:

# Use OpenAI
response = assistant.chat(prompt, provider="openai")

# Switch to Anthropic (when you add it)
response = assistant.chat(prompt, provider="anthropic")

# Fallback to template
response = assistant.chat(prompt, provider="support")

2. Built-in Production Features

No need to implement yourself:

Conversation history tracking
Response caching (faster + cheaper)
Streaming support
Health monitoring
Performance metrics

3. Module Architecture Benefits

The ai_assistant module follows RapidKit's standard:

module.yaml — Version and metadata
templates/ — FastAPI and NestJS variants
docs/usage.md — Usage guide
Health endpoints built-in
Testing included

4. Extensibility

Easy to add providers:

Implement ChatProvider protocol
Register with assistant.register_provider()
Done

Example providers you can add:

Anthropic Claude
Google PaLM
Azure OpenAI
Cohere
Local models (Ollama, LM Studio)

Next Steps

Enhance your AI agent:

Add authentication:

   rapidkit add module auth_core

Add database for chat history:

   rapidkit add module db_postgres

Add Redis for distributed caching:

   rapidkit add module redis

Add observability:

   rapidkit add module observability

Deploy:

   docker build -t ai-agent .
   docker run -p 8000:8000 ai-agent

Module Customization

Override configuration via environment:

export RAPIDKIT_AI_ASSISTANT_LOG_LEVEL=DEBUG
export RAPIDKIT_AI_ASSISTANT_TIMEOUT=60
export RAPIDKIT_AI_ASSISTANT_FEATURE_FLAG=true

Custom overrides in overrides.py:

See /src/modules/free/ai/ai_assistant/overrides.py for runtime hooks.

Testing

Run integration tests:

rapidkit test

Test specific module:

poetry run pytest tests/modules/free/integration/ai/ai_assistant/ -v

Module verification:

rapidkit modules status

Troubleshooting

Provider Not Found

ProviderNotFoundError: Provider 'openai' is not registered

Solution: Check provider is registered in config or manually.

Timeout Errors

TimeoutError: Request exceeded 30 seconds

Solution: Increase timeout:

request_timeout_seconds: 60

OpenAI API Errors

Authentication Error: Invalid API key

Solution: Check environment variable:

echo $OPENAI_API_KEY

Learn More

You just built a production AI agent in 10 minutes.

Now scale it.

The RapidKit Ecosystem: Three Tools, One Vision

RapidKit — Tue, 10 Feb 2026 13:13:55 +0000

You Don't Need Another Framework

You need a workflow.

Backend development in 2026 isn't about picking the right web framework.
FastAPI is mature. NestJS is mature.

The problem isn't building APIs.
The problem is the everything else:

Setting up projects consistently
Managing dependencies across services
Organizing code in a way that scales
Onboarding new developers without friction
Maintaining multiple APIs without chaos

This is where most teams struggle.

And this is what RapidKit was built to solve.

One Problem, Three Tools

RapidKit isn't a monolithic framework.
It's an ecosystem of three focused tools that work together seamlessly:

RapidKit Core (Python Engine)
RapidKit CLI (npm Package)
RapidKit for VS Code (Extension)

Each tool solves a specific part of the workflow.
Together, they eliminate the friction in modern backend development.

1️⃣ RapidKit Core: The Brain

Language: Python

Install: pip/pipx install rapidkit-core

Role: Project generation, module management, and architecture enforcement

This is where the real work happens.

RapidKit Core is a Python-powered engine that:

Generates FastAPI and NestJS projects with clean architecture
Manages 27+ plug-and-play modules (auth, databases, caching, logging, etc.)
Maintains project structure and tracks file changes
Handles dependency resolution and environment setup
Powers the CLI and VS Code extension behind the scenes

Example:

rapidkit create project fastapi.standard my-api
rapidkit add module settings
rapidkit add module auth_core
rapidkit add module db_postgres
rapidkit add module redis

In four commands, you get:

A production-ready FastAPI project
Multi-source configuration management
PBKDF2 password hashing + HMAC token signing
PostgreSQL with async SQLAlchemy and connection pooling
Redis caching with retry logic
Docker and health endpoints included

Module System:

27+ free modules across 13 categories
Uniform architecture: every module has module.yaml, docs/usage.md, and generate.py
Framework variants: each module supports FastAPI and NestJS
Environment overrides: RAPIDKIT_<MODULE>_<SETTING> pattern

Generation Workflow:

module.yaml → generate.py → vendor artifacts → framework plugin → project files

No templates. No boilerplate copy-paste. Just generated, version-tracked code.

2️⃣ RapidKit CLI: The Bridge

Language: Node.js (TypeScript)

Install: npm install -g rapidkit (or use npx)

Role: Developer-friendly interface and workspace orchestration

The CLI is your primary interface with RapidKit.

It bridges the gap between your terminal and the Python engine, handling:

Workspace creation and management
Project lifecycle commands (init, dev, test, build)
Environment detection (Python, Node, Poetry, etc.)
Command delegation to projects or Core
Cross-platform compatibility (Windows, Linux, macOS)

Why Node.js?

Because most developers already have Node installed.

You don't need to think about Python environments or Poetry setup — the CLI handles it automatically when you create a workspace.

Example workflow:

# Create a workspace (sets up Python environment)
npx rapidkit my-workspace
cd my-workspace

# Create projects
rapidkit create project fastapi.standard api-gateway
rapidkit create project nestjs.standard user-service

# Start developing
cd api-gateway
rapidkit dev  # Starts FastAPI server at :8000

The CLI is smart:

Inside workspace directory? Uses workspace .venv/bin/rapidkit (shared Core)
Outside workspace? Uses npm bridge to invoke Core
Inside a project? Detects .rapidkit/ and runs project commands (dev, test)
Command rapidkit (no npx)? Looks for workspace virtualenv first, then global install

3️⃣ RapidKit for VS Code: The Interface

Platform: VS Code Extension

Install: VS Code Marketplace

Role: Visual project management and discovery

Some developers prefer the command line.
Others prefer a GUI.

RapidKit for VS Code gives you both.

Key features:

Welcome Panel: Central hub for workspaces and projects
Module Browser: Browse and install 27+ modules with one click
Setup Status: Verify your development environment (Python, CLI, Core)
Workspace Health: Check any workspace for issues
Project Creation: Visual wizard for FastAPI/NestJS projects
Sidebar Integration: All your workspaces and projects in one place

Example:

Open VS Code
Ctrl+Shift+P → "RapidKit: Create Project"
Choose FastAPI or NestJS
Enter project name
Done.

Your project is ready with:

Full project structure
Dependencies configured
Dev server ready to start
API docs waiting at /docs

No terminal commands needed.

How They Work Together

Here's the real power:

Each tool handles what it's best at, but they're deeply integrated.

Scenario 1: CLI-First Workflow

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

# Create project via CLI
rapidkit create project fastapi.standard api

# Open in VS Code
code .

Result: VS Code extension auto-discovers the workspace, shows all projects in the sidebar, and offers module installation via GUI.

Scenario 2: VS Code-First Workflow

Open VS Code
Use extension to create workspace
Use extension to create projects
Use extension to install modules

Result: Everything is tracked in ~/.rapidkit/workspaces.json. Open a terminal and rapidkit commands work instantly.

Scenario 3: Mixed Workflow (Most Common)

Use CLI for fast project creation
Use VS Code for module browsing and installation
Use CLI for development commands (dev, test, build)
Use VS Code for health checks and workspace management

The ecosystem adapts to your workflow.

RapidKit Modules: The Building Blocks

RapidKit Core provides 27+ production-ready modules organized into 13 categories:

🔐 Authentication & Authorization

auth/core — PBKDF2 password hashing + HMAC tokens
auth/api_keys — API key management
auth/oauth — OAuth2 providers (Google, GitHub, etc.)
auth/session — Session management
auth/passwordless — Magic link authentication

💾 Database

database/db_postgres — Async/sync PostgreSQL with pooling
database/db_mongo — MongoDB integration
database/db_sqlite — SQLite for prototyping

⚡ Caching & Performance

cache/redis — Async Redis with retry logic

🔒 Security

security/cors — CORS middleware with whitelisting
security/headers — Security headers (CSP, HSTS, etc.)
security/rate_limiting — Rate limiting

📧 Communication

communication/email — Email sending
communication/notifications — Push notifications

⚙️ Essentials

essentials/settings — Multi-source configuration
essentials/middleware — Custom middleware
essentials/logging — Structured logging
essentials/deployment — Deployment configs

📊 Observability

observability/core — Metrics and tracing

⏱️ Background Tasks

tasks/celery — Celery integration

👥 User Management

users/core — User models and CRUD
users/profiles — User profiles

Every module provides:

✅ Framework variants (FastAPI + NestJS)
✅ Health endpoint (/api/health/module/<name>)
✅ Environment-based configuration
✅ Usage documentation (docs/usage.md)
✅ Testing setup

Why Three Tools Instead of One?

Because focus matters.

Python Core: Best for project generation and module logic
Node.js CLI: Best for developer accessibility and environment detection
VS Code Extension: Best for visual discovery and onboarding

Trying to cram everything into one tool creates complexity.
Separating concerns creates simplicity.

Under the Hood: Architecture

┌─────────────────────────────────────────┐
│       VS Code Extension                 │
│  (Visual interface & workspace manager) │
└────────────────┬────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────┐
│          RapidKit CLI (npm)             │
│    (Command routing & delegation)       │
└────────────────┬────────────────────────┘
                 │
      ┏━━━━━━━━━┻━━━━━━━━━┓
      ▼                    ▼
┌──────────────┐   ┌──────────────────┐
│ Project CLI  │   │  RapidKit Core   │
│  (Launcher)  │   │ (Python Engine)  │
└──────────────┘   └──────────────────┘
      │                    │
      └─────────┬──────────┘
                ▼
      ┌──────────────────┐
      │ Generated Project│
      │ (FastAPI/NestJS) │
      └──────────────────┘

Key insight: The CLI and Extension never generate code directly. They delegate to RapidKit Core, which ensures consistency across all entry points.

What This Means for You

If you're a solo developer:

Use the CLI for speed
Use VS Code for discovery
Pick what fits your workflow

If you're on a team:

Use VS Code for onboarding
Use CLI for automation and CI/CD
Use workspaces to enforce consistency

If you're evaluating RapidKit:

Start with workspace creation (npx rapidkit my-workspace)
Install VS Code extension to explore modules visually
Try all three approaches and pick your favorite

There's no lock-in. All three tools share the same project format.

The Vision: Invisible Infrastructure

The goal isn't to make you think about RapidKit.

The goal is to make you forget about boilerplate and focus on building features.

Core generates the foundation
CLI keeps you productive
VS Code keeps you organized

And behind the scenes, everything stays consistent, maintainable, and production-ready.

Try It Yourself

Pick your entry point:

CLI:

npx rapidkit my-workspace

VS Code:

Install RapidKit extension
Ctrl+Shift+P → "RapidKit: Create Workspace"

Python directly:

# Recommended: isolated install
pipx install rapidkit-core

# Or: standard install
pip install rapidkit-core

# Create project
rapidkit create project fastapi.standard my-api

💡 Recommendation: Start with the workspace approach (npx rapidkit my-workspace) for the best experience — it handles all prerequisites automatically.

All three paths lead to the same place: production-ready FastAPI and NestJS projects in minutes.

Learn More

📦 npm CLI: npmjs.com/package/rapidkit
🐍 Python Core: pypi.org/project/rapidkit-core
🧩 VS Code Extension: marketplace.visualstudio.com
🌐 Website: getrapidkit.com

In the next post, we'll explore Workspace-First Development — why organizing multiple projects in one environment changes everything for backend teams.

Stay tuned.

Stop Rewriting Backend Foundations: Introducing RapidKit

RapidKit — Tue, 10 Feb 2026 09:13:12 +0000

We’ve All Been Here

You start a new backend project.

Not the first one. Not the tenth one either.

And before you write a single line of business logic, you’re already doing the same things again:

Setting up project structure
Choosing (again) how to organize layers and modules
Wiring authentication, configs, logging
Creating Docker files, environments, CI configs
Debating architecture decisions you’ve already solved before

None of this is new.
None of this moves the product forward.

Yet it happens every single time.

Backend Projects Rarely Fail Because of Features

They fail because the foundation is rushed, inconsistent, or impossible to scale.

Different projects, different structures.
Different teams, different conventions.
Onboarding takes weeks.
Maintenance becomes painful.

After repeating this cycle across multiple teams and projects, one question kept coming up:

Why are we still rebuilding backend foundations from scratch?

This Is Why We Built RapidKit

RapidKit is an open-source framework designed to give backend teams a solid, production-ready starting point — without locking them into rigid abstractions.

It’s not a template.
It’s not a starter repo.

It’s a scaffolding system that generates and manages real projects you can evolve over time.

What RapidKit Focuses On

RapidKit is built around a few core ideas:

Consistency over cleverness
Every project starts with the same clean, predictable structure.
Workspace-first development
Manage multiple services in one shared environment — ideal for teams and microservices.
Modular architecture
Authentication, databases, caching, logging, observability — added when you need them, not before.
Production readiness by default
Docker, environment management, testing, and CI are part of the foundation, not afterthoughts.
Framework flexibility
Build APIs with FastAPI (Python) or NestJS (TypeScript) using a unified workflow.

A Quick Look

Creating a new backend doesn’t require days of setup:

# Create a workspace
rapidkit my-workspace
cd my-workspace

# Create a project
rapidkit create project fastapi.standard my-api

# Add features as modules
rapidkit add module auth
rapidkit add module database.postgres

# Start development
rapidkit dev

In minutes, you get a clean, structured, production-ready API — ready to build real features.

Who Is RapidKit For?

RapidKit is especially useful for:

Teams building multiple backend services
Startups that need to move fast without cutting corners
Solo developers tired of rewriting boilerplate
Companies that care about long-term maintainability
Developers who value clean architecture and consistency

It’s probably not for projects that need a completely custom architecture from day one.

Why This Is Just the Beginning

This post is intentionally high-level.

In upcoming articles, we’ll go deeper into:

Workspace-first backend development
How RapidKit’s module system works
Designing scalable FastAPI projects
Managing multiple services with shared tooling
Writing your own RapidKit modules

RapidKit is evolving, and we’re building it openly.

Learn More

🌐 Website: https://www.getrapidkit.com
📦 GitHub / Core Engine: https://pypi.org/project/rapidkit-core/
📦 npm CLI: https://www.npmjs.com/package/rapidkit
🧩 VS Code Extension: https://marketplace.visualstudio.com/items?itemName=rapidkit.rapidkit-vscode

Final Thought

Backend teams shouldn’t spend their energy reinventing foundations.

They should spend it building products.

That’s the problem RapidKit is trying to solve.