Architect the Daily Grind API

In this lab, you will direct Claude in the Architect role to draft a formalized development plan for an expanded version of The Daily Grind backend, and you will act as the Product Manager who reviews, questions, revises, and finally approves that plan. Planning an API before writing it is a core professional skill: teams that agree on routes, data sources, middleware, and error behavior up front build faster and argue less. This lab is also direct preparation for the SBA, where you will implement a RESTful server of your own. Estimated time: 45 minutes (asynchronous).

Scenario

The owner of “The Daily Grind” coffee shop has been thrilled with your work. The static site from Lab 1 brings in customers, and the fun-fact endpoint from Lab 2 is a hit on the in-shop display. Now the owner wants a real backend: a menu that staff can manage, an ordering system for the shop’s tablet, and the existing features carried forward, all organized the professional way you learned in Lesson 7.

Before anyone writes a line of code, the owner wants a formal development plan they can share with a part-time developer who will help build it. You will not draft this plan alone. You will delegate the drafting to Claude, acting as your Architect, while you play the role every AI-era developer must master: the accountable human reviewer who owns the final decision.

Learning Objectives

By the end of this activity, you will have demonstrated your ability to:

• Direct an AI assistant in the Architect role to produce a formalized development plan for an Express application.
• Audit a proposed project structure and RESTful route map against the standards taught in this module.
• Request targeted, well-reasoned revisions and verify that each revision was applied correctly.
• Produce professional planning artifacts (DEVELOPMENT_PLAN.md and REVIEW_LOG.md) that a development team could execute.

The AI Role in This Lab: Architect

This course practices three distinct ways of working with AI: AI as Socratic Tutor, AI as Architect, and AI as Builder. This lab uses AI as Architect. In this role, the AI drafts plans, scaffolding structures, schemas, and architecture documents, and you act as the Product Manager: you review, question, request revisions, and approve. The AI never writes implementation code in this role, and neither do you. The deliverable is a plan, not a program.

To enforce this role, you will give Claude the following instruction before any other prompt. Copy it exactly:

You are acting as the software Architect for this project, and I am the
Product Manager. Your job is to produce planning documents only: directory
structures, route tables, middleware plans, and build orders. Do not write
implementation code in this conversation, even if a question could be
answered with code; respond with structure, tables, or plain explanations
instead. Present each draft for my review, wait for my feedback, and revise
until I approve. I make the final decisions.

The Product Brief

This is the brief you will hand to the Architect. Read it carefully first, because you cannot review a plan against requirements you have not internalized. You will paste this text into your prompt in Part 2.

Product Brief: The Daily Grind API, Version 2

The Daily Grind coffee shop has an Express server that serves two static
pages (a homepage and a contact page) from a public/ directory and exposes
one API route, GET /api/fun-fact, which proxies a random fact from the
external Useless Facts API
(https://uselessfacts.jsph.pl/api/v2/facts/random). The owner now wants a
full backend with the following requirements:

1. Static pages: the existing homepage and contact page must continue to
   work.

2. Menu resource: the API must support listing all menu items, retrieving a
   single menu item by its id, creating a new menu item, updating an
   existing menu item, and deleting a menu item. A menu item has a name, a
   description, a price, and a category (drink or food).

3. Orders resource: customers place orders through the shop's tablet. The
   API must support creating an order, retrieving a single order by its id,
   and listing orders filtered by status (for example: pending, ready, or
   completed). An order has a list of menu item ids, a customer name, and a
   status.

4. Fun-fact proxy: keep GET /api/fun-fact. It must translate upstream
   errors properly: if the external API cannot be reached or returns a
   server error, respond with 502 Bad Gateway and a clean JSON error
   message. Never leak the raw upstream error to the client.

5. Admin protection: creating, updating, and deleting menu items are admin
   operations. They must be protected by an API key middleware that checks
   a key supplied by the client against a secret stored on the server.
   Customer actions (viewing the menu, placing an order, checking an
   order) must NOT require the key.

6. Configuration: the admin API key and the server port must live in a
   .env file that is excluded from version control.

Out of scope: databases (plan for in-memory arrays), user accounts,
payments, and any front-end work beyond the existing static pages.

Notice one thing the brief does not decide: whether listing all orders by status requires the admin key. Is that a barista-only screen or a public order board? That is a product decision, and product decisions belong to you, not the Architect. You will make this call during your review and document your reasoning in REVIEW_LOG.md.

Instructions

Part 1: Setup (5 minutes)

1. Create a project directory and initialize a Git repository:

   mkdir daily-grind-architecture
   cd daily-grind-architecture
   git init

2. Create a new, empty repository on GitHub named daily-grind-architecture, then connect it:

   git remote add origin https://github.com/<your-username>/daily-grind-architecture.git

3. Choose your tool. Either path produces the same deliverables.

   Option A: claude.ai (recommended for this lab). Sign in at https://claude.ai  with your Per Scholas-provided Claude Pro account. Create a Project named Daily Grind Architect and paste the Architect role prompt from above into the Project’s custom instructions, so the role applies to every conversation in the Project. If you prefer not to use a Project, start a new chat and send the role prompt as your very first message instead.

   Option B: Claude Code. If you have not installed it yet, run:

   npm install -g @anthropic-ai/claude-code

   Then start it inside your project directory by running claude, and log in with /login using your Per Scholas-provided account if prompted. Press Shift+Tab to cycle permission modes until Plan Mode is active. In Plan Mode, Claude Code proposes a plan without editing any files, which is exactly the constraint the Architect role requires. Send the role prompt from above as your first message as well, so the conversation rules are explicit.

Part 2: Brief the Architect (10 minutes)

1. Confirm the role prompt is in place (as the Project’s custom instructions, or as the first message of your chat or Claude Code session).

2. Send the planning request below, pasting the full product brief where indicated:

   Here is the product brief for The Daily Grind API, Version 2.
   
   [paste the full product brief here]
   
   Draft a formalized development plan as a single Markdown document with
   these four sections:
   
   1. Proposed directory and file structure, including server.js, routes/,
      controllers/, middleware/, public/, .env, and .gitignore, with a
      one-line purpose note for each file.
   
   2. A RESTful route table with one row per endpoint and these columns:
      HTTP method; path; where the endpoint reads client data (req.params,
      req.query, or req.body, or none); success status code; error
      responses (status code and the condition that triggers each); the
      controller function that handles it; and any middleware applied to
      that route. Include the upstream error translation for the fun-fact
      proxy route.
   
   3. A middleware plan: each middleware, what it does, which routes it
      applies to, and the exact order it is registered in, with a sentence
      justifying that order.
   
   4. A build order: the sequence of milestones you recommend for
      implementing this plan, with a short rationale for the sequence.
   
   Do not write any implementation code. This is a planning document.

3. Read the entire draft once, top to bottom, before responding. Do not evaluate yet; just make sure you understand every row. To calibrate your expectations, one row of a well-formed route table looks like this:

   Method	Path	Client Data	Success	Errors	Controller	Middleware
   GET	/api/fun-fact	none	200	502 when the upstream API fails	getFunFact	none

   If any part of the draft is unclear, ask the Architect to explain its reasoning before you begin the formal review. An Architect who cannot justify a decision has not finished making it.

Part 3: Product Manager Review (15 minutes)

Now audit the draft against the standards this module taught you. Work through the checklist in order.

Architect drafts commonly contain real flaws. Hunt specifically for these:

• Over-protection: the API key required on public reads like GET /api/menu.
• Under-protection: DELETE /api/menu/:id left open.
• Wrong data source: an id passed as a query string instead of a route parameter.
• Ordering mistakes: express.json() mounted after the routers that need it.
• Scope creep: databases, login systems, or extra resources the brief ruled out.
• Vague error rows: a route table that lists a success code but no error conditions.

Then complete these steps:

1. Identify at least two concrete problems or improvements. If the draft is genuinely strong, improvements still count: a missing error condition, an unjustified middleware order, a build milestone that is too large, or the undecided question of whether listing orders requires the admin key.

2. Send each revision request as its own follow-up prompt, and make it specific. Compare:

   • Weak: “Fix the middleware.”
   • Strong: “In the route table, POST /api/orders reads the order from req.body, but your middleware plan registers express.json() after the routers are mounted. Move express.json() above all router mounts and update the ordering justification, since body parsing must happen before any handler reads req.body.”

3. Verify each revision. Re-read the affected section of the new draft and confirm the change was actually made and made correctly. Architects, human and AI alike, sometimes revise the paragraph you pointed at while quietly breaking a neighboring one.

4. Make the order-listing protection decision yourself. If the Architect already chose, decide whether you agree. Somewhere in this review, there must be at least one decision where you overrode, rejected, or ruled against the Architect’s recommendation, with a reason. If you agree with everything, push harder: ask the Architect for two alternative approaches to one decision (for example, 401 versus 403 for a failed key check, or where the in-memory arrays should live) and choose between them yourself.

5. Iterate until you would sign your name to this plan and hand it to a development team.

Part 4: Formalize and Deliver (10 to 15 minutes)

1. Save the approved plan as DEVELOPMENT_PLAN.md in your project directory.

   • Option A (claude.ai): ask the Architect for the final approved plan as a single clean Markdown document, then copy it into the file.
   • Option B (Claude Code): exit Plan Mode (press Shift+Tab to cycle modes) and ask Claude Code to write the approved plan to DEVELOPMENT_PLAN.md. It will ask permission before creating the file; read the request and approve it deliberately.

2. Create REVIEW_LOG.md and fill it out using this template:

   # Review Log: The Daily Grind API Development Plan
    
   ## Tool Used
    
   (claude.ai or Claude Code, and whether you used a Project.)
    
   ## Prompts
    
   (The role prompt, the planning request, and any follow-up prompts you
   sent. If conversation sharing is enabled in your workspace, you may also
   include a shared link to the conversation here.)
    
   ## Revision Requests
    
   ### Revision 1
    
   - What I asked the Architect to change:
   - Why (the lesson or REST principle behind it):
   - What changed in the plan as a result:
    
   ### Revision 2
    
   - What I asked the Architect to change:
   - Why (the lesson or REST principle behind it):
   - What changed in the plan as a result:
    
   ## Disagreement
    
   (One decision where you overrode or rejected the Architect's
   recommendation, including the order-listing protection call if that was
   yours, and your rationale.)
    
   ## Reflection
    
   (Two or three sentences: where the Architect saved you time, and where
   your own judgment was required.)

3. Commit and push both files:

   git add DEVELOPMENT_PLAN.md REVIEW_LOG.md
   git commit -m "Add approved development plan and review log"
   git branch -M main
   git push -u origin main

Optional Stretch: Scaffold the Skeleton with Claude Code

If time permits, turn the plan into an empty project skeleton. In Claude Code (out of Plan Mode), send:

Create the directories and empty files exactly as listed in
DEVELOPMENT_PLAN.md. Do not write any implementation code; each file should
be empty or contain only a one-line comment naming its purpose.

Review each permission request before approving it. When Claude Code finishes, run git status to confirm the created files match the plan exactly, stage them, and review with git diff --staged before committing. If anything does not match the plan, tell Claude Code precisely what to correct. Push the scaffold with your other files.

Reflection Questions

After completing this activity, consider the following:

1. Where did the Architect save you time compared with drafting the plan yourself, and where did it require your correction? What does that tell you about which work to delegate?
2. The SBA asks you to build a RESTful, routes-and-controllers-structured API under time pressure. How would writing a route table like this one first change how you approach that build?
3. Why must the Product Manager, not the Architect, own the decision about which routes the API key middleware protects? What could go wrong if that decision were left to a tool that does not know the business?

Submission Guidelines

Submit a link to your daily-grind-architecture GitHub repository on Canvas.

This lab is graded complete/incomplete. To receive a complete, your repository must show all of the following:

1. DEVELOPMENT_PLAN.md contains a proposed file and directory structure and a complete RESTful route table specifying, for every endpoint: HTTP method, path, client data source (req.params, req.query, req.body, or none), success status code, error responses with their conditions, the controller function name, and any middleware applied.
2. REVIEW_LOG.md documents the prompts you used, at least two substantive revision requests with the rationale for each, one documented point of disagreement with the Architect, and your short reflection.
3. The routes in the final plan follow RESTful conventions: resource nouns in paths, correct HTTP verbs, and the correct choice of req.params versus req.query versus req.body for each endpoint.
4. The plan externalizes the admin API key and port into a .env file listed in .gitignore, as taught in Lesson 7.

The optional scaffold is not required for a complete, but if you include it, the file structure must match DEVELOPMENT_PLAN.md exactly.