Capstone: Build a Complete Feature

The Complete Workflow

In the previous lesson, we explored advanced workflows. Now let’s build on that foundation. Time to bring everything together. We’ll walk through building a complete feature using all the techniques from this course.

This isn’t a toy example. It’s the real workflow I’d use for production code.

The Feature: API Rate Limiting

We’re adding rate limiting to an Express.js API. Requirements:

Limit requests per user (by API key)
Configurable limits (requests per minute)
Return proper 429 responses when exceeded
Bypass for admin users
Redis-backed for distributed deployments
Comprehensive tests

Let’s build it.

Phase 1: Plan

Don’t touch code yet. Plan first.

> I need to add API rate limiting to an Express.js app.
> Requirements:
> - Per-user limiting by API key
> - Configurable limits
> - Proper 429 responses
> - Admin bypass
> - Redis-backed
> - Full test coverage
>
> Outline the implementation:
> 1. What files need to be created?
> 2. What existing files need modification?
> 3. What's the order of implementation?
> Don't write code yet.

Claude produces a plan. Review it. Ask questions:

> Why Redis instead of in-memory? What if we want to support both?

> How will we handle the admin bypass—header check or database lookup?

Get alignment before implementation.

Phase 2: Context Setup

Add relevant files:

/add src/middleware/*.js
/add src/config/index.js
/add package.json
/add tests/middleware/*.test.js

Verify context:

/ls

We should see the middleware patterns and config structure.

Phase 3: Core Implementation

Build the rate limiter:

> Create the rate limiting middleware at src/middleware/rate-limiter.js
>
> Requirements from our plan:
> - Token bucket algorithm
> - Redis storage (with in-memory fallback)
> - Configurable limits from config
> - Returns 429 with Retry-After header
>
> Follow the patterns from the existing middleware files.

Claude creates the middleware. Review it:

> Walk me through how the token bucket refills.

> What happens if Redis is unavailable?

Fix any issues:

> The fallback logic isn't quite right. When Redis fails, it should:
> - Log the error
> - Fall back to in-memory
> - Continue checking limits
> Fix this.

Phase 4: Tests First (Almost)

Before integrating, write tests:

> Create tests for the rate limiter at tests/middleware/rate-limiter.test.js
>
> Test cases:
> - Allows requests under limit
> - Blocks requests over limit
> - Returns correct 429 response with Retry-After
> - Admin bypass works
> - Redis failure fallback works
> - Limits reset after window expires

Run the tests:

> Run the tests. They should all pass.

If tests fail, iterate:

> Test 3 is failing. The Retry-After header isn't being set.
> Fix the middleware.

Phase 5: Integration

Now wire it up:

/add src/app.js
> Integrate the rate limiter middleware.
> - Apply globally but after authentication middleware
> - Use config for limit values
> - Add to the middleware chain in the right order

Add configuration:

/add src/config/index.js
> Add rate limiting configuration:
> - RATE_LIMIT_WINDOW_MS (default 60000)
> - RATE_LIMIT_MAX_REQUESTS (default 100)
> - RATE_LIMIT_ADMIN_BYPASS (default true)

Quick check: Before moving on, can you recall the key concept we just covered? Try to explain it in your own words before continuing.

Phase 6: Edge Cases

Now harden:

> Review the rate limiter for edge cases:
> - What if API key is missing?
> - What if API key is malformed?
> - What about race conditions in distributed environment?
> - What if limit config is invalid?
>
> Add handling for any gaps.

Claude identifies issues and fixes them.

Phase 7: Documentation

> Create documentation for the rate limiting feature:
> - Add section to README about rate limiting
> - Add inline JSDoc comments to the middleware
> - Document the configuration options
> - Add example of how to test rate limiting

Phase 8: Final Review

Full review before committing:

> Review everything we built:
> - src/middleware/rate-limiter.js
> - tests/middleware/rate-limiter.test.js
> - Changes to src/app.js and config
>
> Any issues? Missing test cases? Potential bugs?

Run final tests:

> Run all tests. Confirm everything passes.

Check git status:

git status
git diff

Phase 9: Commit

Clean git history:

git add src/middleware/rate-limiter.js
git commit -m "feat: add rate limiting middleware with Redis storage"

git add tests/middleware/rate-limiter.test.js
git commit -m "test: add rate limiter test coverage"

git add src/app.js src/config/index.js
git commit -m "feat: integrate rate limiter globally"

git add README.md
git commit -m "docs: document rate limiting configuration"

Logical commits that could each be reverted independently.

Your Capstone Challenge

Build this feature yourself using Claude Code:

Feature: API Request Logging

Requirements:

Log all incoming API requests
Include: timestamp, method, path, user ID, response time, status code
Store in database (or file for simplicity)
Configurable log levels
Ability to query/search logs
Tests

Your workflow should include:

Planning session (don’t code yet)
Context setup (add relevant files)
Core implementation
Tests
Integration
Edge case handling
Documentation
Final review
Clean commits

Use everything you’ve learned.

Course Recap

Over 8 lessons, you’ve learned:

Lesson	What You Learned
1. Introduction	The mental model: direct Claude, don’t just ask
2. Core Commands	Essential slash commands for daily use
3. Context Management	Strategic file loading for better responses
4. Task Orchestration	Breaking down and sequencing complex work
5. File Operations	Safe, efficient file manipulation
6. Bash Integration	Intelligent automation with shell commands
7. Advanced Workflows	Professional patterns for serious development
8. Capstone	Putting it all together

Key Principles

Context is everything. Quality over quantity.
Plan before implementing. Especially for anything non-trivial.
Iterate, don’t restart. Build on what works.
Verify continuously. Test early and often.
Git is your safety net. Commit often, revert easily.
Use the right level of direction. Match effort to task complexity.

What’s Next

You’ve got the foundation. Now:

Practice daily. Every task is an opportunity to get better.
Build your own workflows. Adapt patterns to your projects.
Stay current. Claude Code evolves. Check for new features.
Share knowledge. Teach others what you’ve learned.

Go build something.