Lesson Complete!

What you learned

• Why hardcoded settings create problems across different environments and why configuration belongs in environment variables
• How to use Pydantic's BaseSettings to define typed, validated configuration with .env file support
• How to replace hardcoded values with settings so your app can be configured without changing code
• Why unhandled exceptions should return a consistent JSON response instead of exposing internal details
• How to add a global exception handler that catches any error and returns a safe 500 response
• How to use unittest.mock.patch to trigger errors in tests

Congratulations

You hardened your expense tracker API. It now has automated tests for every endpoint, request logging middleware, atomic file writes, CORS headers, environment-based configuration, and a global exception handler. These are the same patterns used in production APIs — you built them from scratch, one piece at a time.

What comes next

Your API is tested, configured, and handles errors gracefully. But it still saves everything to a JSON file. That works for a personal project — until you need to search expenses by date range, generate monthly spending reports, or handle multiple users at once.

The next course in this path picks up where you left off. You will swap the JSON file for a real database — and unlock queries that would take dozens of lines of Python in just one statement.

Same expense tracker. Same codebase. A much more powerful backend.

Ready to add a database? Add a Database to Your API picks up right where this course ends — same expense tracker, same codebase. You will swap the JSON file for SQLite and unlock queries that would take dozens of lines of Python in a single statement.