From 5a3b9fe4afa71a291fdd236ab53152ae111ba771 Mon Sep 17 00:00:00 2001 From: donbr <7340008+donbr@users.noreply.github.com> Date: Fri, 2 Oct 2026 14:20:38 -0700 Subject: [PATCH] chore: remove the Concepts page The page was generated in b03de6c (Nov 2025) and opened with an anecdote that never happened. Removes ConceptsPage.tsx, its route, the Concepts nav link and the CLAUDE.md nav mention. /concepts now falls through to the 404 page. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01Ppa5DyJCZ1CowKtz58QARN --- CLAUDE.md | 2 +- src/App.tsx | 2 - src/components/layout/Layout.tsx | 9 - src/pages/ConceptsPage.tsx | 348 ------------------------------- 4 files changed, 1 insertion(+), 360 deletions(-) delete mode 100644 src/pages/ConceptsPage.tsx diff --git a/CLAUDE.md b/CLAUDE.md index 1f17204..7915b25 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -79,7 +79,7 @@ The ProjectCard component is also defined inline in ProjectsPage.tsx (lines 15-1 ### Layout Component The Layout component (`src/components/layout/Layout.tsx`) wraps all pages and provides: -- Navigation bar with links to sections (About, Expertise, Publications, Projects, Concepts, Teaching, Certifications, Contact, Graph Demos) +- Navigation bar with links to sections (About, Expertise, Publications, Projects, Teaching, Certifications, Contact, Graph Demos) - Active link highlighting using hash-based navigation for sections and pathname for Projects - Footer with social links (GitHub, LinkedIn, Graph Visualizations) diff --git a/src/App.tsx b/src/App.tsx index 95bb349..85546da 100644 --- a/src/App.tsx +++ b/src/App.tsx @@ -4,7 +4,6 @@ import { BrowserRouter, Routes, Route } from 'react-router-dom'; // Page Components import HomePage from '@/pages/HomePage'; import ProjectsPage from '@/pages/ProjectsPage'; -import ConceptsPage from '@/pages/ConceptsPage'; import NotFoundPage from '@/pages/NotFoundPage'; // Project Components @@ -21,7 +20,6 @@ const App: React.FC = () => { } /> } /> - } /> {/* Project routes */} } /> diff --git a/src/components/layout/Layout.tsx b/src/components/layout/Layout.tsx index e47b2f0..2a3c251 100644 --- a/src/components/layout/Layout.tsx +++ b/src/components/layout/Layout.tsx @@ -69,15 +69,6 @@ const Layout: React.FC = ({ children }) => { > Projects - - Concepts - { - return ( - - {/* Hero Section */} -
-
-

- MCP Architecture: Concepts Before Code -

-

- Frame the problem first. Understand the trade-offs. Then write the code. -

-
-
- - {/* Introduction */} -
-
-
-

- A student once asked me: "Should I refactor my FastAPI RAG system to use FastMCP?" -

-

- My answer? "It depends. Let's talk about what problem you're actually solving." -

-
-

- This page isn't about code syntax. It's about architectural decisions — - when to use MCP tools vs resources, when FastAPI still wins, and how CQRS patterns help you think clearly about these choices. -

-
-
- - {/* MCP Decision Framework */} -
-
-

- The MCP Decision Framework -

- -
- {/* MCP Tools */} -
-

MCP Tools 🔧

-

Use when you need to change state

- -
-

Good For:

-
    -
  • • Running searches (query changes each time)
  • -
  • • Creating/updating records
  • -
  • • Executing actions with side effects
  • -
  • • Real-time operations that need parameters
  • -
-
- -
-

Ask yourself:

-

"Does this operation need unique input each time it runs?"

-

If yes → Tool

-
-
- - {/* MCP Resources */} -
-

MCP Resources 📚

-

Use when you need to read state

- -
-

Good For:

-
    -
  • • Static or semi-static data
  • -
  • • Configuration files
  • -
  • • Documentation that doesn't change often
  • -
  • • Cacheable content
  • -
-
- -
-

Ask yourself:

-

"Can this data be cached and reused?"

-

If yes → Resource

-
-
-
- - {/* CQRS Connection */} -
-

The CQRS Connection

-

- If you're familiar with CQRS (Command Query Responsibility Segregation), this framework should feel natural: -

-
-
-

Commands (write)

-

Change state, have side effects

-

→ MCP Tools

-
-
-

Queries (read)

-

Read state, no side effects

-

→ MCP Resources

-
-
-
-
-
- - {/* FastAPI vs FastMCP */} -
-
-

- FastAPI → FastMCP: The Migration Pattern -

- -
-

- The question isn't "Should I migrate?" -

-

- The question is: "What integration point matters most to me?" -

-
- -
- {/* FastAPI Strengths */} -
-

FastAPI Strengths 🚀

-
    -
  • - ✓ - Simple setup — pip install, run server, done -
  • -
  • - ✓ - HTTP everywhere — works with any client -
  • -
  • - ✓ - Mature ecosystem — tons of middleware, auth, etc. -
  • -
  • - ✓ - Flexibility — full control over implementation -
  • -
- -
-

Choose FastAPI when:

-

- You need a general-purpose API that non-AI clients will also use, or when you need full control over auth, rate limiting, and middleware. -

-
-
- - {/* FastMCP Strengths */} -
-

FastMCP Strengths ⚡

-
    -
  • - ✓ - Native IDE integration — Claude Desktop, Cursor, Zed -
  • -
  • - ✓ - Resource caching — built into the protocol -
  • -
  • - ✓ - Standard discovery — servers are auto-discoverable -
  • -
  • - ✓ - Context-aware — designed for AI workflows -
  • -
- -
-

Choose FastMCP when:

-

- Your primary users are AI applications/IDEs, you want standardized tool/resource patterns, or you're building for the MCP ecosystem. -

-
-
-
- - {/* The Hybrid Approach */} -
-

💡 The Hybrid Approach

-

- You don't have to choose! Many production systems run both: -

-
    -
  • • FastAPI for your main application and web clients
  • -
  • • FastMCP server for IDE/AI integration
  • -
  • • Both calling the same business logic layer
  • -
-

- This is often the right answer for production systems that need broad compatibility. -

-
-
-
- - {/* Real-World Scenarios */} -
-
-

- Real-World Decision Scenarios -

- -
- {/* Scenario 1 */} -
-

- Scenario 1: RAG System with Vector Search -

-

- "I have a RAG system where users search documentation. Should the search endpoint be FastAPI or FastMCP?" -

-
-

Recommendation: FastMCP Tool

-

- Why: Each search query is unique (dynamic input), and if you're using Claude/IDEs, - MCP gives native integration. The search results aren't cacheable since the query changes. -

-

- But consider FastAPI if: You need the API for a web frontend too, or you have complex authentication needs. -

-
-
- - {/* Scenario 2 */} -
-

- Scenario 2: LangSmith Trace Analysis -

-

- "I want to query my LangSmith traces from Claude Desktop. Tool or Resource?" -

-
-

Recommendation: MCP Resource

-

- Why: Traces are historical data (read-only), they don't change frequently, - and caching can significantly improve performance. Resources are perfect for this. -

-

- Use a Tool for: Creating new traces, updating metadata, or running analytics that need parameters. -

-
-
- - {/* Scenario 3 */} -
-

- Scenario 3: Multi-Agent Orchestration -

-

- "I'm building a multi-agent system with LangGraph. How do I expose agent capabilities?" -

-
-

Recommendation: Hybrid Approach

-

- MCP Tools for invoking agents (dynamic, stateful operations) -

-

- MCP Resources for agent configurations, schemas, available tools -

-

- Consider FastAPI if you need a REST API for monitoring dashboards or external integrations -

-
-
-
-
-
- - {/* Code Examples Link */} -
- -
- - {/* Questions Section */} -
-
-

- Still Have Questions? -

-
-

- These architectural decisions depend heavily on your specific use case. If you're a student in one of my bootcamp cohorts, - bring your scenario to office hours. If not, feel free to reach out: -

- -
-
-
- - ); -}; - -export default ConceptsPage;