COOKBOOK = Your exo-brain for patterns, templates, and starting points

When you're about to start a new project:
  → "Let me check Cookbook first"
  
When you see a pattern that works:
  → "Adding this to Cookbook"
  
When you need to explain something to a teammate:
  → "Here's the Cookbook recipe"
  
When you're hiring:
  → "Can you fork a Cookbook recipe and extend it?"

When I need to build...         I check Cookbook for...
├─ Async service              → Python + Go recipes
├─ CLI tool                    → Shell + Go + TypeScript recipes
├─ Distributed system          → Go + Rust patterns
├─ Web API                     → TypeScript + Python templates
├─ Infrastructure automation   → Shell + Go scripts
└─ Concurrent processing       → Rust + Go + Python patterns

github.com/your-cookbook/

├── README.md
│   └─ "The Cookbook: my personal recipe library"
│
├── python/
│   ├── recipes/
│   │   ├── async-retry/
│   │   ├── event-handler/
│   │   ├── connection-pool/
│   │   └── [templates]
│   │
│   ├── patterns/
│   │   ├── circuit-breaker/
│   │   ├── bulkhead-isolation/
│   │   └── [proven approaches]
│   │
│   └── blueprints/
│       ├── microservice-foundation/
│       ├── event-driven-system/
│       └── [full systems]
│
├── go/
│   ├── recipes/
│   │   ├── goroutine-pool/
│   │   ├── channel-patterns/
│   │   ├── graceful-shutdown/
│   │   └── [templates]
│   │
│   ├── patterns/
│   │   ├── worker-pool/
│   │   ├── fan-out-fan-in/
│   │   └── [proven approaches]
│   │
│   └── blueprints/
│       ├── http-service/
│       ├── message-processor/
│       └── [full systems]
│
├── typescript/
│   ├── recipes/
│   │   ├── async-queue/
│   │   ├── error-handling/
│   │   ├── react-patterns/
│   │   └── [templates]
│   │
│   ├── patterns/
│   │   ├── state-management/
│   │   ├── dependency-injection/
│   │   └── [proven approaches]
│   │
│   └── blueprints/
│       ├── fullstack-app/
│       ├── nextjs-foundation/
│       └── [full systems]
│
├── rust/
│   ├── recipes/
│   │   ├── async-runtime/
│   │   ├── error-handling/
│   │   ├── memory-patterns/
│   │   └── [templates]
│   │
│   ├── patterns/
│   │   ├── zero-copy/
│   │   ├── trait-patterns/
│   │   └── [proven approaches]
│   │
│   └── blueprints/
│       ├── async-service/
│       ├── systems-tool/
│       └── [full systems]
│
├── shell/
│   ├── recipes/
│   │   ├── parallel-processing/
│   │   ├── error-handling/
│   │   ├── logging-patterns/
│   │   └── [templates]
│   │
│   ├── patterns/
│   │   ├── idempotent-operations/
│   │   ├── retry-logic/
│   │   └── [proven approaches]
│   │
│   └── blueprints/
│       ├── deployment-automation/
│       ├── backup-system/
│       └── [full systems]
│
├── cross-language/
│   ├── patterns/
│   │   ├── distributed-tracing/
│   │   ├── service-communication/
│   │   ├── graceful-degradation/
│   │   └── [patterns that work everywhere]
│   │
│   └── blueprints/
│       ├── microservice-system/
│       ├── event-driven-mesh/
│       └── [multi-language systems]
│
└── templates/
    ├── new-service-scaffold/
    ├── new-cli-scaffold/
    ├── deployment-scaffold/
    └── [cookiecutter templates for all languages]

You also tag/index everything by concept:

├── concurrency/
│   ├── python/async-retry
│   ├── go/goroutine-pool
│   ├── rust/tokio-patterns
│   ├── typescript/async-queue
│   └── [same concept, different languages]
│
├── error-handling/
│   ├── python/try-except-patterns
│   ├── go/error-wrapping
│   ├── rust/result-patterns
│   ├── typescript/try-catch-strategies
│   └── [how each language handles errors]
│
├── resilience/
│   ├── all languages
│   └── circuit-breaker, retry, timeout, bulkhead
│
├── performance/
│   ├── all languages
│   └── caching, pooling, batching patterns
│
└── systems/
    ├── all languages
    └── distributed systems, messaging, service design

# The Cookbook

My personal recipe library. 

Templates, patterns, and blueprints across:
- Python
- Go  
- Rust
- TypeScript
- Shell

When I'm about to start something, I check the Cookbook first.

## Browse by Language

- Python Recipes
- Go Recipes
- Rust Recipes
- TypeScript Recipes
- Shell Recipes

## Browse by Concept

- Concurrency Patterns
- Error Handling
- Resilience & Reliability
- Performance Optimization
- Systems Design

## Latest Recipes

[Feed of newest additions]

## Most Forked

[Feed of most-used recipes]

## Featured Blueprint

[Highlight one complete system architecture]

---

The Cookbook is my exo-brain. 
Here's how I think about building systems, across every language I use.

Fork what you need. Build something great.

---
title: Circuit Breaker Pattern
id: circuit-breaker-001

# Multi-language implementations
languages:
  - python: ./python/patterns/circuit-breaker/
  - go: ./go/patterns/circuit-breaker/
  - rust: ./rust/patterns/circuit-breaker/
  - typescript: ./typescript/patterns/circuit-breaker/

# Concepts this touches
concepts:
  - resilience
  - fault-tolerance
  - timeouts
  - error-handling

# When to use
use_cases:
  - microservices
  - distributed systems
  - external API calls
  - unreliable networks

# Trade-offs
tradeoffs:
  - increases latency (slightly)
  - reduces cascading failures (significantly)
  - requires monitoring

# Difficulty
difficulty: intermediate
time_to_understand: 25min
time_to_implement: 1-2 hours

# Dependencies (per language)
dependencies:
  python:
    - asyncio (stdlib)
  go:
    - stdlib (no deps)
  rust:
    - tokio
  typescript:
    - none

# Related recipes
related:
  - bulkhead-isolation
  - retry-logic
  - timeout-patterns
  - graceful-degradation

# Last updated
created: 2025-02-15
updated: 2025-02-23
---

You're building a searchable, forkable, version-controlled extension of your brain.

When you're about to start a new project:

Question in your head          →  Cookbook search
"I need async error handling"  →  Search: async + error
                               →  See Python, Go, Rust, TS implementations
                               →  Pick the one for this project
                               →  Fork the recipe
                               →  Modify for your use case
                               →  Done in 30 min instead of 2 hours

github.com/your-name/cookbook

├── README.md                    (Landing page)
├── CONTRIBUTING.md              (How to add recipes)
├── STRUCTURE.md                 (What goes where)
│
├── python/
├── go/
├── rust/
├── typescript/
├── shell/
├── cross-language/
│
├── docs/                        (Website source)
│   ├── index.md
│   ├── concepts/
│   ├── guides/
│   └── mint.json (Mintlify config)
│
├── .github/
│   └── workflows/
│       ├── validate-recipes.yml (lint, test)
│       └── update-index.yml (rebuild search)
│
└── scripts/
    ├── generate-index.py        (Auto-index all recipes)
    ├── validate-recipe.py       (Check recipe quality)
    └── suggest-related.py       (Find related recipes)

cookbook.dev/search/?q=concurrency
├─ python/recipes/async-retry
├─ go/recipes/goroutine-pool
├─ rust/recipes/tokio-task-spawning
└─ typescript/recipes/promise-pool

cookbook.dev/search/?q=error-handling
├─ python/patterns/exception-hierarchy
├─ go/patterns/error-wrapping
├─ rust/patterns/result-patterns
└─ typescript/patterns/error-boundaries

cookbook.dev/concepts/concurrency/
├─ All concurrency patterns
├─ All concurrency recipes
├─ Across all languages
└─ Organized by language

cookbook.dev/python       → All Python recipes, patterns, blueprints
cookbook.dev/go          → All Go recipes, patterns, blueprints
etc.

cookbook.dev/concurrency      → All concurrency patterns (all languages)
cookbook.dev/error-handling   → All error patterns (all languages)
etc.

cookbook.dev/beginner        → All beginner recipes
cookbook.dev/intermediate    → All intermediate patterns
cookbook.dev/advanced        → All advanced blueprints

10:00 AM: Start new project
  └─ "What language? What type of project?"
  └─ Go to cookbook.dev
  └─ Filter by language
  └─ Pick relevant recipes/blueprint
  └─ Fork structure
  └─ Start building (30 min saved)

2:00 PM: Hit a problem
  └─ "How do I handle this error pattern?"
  └─ Search cookbook.dev
  └─ Find recipe in Python + Go + Rust
  └─ See how each language handles it
  └─ Apply to current project

4:00 PM: Solve something new
  └─ "This is a pattern I should remember"
  └─ Add to Cookbook
  └─ Include all language variants if known
  └─ Add to search index

Next week: Teach a teammate
  └─ "Check the Cookbook for examples"
  └─ Link to specific recipe
  └─ They learn from your pattern
  └─ They can adapt it

cookbook.dev/

├── /python
│   ├── /recipes
│   ├── /patterns
│   └── /blueprints
│
├── /go
│   ├── /recipes
│   ├── /patterns
│   └── /blueprints
│
├── /rust
├── /typescript
├── /shell
│
├── /concepts
│   ├── /concurrency
│   ├── /error-handling
│   ├── /resilience
│   ├── /performance
│   └── /systems
│
├── /guides
│   ├── how-to-fork-a-recipe
│   ├── how-to-extend-a-recipe
│   ├── how-to-add-a-recipe
│   └── comparing-approaches-across-languages
│
├── /search
│   └─ Full-text searchable index
│
└── /about
    ├── why-this-exists
    ├── my-languages
    └── contact

# Circuit Breaker Pattern

## Overview
Prevent cascading failures in distributed systems by failing fast 
when a service is unavailable.

## When to Use
- External API calls with potential failures
- Microservices communication
- Unreliable networks

## When NOT to Use
- Local function calls (overhead not worth it)
- Always-available services

## Concept Diagram
[boxes & arrows showing circuit breaker states]

## Implementations

### Python
```python
# Code from ./python/patterns/circuit-breaker/
# Working implementation

// Code from ./go/patterns/circuit-breaker/
// Working implementation

// Code from ./rust/patterns/circuit-breaker/
// Working implementation

// Code from ./typescript/patterns/circuit-breaker/
// Working implementation

---

## Search & Discovery Engine

### Mintlify Config for Multi-Language Search

```json
{
  "name": "Cookbook",
  "description": "Universal template & pattern library across Python, Go, Rust, TypeScript, Shell",
  
  "navigation": [
    {
      "group": "Languages",
      "pages": [
        "python",
        "go",
        "rust",
        "typescript",
        "shell"
      ]
    },
    {
      "group": "Concepts",
      "pages": [
        "concepts/concurrency",
        "concepts/error-handling",
        "concepts/resilience",
        "concepts/performance",
        "concepts/systems"
      ]
    },
    {
      "group": "Browse",
      "pages": [
        "browse/all-recipes",
        "browse/all-patterns",
        "browse/all-blueprints",
        "browse/by-difficulty"
      ]
    }
  ],
  
  "analytics": {
    "plausible": {
      "domain": "cookbook.dev"
    }
  }
}

recipe-name/
├── v1.0/
│   ├── python/
│   ├── go/
│   └── [initial implementations]
│
├── v1.5/
│   ├── python/ (improved error handling)
│   ├── go/ (performance optimizations)
│   └── [refinements]
│
├── v2.0/
│   ├── python/ (async variant added)
│   ├── go/ (context support)
│   └── [major updates]
│
└── CHANGELOG.md (evolution documented)

YOUR PERSONAL BRAND:
├─ Polyglot engineer (Python, Go, Rust, TS, Shell)
├─ Systems thinker (boxes & arrows, architecture)
├─ Open about your process (sharing patterns)
└─ Practical (everything has working code)

COOKBOOK manifests this:
├─ Single repository (unified view)
├─ All languages (your toolkit)
├─ Organized by concept (your thinking)
├─ Executable recipes (your practicality)
└─ Transparent evolution (your openness)

RESULT:
"This person doesn't specialize in one language.
They specialize in patterns that work across languages.
That's a different (higher) level of expertise."

Most engineers keep their patterns in their head.
You're externalizing them.

That has 5 effects:

1. You learn faster (writing forces clarity)
2. You teach faster (patterns are documented)
3. You build faster (starting from template)
4. You hire better (candidates understand your approach)
5. You consult better (you literally have a portfolio of patterns)