Web DevelopmentAdvancedtypescript

Full Stack Web Development

Wire a frontend, an API, a database and auth into one deployable app — and predict what happens at every seam between them.

Learning the layers separately is not the same as being able to build an application out of them. Someone who knows React, Express, SQL and OAuth perfectly can still ship an app where the frontend caches a private response at the CDN, the API trusts a role that was never checked, and a migration runs five minutes after the code that needs it. None of those are React bugs or Express bugs or SQL bugs. They are full-stack bugs, and they are invisible from inside any one layer. This course is about the seams. It assumes you can write a component, a route handler and a query, and spends its time on the decisions that happen between them: which layer answers a request, what a cache is allowed to hold, where a session dies, which migration must run before which deploy, and what evidence you have when something is wrong at three in the morning. It is prediction-based, and deliberately so. Full-stack bugs are rarely visible in the code you are looking at — they are visible in the sequence of decisions between two pieces of code you have both already read. So the questions here ask you to follow a request through a whole system and say what happens, and the two graded challenges model exactly that: one resolves a request through every hop including the invisible ones, the other validates a session the way a server has to, with sliding expiry, rotation, revocation and CSRF rather than a boolean `isLoggedIn`. Everything here is pinned: TypeScript 5, Node 22, PostgreSQL 16, HTTP semantics as of RFC 9110. A prediction without those pins is folklore.

4.7 (120) 720 students 291 min 21 lessons 320 XP on completion

What you will be able to do

  • Trace a single request through every hop it actually takes — edge, CDN, app server, API, database — and name the layer responsible for each decision
  • Decide which rendering strategy fits a route: static, incremental, server-rendered or client-only, and say what each one costs
  • Explain why a client cache and a server cache have different rules, and what stale-while-revalidate actually promises
  • Design an error shape that a frontend can branch on without parsing prose
  • Keep authentication (who) separate from authorization (what), and place the check where it cannot be forgotten
  • Decide where a session lives, when it expires, when it is rotated, and how revocation actually works
  • State the two attacks that token and cookie choices create by default — CSRF and session fixation — and the specific defence for each
  • Make the database the owner of the truth, and let the cache be a copy with a stated staleness budget
  • Recognise an N+1 from a log line, and know the transaction boundaries that stop a partial write
  • Order a deploy and its migrations so a rollback is always possible
  • Choose what to test at each layer so the suite is fast enough that people run it

Assessments

Dashboard