How to learn backend engineering
Backend engineering has a particular failure mode: it is entirely possible to ship working features for years while understanding almost none of it. The framework handles the HTTP, the ORM handles the SQL, the auth library handles the tokens, and the gaps only show up when something breaks in a way the framework has no opinion about.
The way out is unglamorous. Learn the protocol before the framework, the SQL before the ORM, and what a session actually is before installing something that manages them. It is slower for about two weeks and then permanently faster.
01 / What backend work actually is
Almost all of it reduces to three questions. What shape is the data and where does it live. Who is allowed to ask for it. And what happens when the request fails halfway through.
The first is data modelling, and it is the decision with the longest half-life on any project. Schemas outlive the code that reads them, and a bad one is paid for by every feature built afterwards.
The second is authentication and authorisation, which are different things that get conflated. Authentication is who you are. Authorisation is what you may do. Most security incidents that make the news are the second one, missing, on an endpoint nobody thought about.
The third is where the difference between working code and production code lives. Retries, idempotency, transactions and partial failure are not advanced topics. They are what separates a system that loses data quietly from one that does not.
02 / The order that works
24 days of this path, in sequence
HTTP comes first because a backend is a program that answers HTTP requests, and every framework decision downstream is a wrapper around something in that protocol. Learn it once and every framework afterwards is a variation you can read.
- 23What actually happens when you type a URL
- 24HTTP methods, status codes, and headers
- 25JSON, REST, and the idea of an API contract
- 26JavaScript fundamentals for engineers
- 27The event loop, single-threaded and still fast
- 28Promises, async, await, and real concurrency
- 29TypeScript, and why static types exist
- 30Interfaces, unions, and generics in practice
- 31The browser, the DOM, and where state lives
- 32React's mental model
- 33Next.js routing, layouts, server and client
- 34Tracing one request through a whole app
- 35Anatomy of a backend
- 36Building an API with FastAPI
- 37Validation, serialization, and the trust boundary
- 38Authentication versus authorization
- 39Sessions, tokens, and what a JWT actually is
- 40Password hashing, CORS, and secrets
- 41Relational thinking: tables, keys, relationships
- 42SQL: SELECT, WHERE, JOIN, GROUP BY
- 43Indexes, and why a query goes from 4s to 4ms
- 44Transactions, and what ACID actually protects
- 45ORMs, the N+1 problem, and SQL injection
- 46Design a schema and defend it
Every one of those days is free to read in full. See all 90.
03 / Where people go wrong
- 01
Learning a framework instead of HTTP
Someone who knows Express but not HTTP can build endpoints and cannot debug a caching problem, a CORS failure, or a request that works in one client and not another. The framework is a convenience over the protocol. Knowing the protocol makes every framework readable, including the next one.
- 02
Using an ORM before writing SQL
The ORM generates queries you cannot read, and when one is slow you have no idea why. Write the SQL first, understand what an index is and when it is not used, see the N plus one problem happen to you once. Then the ORM becomes a time saver rather than a blindfold.
- 03
Copy-pasting authentication
Auth is the area where working code and correct code diverge most dangerously, because a broken implementation behaves perfectly until somebody attacks it. You do not need to write your own, and you do need to understand what a session is, what a JWT actually contains, why it cannot be trusted blindly, and where the token is stored.
- 04
Treating the database as a place to put things
Schema design gets skipped because it is not visible in the product. Then a missing constraint becomes inconsistent data, a missing index becomes a slow query at ten thousand rows, and a denormalised field becomes three places that disagree. The database is the part of your system with the longest memory.
04 / How long it takes
Twenty-four days at two to three hours across the two spans above, ending with a backend you built rather than scaffolded: real endpoints, real authentication, a schema you can defend, and queries you can explain the plan of.
If you already know HTTP properly you can start at the second span and take twelve. That is the honest version, and the day pages are public so you can check whether the first span has anything you are missing before you decide.
05 / Common questions
- Should I learn SQL or an ORM first?
- SQL, without much doubt. An ORM writes SQL for you, and when it writes something slow or wrong you need to be able to read it. Learning the ORM first means every database problem is opaque. The reverse order costs about a week and pays back permanently.
- Which backend language should I learn?
- It matters far less than the concepts. This path teaches foundations and data structures in Python for the first twenty-two days, then moves to JavaScript and TypeScript for the web and backend days, so you see the same ideas expressed twice and stop mistaking syntax for understanding. HTTP, schema design, indexing, auth and transactions transfer to any language you move to afterwards.
- Do I need to learn frontend before backend?
- Not strictly, but a little helps, because you will be building the thing that a frontend consumes and it is much easier to design an API when you have felt what it is like to use a bad one.
The whole path is free and public.
Read the roadmap, open any day, and decide for yourself. Signing in is only so ninety days of progress survives a cleared browser.