7. Evaluation and submission

Self-evaluation is the last step before you ship. Walk the rubric end-to-end, find the weakest dimension, and spend your remaining time there. Ship when it's good enough that you'd be proud to send a link to a hiring manager.

Completion checklist

The checklist below is the audit pass before you call the project done. Walk it once with the deployed system open in a browser tab; anything you can't verify by running it counts as not done. The top-level groups map directly to the rubric in §3 below.

  • Core requirements (all must be true). External APIs:
  • NewsAPI integrated with API key authentication
  • Guardian API integrated (API key in query parameter)
  • Reddit API integrated with OAuth 2.0
  • One internal article shape across all three sources
  • Error handling for upstream API failures

Database

  • PostgreSQL schema with all tables (users, articles, preferences, etc.)
  • Alembic migrations working
  • Full-text search index implemented
  • Proper relationships and constraints

Application API

  • FastAPI with 5+ endpoints
  • Pydantic validation on all inputs
  • Error responses (4xx, 5xx) with clear messages
  • Validated limit query parameters on list endpoints (covered in Chapter 26); full pagination is a stretch goal beyond the book
  • API documentation at /docs

Authentication

  • OAuth 2.0 authorization flow
  • Token exchange working
  • API-key authentication on your own protected endpoints (covered in Chapter 26); issuing your own JWTs is a stretch goal beyond the book
  • Protected endpoints requiring authentication

Caching

  • Redis integration
  • Cache-aside pattern implementation
  • TTL configuration (5-15 minutes)
  • Demonstrable performance improvement

Testing

  • 70%+ code coverage
  • Unit tests for business logic
  • Integration tests for endpoints
  • API client tests

Containerization

  • Multi-stage Dockerfile
  • Docker Compose for local development
  • All services (API, PostgreSQL, Redis) working together

AWS deployment

  • ECS Fargate service running
  • RDS PostgreSQL database
  • ElastiCache Redis
  • Application Load Balancer
  • Public URL accessible
  • Health checks passing

CI/CD

  • GitHub Actions workflow
  • Automated tests on PR
  • Automated deployment on push to main
  • Deployment verification

Monitoring

  • CloudWatch dashboard with Golden Signals
  • At least 3 meaningful alarms
  • Logs flowing to CloudWatch
  • Logs Insights queries documented

Documentation

  • README covering overview, quick start, API surface, deployment, performance numbers, known limits
  • Architecture diagram
  • API documentation at /docs
  • Setup instructions tested on a fresh clone
  • .env.example file with every variable the application reads

Extension (one or two shipped).

  • Extension implemented and working end-to-end
  • Extension documented in README
  • Extension demonstrated in the video
  • Extension tests included

The portfolio package

Nobody collects this package; it's what makes the project legible to a hiring manager, or to you in six months. Five artifacts:

  • 1. GitHub repository URL. Public repository, clean commit history with informative messages, .gitignore excluding secrets, an open-source license file.

2. Live deployment URL. The public ALB endpoint with /health returning 200 OK, /docs rendering the OpenAPI spec, and an example request returning real data.

3. Demo video. 5-10 minutes, uploaded to YouTube (unlisted), linked from the README.

4. Written reflection. 2-3 pages, Markdown at docs/REFLECTION.md, covering the four topics from §6.4.

5. Coverage report. HTML coverage report in the repo (htmlcov/), a coverage badge in the README, a minimum of 70%.

Self-assessment rubric

The points aren't a grade; nobody adds them up but you. Their job is to make "find the weakest dimension" concrete, so the remaining hours go where they buy the most.

  • Technical implementation (60 points). External API integration (10): all three integrated (10), two working (7), one or authentication issues (4).

OAuth 2.0 (10): complete flow including token refresh (10), basic flow without refresh (7), partial or broken (4).

Database design (10): normalised schema with indexes and migrations (10), working schema with minor issues (7), CRUD without indexing or migrations (4).

API quality (10): every endpoint validated and documented (10), most endpoints working with some validation gaps (7), endpoints present but minimal validation (4).

Testing (10): 70%+ coverage with meaningful assertions (10), 50-69% coverage (7), under 50% or assertions that don't fail on regressions (4).

Deployment (10): full AWS stack with monitoring (10), deployed but missing monitoring or auto-scaling (7), local only or broken deployment (4).

  • Engineering practices (25 points). Code quality (5): consistent structure, named clearly, no dead code (5), functional but inconsistent (3), messy (1).

Git history (5): informative commits with a clear progression (5), acceptable (3), one giant commit (1).

CI/CD (5): full pipeline with test gating and rollback (5), basic automation (3), manual deployment (1).

Monitoring (5): dashboard plus alarms with documented response paths (5), dashboard only (3), none (0).

Security (5): OAuth, secrets management, least-privilege IAM (5), partial (3), major issues (1).

  • Documentation and presentation (15 points). README quality (5): runnable from a fresh clone, includes diagram and measured numbers (5), complete but plain (3), basic (1).

Demo video (5): clear, well-paced, deployed environment visible (5), functional but rough (3), minimal or unclear (1).

Reflection (5): specific examples, honest tradeoffs (5), generic reflections (3), superficial (1).

Reading your total.

  • 90-100: the system is genuinely good. Ship as-is.
  • 75-89: solid build with one or two soft spots. Fix the weakest dimension before sharing the link.
  • 60-74: complete but has gaps. Identify the two lowest-scoring dimensions and spend the remaining time there.
  • Under 60: significant scope still open. Don't call it done yet; finish the core requirements first.

Next, in section 8, we close out the chapter and the book: the patterns this project put in place, a quiz on the load-bearing decisions, and a pointer at what to do after the capstone is shipped.