What Is This Course?
TypeScript: Basics to Advanced is a free course that teaches TypeScript step by step, the way companies use it.
It...
For further actions, you may consider blocking this person and/or reporting abuse
Ending on a full Node API instead of isolated snippets is the right call.
Thank you! That was the goal. Snippets teach the syntax, but a full project shows how the pieces fit together. The last session builds a Task Management API with JWT login, Joi validation, MongoDB and 25 tests, using everything from the earlier sessions.
The JWT login plus Joi validation in that final build is a nice payoff for working through all 33 sessions.
Thanks, glad it lands that way! The final session shows which earlier session each file is built on, so the project feels like a recap rather than something new. It's also the TypeScript version of the Task API from the Node.js course, so anyone who took both courses can compare the JavaScript and TypeScript code file by file.
That file-by-file JavaScript and TypeScript comparison is the part that would make the recap click. Seeing the same Task API in both makes the differences easier to spot.
Exactly! For anyone who wants to try it, the table that maps each JavaScript file to its TypeScript version is in The Plan section of the final session. Thanks again for reading so closely!
I'd add a small change request after the final Task API: introduce a new task status and trace every place that needs updating, from the union to Joi validation and the tests. That would show whether the pieces really fit together without asking learners to build another app. For interview prep, I'd pair the finished project with a few prachub questions that require explaining a change to existing code. The explanation is where gaps become much easier to spot.
Thanks, that's a great suggestion, and the final session actually includes it. Mini Example 1: A New Task Status adds an
archivedstatus to the one list of statuses. The union type, the Mongoose enum, the Joi rule and the stats loop all follow from that list, andtscpoints to the one object that still has to name every status. Exercise 7 then asks learners to finish the change for real: update the tests, makeoverdueignore archived tasks, and find out which test fails beforegetStatschanges.I agree about interview prep too. Explaining a change to code you know well is where the gaps show up. That's why the session's interview questions are about decisions in the project itself, like how each user only sees their own tasks.
The Node API endpoint gives learners a useful finish line beyond syntax drills. One lesson worth emphasizing near the API section is the boundary between compile-time types and runtime data: request bodies, environment values, and database results still need validation. Showing a type plus a runtime schema for the same payload makes TypeScript’s value in backend work much more concrete.
Thank you, this is a great point, and it's exactly the boundary the course tries to make clear.
Session 26: Runtime Validation with Joi starts from that idea: request bodies, query strings, environment variables, settings files and responses from other APIs all arrive without a type TypeScript can trust. The rule it teaches is to validate once at the edge, and then let the rest of the code rely on the types. It also pairs an interface with a Joi schema for the same payload, so a misspelled key in the schema becomes a compile error, and it checks environment variables when the program starts. The final project uses the same pattern for its request bodies.
Database results are the part the course covers least directly. Session 32 relies on the Mongoose schema to control what gets written, so making the "check what comes back" side more explicit is a good idea. Thanks for the thoughtful feedback!