Development
Node.js & Backend Development
An API in Node: routes, validation, and data the server is willing to store.
Node.js & Backend Development builds a small API. You will define routes, check input, and return data the front end can use. JavaScript knowledge is assumed. The lectures keep the server responsible for decisions the browser must not make.
Course syllabus
01. A process on a port
- A process that listens
Node stays running, and a port accepts connections.
- The entry file
That file loads the config and calls listen.
- The port comes from the environment
A default is only for your own machine.
- A request runs a function
The method and the path choose it.
- End the response
Send a status and a body, or the caller waits.
- Speak JSON
A request, a status, and a JSON body.
- A save does not change the running process
You restart to load the file you just edited.
- The API is this process
The browser app is separate, and it never receives the server's secrets.
02. Method, path, and body
- GET and POST are different routes
Same path, different method, different function.
- The id lives in the path
The handler reads it as a string.
- Filters live in the query
A GET does not take a JSON body for its filter.
- Read a header on purpose
Content-Type now, and a credential when you add one.
- Parse JSON once
Then validate the object, because the body is untrusted.
- Reject a body that is not JSON
A wrong content type gets a status, not a guess.
- Copy the fields you accept
The record is a new object, not the raw request.
- Another origin
The API names which browser origin may call it.
03. Read and write routes
- Reading and writing endpoints
A read returns data, and a write changes data and returns what it stored.
- GET returns the list
The handler loads records and sends an array.
- GET returns one record
It looks up the id, or it says the id is unknown.
- POST creates
The body is checked, the record is stored, and the response includes the new id.
- PATCH changes allowed fields
Fields you did not accept stay as they were.
- DELETE removes that id
You decide what a second delete of the same id should return.
- The same shapes every time
List, record, and error do not change shape between calls.
- Hit the route from the terminal
A curl that works is the check, before any UI.
04. Reject a bad body
- Validation
Reject a bad body before any record is written.
- A list of fields you accept
Unknown fields do not get stored.
- Required means present and usable
An empty string is not a name.
- Check the type
A count is a number, and a flag is a boolean, before you save.
- Length and range
A title has a maximum, and a price is not negative.
- One validator for the resource
Create and update both call it, with a clear rule for partial updates.
- The error lists the fields
The client can show which field failed, because you named it.
- The form check is not this check
You still validate on the server when the form is bypassed.
05. Records the server keeps
- Saving on the server
The record lives in a store the process can read after the response.
- The server assigns the id
The client does not choose it.
- A shape you wrote down
The fields, their types, and which ones may be absent.
- Write the record, then read it back
The response is what was stored, not only what was sent.
- A store that survives a restart
A file or a database, not a variable that dies with the process.
- A patch must not wipe the neighbours
Updating one record leaves the others as they were.
- Decide what a missing id means on delete
A missing id is a 404, or a quiet success, and you pick one.
- A field you will not store
A password or a third-party key does not go in this table.
06. Status codes that mean something
- 400 when the body is wrong
The client can fix it, and the message names the field.
- 404 when the id is unknown
You do not send an empty object with a 200.
- 500 when you failed
Something you did not expect, with a short message and no stack in the JSON.
- An async error still answers
A rejected promise reaches a handler that sends the status.
- Unknown paths
A route you do not have is a 404, not a crash.
- The log gets the detail
You keep the error on the server, and the client gets a sentence.
- Do not send the database text
Vendor messages can include paths and queries.
- A failure still ends the response
One status goes out, including when the handler throws.
07. Config and secrets
- Errors and secrets
The client gets a status, and the values that must stay on the server stay there.
- A key in the environment
The process reads it at startup, and it is not a string in the source.
- A file that is not committed
The local env file stays off the repository.
- Refuse to listen if a required value is missing
A server without the config it needs should not start.
- Logs omit the secret
Printing the whole environment is a leak.
- The browser bundle is public
Anything you send to the client is no longer a secret.
- A third-party key stays in this process
The front end calls your route, and your route uses the key.
- Separate config from code
The port, the store path, and the key are configuration.
08. The browser does not decide
- The server calculates the price
If money is involved, the browser does not send the amount to trust.
- A role is not a field in the body
Posting isAdmin does not make someone an admin.
- Look the id up before you act
You load the record, then decide, and you do not trust a hidden input.
- Check a token on the server
A header is verified before the handler runs, when the route requires one.
- Write down what an anonymous caller may do
The routes enforce that list.
- A record has an owner
Another caller does not receive it by guessing the id.
- Drop fields you did not ask for
Extra properties in the body are ignored.
- The same rule for curl and for the app
A disabled button is not a server rule.
09. Files in the API
- Listen stays in the entry file
The entry wires config and starts, and the routes live elsewhere.
- A router per resource
Items have their own routes, mounted on a path.
- Validation beside the resource
The checks are a function the routes call.
- The store is a module
Handlers do not open the file or the database inline every time.
- Format errors in one place
Handlers pass the failure on, and one function shapes the JSON.
- Middleware order
Parse JSON, then the routes, then the error handler last.
- A health route
A GET that shows the process is up, with no secrets in the body.
- Point at where a request lands
You can name the file for a given method and path.
10. Ids, times, and list shape
- One resource before a second
Finish items before you add another noun.
- A related id must exist
If a record points at another, you look that id up first.
- Return the fields you meant
The JSON lists those fields, including when one of them is null.
- Limit the list
The query takes a limit you allow, not the entire history by default.
- Sort only by columns you allow
An arbitrary column name from the query is not a sort.
- The server sets the created time
The client does not choose createdAt.
- The server sets the updated time
You write it when the store changes.
- An empty list keeps the same shape
No rows is still an array, with the same wrapper if you use one.
11. Call the resource
- Listen and confirm the port
The process prints the port it bound, or it fails because the port is taken.
- Read the list before any writes
An empty store returns an empty array on purpose.
- Create with a valid body
You get the record and the id the server assigned.
- Create with an invalid body
You get a 400, and the store does not gain a row.
- Read the id from the response
The stored fields match what you sent, plus the server's own fields.
- Update and read it back
The change is the one you sent, and the other fields remain.
- Confirm the secret is absent
None of those JSON bodies contain the key.
- Restart and read the store
What you saved is still there, because the store outlives the process.
Lecture videos stay with the course. Playback for enrolled students will open once payments are available. Video links are not published on this page.