Full Stack Development: Classroom Bootcamp

An eight-hour classroom bootcamp on full stack development with Django and React, taught on Smarter’s web console, where Django hosts each React app and React calls back into Django’s REST API. Every list page in the console is built the same way: a Django view and template render a root element with the session’s details as data attributes, a template tag reads Vite’s build manifest, and the React app calls back into session-authenticated views to list, clone, rename and delete. The chat goes further, with a Pydantic contract that is exported as a JSON Schema and turned into TypeScript types, so both sides of the stack share one definition. Students follow a feature from database column to pixel, and add one of their own. See Course Formats and Grading for the standard bootcamp day, the grading scale and the course policies, and Full Stack Development with Django and React for an overview of the subject.

At a Glance

Students

Developers who know some Python and some JavaScript, and want to connect a back end to a front end in a real application.

Deployment

Each student runs Smarter from source, installed and working before the bootcamp, with make react-install done.

Cost

Free, apart from small model charges.

Learning Objectives

By the end of the bootcamp, students can:

  1. Explain how Django serves a React app: view, template, root element, build manifest and static files.

  2. Trace a feature from a Django model, through a REST endpoint, to a React component.

  3. Explain session authentication and CSRF between a React front end and a Django back end.

  4. Add a field that travels from the database to the screen, with tests on both sides.

  5. Explain how a typed contract, published as a JSON Schema from Pydantic models, keeps a front end and a back end in agreement.

Technical Prerequisites

  • Required: Python (classes, decorators, type hints) and JavaScript (modules, promises, async/await).

  • Required: basic Django (models, views, URLs) or completion of the backend course, and basic React (components, props, state) or the front end course.

  • Required: Git, the command line, Docker basics, HTTP and JSON.

  • Required: Smarter installed from source and running before the bootcamp (see the Developer Setup Guide), with a screenshot of docker ps sent beforehand.

  • Helpful: TypeScript, and the browser’s network panel.

Schedule

The files that the lectures refer to are listed in full under Smarter in the Source Code.

Block

Min

Content

1

45

Lecture 1: Architectures for full stack apps. Server-rendered pages, single-page apps, and the hybrid that Smarter uses: Django pages that each host a small React app. Trade-offs of each.

2

45

Lab 1: Follow a page. Follow one list page from its Django URL, view and template, through the Vite build manifest, to the React component and the API it calls, using the browser’s network panel. Produces Assignment 1.

3

45

Lecture 2: Hosting React in Django. The view, template and template tag that render the root element and its data attributes, the Vite manifest, collectstatic, and what goes wrong when the manifest is missing: an empty page, no console error, and a template tag that has cached the absence. Django-React Integration.

4

45

Lab 2: Break it and fix it. The instructor gives each pair a broken page (a missing manifest, a wrong data attribute, a stale build). Diagnose and fix it. Produces Assignment 2.

5

45

Lecture 3: Talking to the API. Session authentication, CSRF tokens, fetchDjangoUrl and SessionContext in smarter-common, and the list, clone, rename and delete API contract that every list page uses.

6

45

Lecture 4: Typed contracts. How the chat API contract is defined as Pydantic models, published as a JSON Schema, and turned into TypeScript types (The Chat API Contract). What this prevents.

7

45

Lab 3: Database to pixel. Add a field that already exists on a model to a list page: serializer, API response, TypeScript type, column, story and test. Produces Assignment 3.

8

45

Lecture 5: Testing both sides. Django tests for the API, Vitest and MSW for the component, and keeping mocks honest.

9

45

Lab 4: Rebuild and verify. Run make react-build, restart the app, and verify the new column in the real console. Ungraded.

10

45

Lecture 6: Shipping it. Builds in CI, static files in production, caching, and how a front end change reaches users.

11

30

Capstone kickoff. Students choose a capstone, branch, and list every file they expect to change.

Smarter in the Source Code

Every lecture, lab and assignment in this course follows features through the files below, from the database to the browser. Every reference is to the main branch of github.com/smarter-sh/smarter, or of github.com/smarter-sh/smarter-chat where named, so that students can open each one during class. Python paths are under smarter/smarter/.

One List Page, Database to Pixel

The guardrail list page is the reference. Every list page in the console is built the same way.

Step

What happens

Where to look

The model

The Guardrail Django model, owned by an account and a user.

guardrail/models/guardrail.py

The sidebar link

The console’s navigation, a Django template.

templates/dashboard/sidebar.html

The URLs

The page itself, and the react-integration/api/ endpoints that the React app calls to list, clone, rename and delete.

guardrail/urls.py

The Django view

Builds the page’s context: the root element’s id, the CSRF and session cookie names, the cookie domain and the API’s URL.

guardrail/views/listview/view.py

The template

Renders the root element with those values as data attributes, and the app’s scripts and styles.

templates/react/guardrail-list.html

The template tag

Reads the Vite build’s manifest.json, validated by Pydantic models, to find the hashed file names of the app’s assets. A missing manifest renders an empty page without an error, and is cached, which is the classic failure of this design.

guardrail/templatetags/react_guardrail_list.py, lib/django/templatetags/smarter_react_contract.py

The React entry point

Reads the data attributes into a SessionContext and mounts the app on the root element.

smarter-guardrail-list/src/main.tsx

The API call

fetchDjangoUrl posts to Django with the session cookie and the CSRF token.

smarter-common/src/lib/django.tsx

The server’s answer

Session-authenticated, never-cached views that list the guardrails a user owns or can see, and clone, rename or delete one.

guardrail/views/listview/api.py

The pixels

The list and card views, the toolbar and the status bar, with typed API objects.

smarter-guardrail-list/src/components/, src/lib/Types.tsx

The pattern, written down

The view, template, template tag, data attributes, SessionContext, the list, clone, rename and delete contract, the Vite build, and the sidebar link, as a checklist.

smarter-django-react/SKILL.md

A Typed Contract Across the Stack

Step

What happens

Where to look

Pydantic models

The chat API’s requests and responses, defined once on the server.

prompt/contract/models.py

JSON Schema

Exported by a management command, committed, and tested to be current.

prompt/contract/schema.py, chat-contract.schema.json

Copied to the client

make chat-contract regenerates the schema and copies it into the chat’s repository.

Makefile (chat-contract)

TypeScript types

Generated from the schema, and tested against example payloads.

smarter-chat: src/contract.gen.ts

Building, Testing and Shipping

Topic

What Smarter does

Where to look

Builds

make react-build builds every app with Vite, collects static files and rebuilds the image. make build alone reuses the old static files, so a new page renders empty.

Makefile (react-build)

Testing the back end

Shared mixins that test any resource’s list, clone, rename and delete views.

lib/unittest/resource_views.py, guardrail/tests/test_views.py

Testing the front end

Vitest and Testing Library, with MSW handlers and fixtures that mirror the server’s responses.

smarter-guardrail-list/src/mocks/, src/App.test.tsx

CI

The python and react jobs, run side by side.

test.yml

Embedded apps

A deployed LLMClient’s chat can be embedded on another site, and only the origins listed in its manifest’s allowedOrigins may call it.

llmclient/cors.py

Graded Assignments

Assignment 1: Page Trace

Students document how one list page reaches the screen, from URL to React component, and every API request it makes.

Turn in: a diagram and a Markdown explanation in their fork, with network panel screenshots.

Criterion

Pts

Exemplary

Developing

Server side

6

URL, view, template, template tag and static files, with file names.

Steps missing.

Client side

6

Entry point, components and API calls.

Components only.

Evidence

4

Network panel confirms each request.

Inferred.

Clarity

4

A newcomer could follow it.

Hard to follow.

Assignment 2: Diagnosis Report

Pairs diagnose and fix the broken page they are given, and write up the symptom, the cause, how they found it, and how to prevent it.

Turn in: a one-page report and the fix.

Criterion

Pts

Exemplary

Developing

Fixed

6

The page works.

Partly working.

Root cause

6

Correct and specific.

Symptom fixed, cause unclear.

Method

4

Describes the evidence that led to the cause.

“We tried things until it worked”.

Prevention

4

A realistic check that would catch it.

None.

Assignment 3: Database to Pixel

Students expose an existing model field on a list page, end to end, with a Django test and a Vitest test.

Turn in: a pull request against their fork.

Criterion

Pts

Exemplary

Developing

End to end

7

Serializer, API, type, component and story all updated.

A layer missing.

Tests

6

Both sides tested; mocks match the real response.

One side only.

Verified

3

Shown working in the real console after a rebuild.

Storybook only.

Quality

4

Pre-commit, ESLint and Prettier pass.

Hooks fail.

Capstone Projects

Students choose one. Capstones are due one week after the bootcamp, as a pull request against their fork.

Capstone A: A Full Stack Feature on a List Page

Learning objective. Deliver a feature that needs coordinated back end and front end changes, tested on both sides.

Students add a server-side feature with a front end to a list page, for example filtering by tag (a query parameter on the API, a filter control on the page), or a “duplicate with new name” action with validation errors shown in the dialog.

What students turn in:

  • A pull request with Django and React changes, Django tests, Vitest tests and stories.

  • A screen recording in the real console.

  • A half-page design note on the API change.

How it is graded (100 points):

Criterion

Pts

Exemplary

Developing

Back end

25

Correct, efficient, scoped to the user’s account, consistent errors.

Works, but unscoped or inconsistent.

Front end

20

All states handled; accessible controls.

Happy path only.

Contract

15

Front and back agree; types and mocks match the real API.

Mocks drift from the API.

Tests

25

Both sides, including errors.

One side only.

Pull request

15

Clear description, recording and design note.

No description.

Capstone B: A Typed Contract for a List Page

Learning objective. Apply the typed-contract pattern from the chat API to another part of the application, and show the class of bugs it prevents.

Students define one list page’s API response as a Pydantic model, publish its JSON Schema, generate TypeScript types from it, use them in the React app, and add a test that fails when the committed schema is out of date.

What students turn in:

  • A pull request with the Pydantic model, schema, generated types, React changes and tests.

  • A demonstration that renaming a field on the server breaks the build or a test.

  • A one-page note comparing this with hand-written types.

How it is graded (100 points):

Criterion

Pts

Exemplary

Developing

Pydantic model

20

Matches the real response exactly, no Any.

Loose types.

Schema and types

20

Generated, not hand-edited, and used by the component.

Generated but unused.

Freshness test

20

Fails when the schema is stale.

No test.

Demonstration

20

A server change is caught before it reaches users.

Not demonstrated.

Note

20

Weighs the benefits against the extra build step.

One-sided.

Further Study