The Course, the One App, and the Spine
2026-10-14
Emmanuel BRUNO — Associate Professor, University of Toulon (Information System Laboratory, LIS — UMR CNRS 7020).
Contact: course Discord channel (preferred for quick questions) · email emmanuel.bruno@univ-tln.fr.
One app, extended layer by layer, into a full review layer.
Goal. By the end of the course you can build and reason about a complete full-stack web application — a modern React frontend talking to a Node.js/Express REST API backed by MySQL — and you can keep extending it.
Audience. L3 / 3rd-year undergraduate students. A programming background is assumed. If you come from PHP, your server-side instincts (routing, sessions, database queries) transfer directly; we apply them in the JavaScript ecosystem.
Shape: 18 hours = 6 sessions × 3 h. Each session is a mix of short lecture and hands-on work, always on the same application.
🤖 AI-first, Day 1
We start with an AI assistant (e.g. GitHub Copilot, Cursor, or similar) and LLMs before refreshing the fundamentals. They accelerate learning and mirror how professional teams work — but they never replace understanding the code. You will always be able to explain what you shipped.
README.md + LLM_Usage.md + video demo — due 1 month after the last session.The one-app spine
fullstack-minimal-app is the only running example in this course. We do not build a toy app and throw it away, then start another. We take one real, working application and grow it. Understand it → extend it layer by layer → capstone: build the review layer.
What it is. A minimal but complete, production-minded full-stack application:
It is deliberately small enough to read end to end, but complete enough to be real: a product catalog with categories, pagination and filtering, full CRUD, input validation, SQL-injection protection, health monitoring, and Docker-first development.
The working catalog you will extend. You start from code that already runs. The frontend is a React single-page app; its source is small and fully inspectable:
frontend/src/main.jsx — the React entry point (mounts the app).frontend/src/App.jsx — the main component: client-side routing and a backend health check.frontend/src/components/ProductList.jsx — the paginated product listing.frontend/src/components/ProductDetail.jsx — the single-product view.frontend/src/components/ProductForm.jsx — the create / edit form.frontend/src/styles.css — Tailwind imports.The backend exposes a REST API (/api/products with GET/POST/PUT/DELETE, /api/categories, and a /health endpoint) that reads and writes a MySQL database (minimal_app_db, seeded by db/init.sql).
Your job is to extend this catalog — never to rebuild it from scratch. Every lesson adds one layer on top of what is already working.
The course is one arc, in one order: understand the shipped catalog → add the review layer session by session → capstone. The product catalog is the given foundation — you never rebuild it. The course adds a review layer to an existing product catalog, milestone by milestone (S0–S5); connecting that layer to the external review source (the shipped scraper-service) is the home stretch, done after the course — never wired inside the 18 hours.
flowchart TD
A[🧭 S0: Understand the shipped catalog] --> B[🃏 S1: Static review card]
B --> C[📋 S2: Vanilla-JS review list]
C --> D[🧩 S3: React review components]
D --> E[🧰 S4: Express review routes]
E --> F[🏁 S5: Capstone: MySQL reviews table]
F -. home stretch (1 month) .-> G[🔗 scraper-service integration]
style F fill:#90EE90
| Session | What you build — the review layer on the shipped catalog |
|---|---|
| S0 | Understand the shipped catalog — the working app and its dev environment (this lecture). |
| S1 | Static review card — one review, presented by hand in HTML/CSS. |
| S2 | Vanilla-JS review list — render and filter reviews from a local JSON file. |
| S3 | React review UI — ReviewCard, ReviewList and ReviewForm built in React, fed with sample data. |
| S4 | Express review routes — GET /api/products/:id/reviews (plus the aggregate endpoint) over an in-memory store. |
| S5 | 🏁 Capstone: the MySQL reviews table — full frontend → API → DB wiring, the integration seam for the shipped scraper-service (connected in the home stretch). |
The home stretch is not in the 18 h
Wiring the shipped scraper service into a multi-source review aggregator is the one-month home stretch you do after the course, as part of the team project. During the 18 hours you build the review layer yourself; in the home stretch you connect it to the scraper-service/ shipped with fullstack-minimal-app.
You will work in a git repository for the whole course. Git — a version control system — is the safety net: every piece of work you commit can be inspected, reverted, or restored, and it doubles as a record of how the app grew. You do not need to master git to take the course, but you do need to be comfortable with the small daily loop below.
fullstack-minimal-app.The daily loop is edit → stage → commit → push: you change files, mark the ones you want to keep (git add), record them as a commit, and push the commit to the remote repository so it is backed up and shared.
flowchart TD
A[Edit a file] --> B[Stage it: git add]
B --> C[Commit: git commit]
C --> D[Push: git push]
How this course uses GitHub. The course lives in a single repository. At the end of each session, the work you produced is committed to the course repo — your progress is the commit history, not a pile of loose files. This also closes the AI-first loop: the generate → verify → integrate cycle always ends with a commit, so AI-assisted code enters the app only once it is reviewed and checked in.
A compact, mandatory refresher — just enough to place every concept we will use.
A web app is a client (the browser) talking to a server over HTTP. The client renders and collects input; the server validates, runs the business logic, and persists data.
graph
subgraph Client["Client (browser)"]
A[HTML/CSS<br/>Presentation]
B[JavaScript<br/>Interaction]
end
subgraph Net["Network"]
D[HTTP/HTTPS]
end
subgraph Server["Server"]
E[Node.js / Express<br/>App logic]
F[MySQL<br/>Persistence]
end
A --> D
B --> D
D --> E
E --> F
A SPA loads one HTML shell and then updates the UI in place — without full page reloads — by fetching data (JSON) from an API. Our catalog is an SPA: App.jsx sets up the routes, and components like ProductList and ProductDetail swap in as you navigate. SPAs give a smooth, app-like experience; the trade-off is that first load needs JavaScript, which is why SEO matters for public pages.
Optional depth. Read this only if you want the wider landscape before we commit to our stack.
SPA vs SSR vs SEO
Common solution patterns
Choosing a stack (quick guideline)
Our minimal full-stack stack
Why this stack for learning. One language (JavaScript) across front and back reduces context-switching; it is JSON-native and API-first; and it maps to a large job market. Once you understand React + Express + a relational database, moving to TypeScript, SSR/hybrid frameworks, or a different backend is mostly translation.
We develop inside a devcontainer — a Docker container that gives everyone the same tooling — and we run the app with Docker Compose. The compose file starts the services the app needs; for daily development you open the project in the container and use npm run dev.
Clone the default branch; do not add -b develop to the command.
| Service | What it is | Host port |
|---|---|---|
mysql |
MySQL 8.0 database (minimal_app_db, seeded by db/init.sql) |
3306 |
backend |
Express REST API (Node.js) | 4000 |
frontend |
React + Vite dev server | 5173 |
scraper |
Mock external review API (home stretch only — use the shipped service) | 5000 |
docker compose up --build.npm install (if needed) then npm run dev. Hot reload is on: save a file, see the change.http://localhost:4000/health).Two common hiccups
0.0.0.0, not localhost. Check VITE_HOST=0.0.0.0 in frontend/.env.5173, 4000, or 3306 (stop a local MySQL or other container) or change the mappings in docker-compose.yml.E. Bruno - Introduction — Full-Stack Web Development