🐍 Free course
Backend with Python
Write Python services that hold up: typed, tested, async where it helps, and boring where it matters.
What you will learn
- What a backend is: request, handler, response
Every app you use is a thin screen in front of a program you never see: it reads one request, runs one function, and writes one response, millions of times a day. - HTTP properly: methods, status codes, headers, idempotency
Networks drop replies, so clients retry. Whether that retry books one cab or two is decided by the HTTP method you picked and the status codes you send. - FastAPI: your first endpoint
Thirteen lines of Python give you routing, type conversion, input checking, JSON and live docs. The skill is knowing what those thirteen lines do for you, and what they quietly don't. - Pydantic: validation as the contract
Every bad row in your database got in through a door someone forgot to check. A Pydantic model is that door, written once, enforced on every request, and published as your API's contract. - Designing a REST API people can use
An API is a promise you can't take back: the day a mobile app ships against your URLs, every odd name and wrong status code is yours to support for years. - Talking to a database: SQLAlchemy and connection pools
Opening a database connection costs a network handshake, TLS and an auth exchange — often more than the query itself — so a service that connects per request spends its time saying hello. - Migrations, and never editing a table by hand
Your laptop, CI, staging and production each hold a copy of the schema, and the only way they stay identical is if every change is a numbered, reviewed script that runs everywhere in the same order. - Auth: sessions, JWT, and what a token is not
A JWT is a signed postcard, not a sealed envelope: anyone can read it, nobody can quietly change it, and you cannot take it back once it is posted. - Async Python: when it wins and when it lies
async def makes waiting cheap, not work fast: one blocking call inside it and your whole server queues behind a single request. - Background work: queues, workers, retries
Every job queue delivers some jobs twice, so the real question is whether paying a driver twice is possible in your code. - Caching: where, how long, and how to invalidate
A cache is a copy of the truth that is allowed to be wrong for a while — your whole job is deciding how wrong, for how long, and who gets told when it changes. - Testing a service: unit, integration, and fixtures
A test suite is only worth having if it fails for exactly one reason — your code broke — and never because of the clock, the network, or the test that ran before it. - Structured logging, metrics and tracing
At 3 AM you won't have a debugger — only what your service chose to write down, so decide now what it says, in what shape, and how one request's story gets stitched back together. - Rate limiting, timeouts and backpressure
Every service has a maximum speed; the only choice is whether it says "no" early and politely, or says nothing at all while it falls over.
How the course works
- Each chapter is a short book: the basics, the explanation in several ways, the words to know, and a two-minute summary.
- Then you test yourself — quiz, puzzles — and recall it on two different days, so it stays.
- Blinks (one idea per screen), games and a daily plan keep you coming back. It is free.