Assembling the Core, End to End

lesson 9-2 · ~14 min · 28/29

Every piece, one function

Below is the create-note path of the API, assembled from parts you have already built:

the session Map from lesson 7-2 (pretend s1 came from a login),
the repository arrays from lesson 6-2,
a validator in the lesson 5-3 style,
the error shape from lesson 4-3 and status codes from 3-3,
ordered like the lesson 5-2 pipeline: auth, then validation, then the handler.

Your job is handleCreateNote, the conductor. It checks the session, validates the body, creates the note, and returns { status, body }. Three TODOs, three pipeline stages. When the last line prints, you have written the core of a production API pattern, end to end.

Code exercise · javascript

Your turn, the capstone. Implement handleCreateNote following the three TODOs: 401 for an unknown session, 400 with details for invalid input, otherwise create { id, author, text }, store it, and return 201 with the note.

Quiz

Wiring this into a real deployment, which statement is TRUE about what remains?

Problem

Final design question. GET /notes must not return a user's 50,000 notes in one response. Which unit-4 technique, returning data plus meta like totalPages, keeps the response bounded? (one word)