Backend Development with Python, Django, Django REST Framework and Pydantic

Why Smarter. Tutorial projects teach Django one feature at a time, on a blog or a to-do list, and stop before the problems that real backends face. Smarter is a large Django project in production that follows the community’s conventions closely, and its eighteen Django apps in smarter/smarter/apps/ follow one deliberately rigid structure, so that once students understand one app they can read them all. The guardrail app is the reference: a Django model, a Pydantic manifest, a broker, serializers, API views, signals, receivers and one test module per source module, each in the same place in every app.

It shows the patterns that small projects never reach, each in code that students can open:

  • A broker layer that turns a YAML manifest into database rows and back, behind one REST API for every kind of resource. See the abstract broker, the registry of kinds and Smarter Broker Model.

  • Pydantic for every contract: manifests, API responses and the Settings class that validates every environment variable (ADR 031).

  • Ownership and multi-tenancy: an abstract base model that makes every resource belong to an account and a user, with permission-aware querysets.

  • Work outside the request: Celery workers on named queues and a beat schedule that aggregates charges and enforces budgets; caching with @cache_results; and management commands built on a shared SmarterCommand base class.

  • Tests at scale: more than five thousand unit tests, a SmarterTestBase with no transaction rollback, and an in-memory provider that replaces every cloud call.

The reasons behind these choices are written down in the Architecture Decision Records, so students learn why as well as how.

What the course covers. Installing Smarter from source and working with its containers; Django in one picture: projects, apps, settings, URLs, middleware, views, models and the ORM; querysets, relationships, aggregation and the N+1 problem; Django REST Framework, authentication and permissions; errors, versioning and API documentation; Pydantic, manifests and brokers; models and migrations, including when to add a migration rather than regenerate one; testing Django, with fixtures, mocks and coverage; management commands; Celery tasks, queues and the beat scheduler; and caching and performance. The longer plans end with a new resource kind, delivered as a pull request.

Look at.

Each course plan lists every file that it uses, layer by layer, under Smarter in the Source Code.

Read. Smarter Broker Model, Smarter API, Pydantic, Getting Started (a reading list for these technologies), New Feature Checklist.

Exercises.

  • Trace one smarter apply request from the URL route, through the DRF view and the broker, to the Django model, and draw a sequence diagram.

  • Add a field to an existing resource’s manifest: the Pydantic model, the Django model and its migration, the broker, and the tests.

  • Write a manage.py command, following smarter/smarter/apps/account/management/commands/.

  • As a capstone, add a new resource kind end to end, following New Feature Checklist.

Course plans. Three complete, ready-to-teach plans, each with a schedule, graded assignments and rubrics, two capstone projects, recommended texts, further study and technical prerequisites. See Course Formats and Grading for what the formats have in common.

See the Smarter Instructor Guide to install Smarter and set up a class.