added initial content for error handling

Author: adamblanchard

courses/backend/node/week2/session-materials/phonebook/api.js

@@ -0,0 +1,18 @@
+import express from "express";
+import contactsRouter from "./api/contacts.js";
+
+const app = express();
+const router = express.Router();
+
+const port = process.env.PORT || 3000;
+
+// Parse URL-encoded bodies (as sent by HTML forms)
+app.use(express.urlencoded({ extended: true }));
+// Parse JSON bodies (as sent by API clients)
+app.use(express.json());
+
+router.use("/contacts", contactsRouter);
+
+app.use("/api", router);
+
+app.listen(port, () => console.log(`Server listening on port ${port}!`));

courses/backend/node/week2/session-materials/phonebook/api/contacts.js

@@ -0,0 +1,18 @@
+import express from "express";
+import knex from "../database.js";
+
+const router = express.Router();
+
+// Example POST endpoint to add a new contact
+router.post("/", async (request, response) => {
+  try {
+    console.log(response.body); // Server side log, for developers
+    const insertedContact = await knex("contacts").insert(response.body); // This could be insecure!
+    response.status(201).json(insertedContact); // 201 Created
+  } catch (error) {
+    console.error("Error inserting contact:", error); // Server side error, for developers
+    response.status(500).json({ message: "Something went wrong on the server." }); // Client side error, for users. Avoid leaking database info.
+  }
+});
+
+export default router;

courses/backend/node/week2/session-plan.md

@@ -41,6 +41,50 @@ TODO: Add a section with live coding somewhere below to explain error handling?
 2. [PUT endpoint exercise](./session-materials/08-put-endpoint.md)
 3. [DELETE endpoint exercise](./session-materials/09-delete-endpoint.md)
 
+## Error handling
+
+Error handling is important so we have visibility of issues that occur in applications, and gain some understanding of what is going wrong.
+
+### HTTP Status Codes Refresher
+
+Here are some of the most commonly used:
+
+#### 2XX - Success
+`200 OK` - The request succeeded, e.g. a webpage loads as it should.
+`201 Created` - A new resource was made, e.g. a new user account.
+
+#### 3XX - Redirection
+`301 Moved Permanently` - The URL has changed, e.g. redirect from oldsite.com to newsite.com.
+`302 Found` - A temporary redirect, e.g. redirecting Spanish visitors to the Spanish version of the website.
+
+#### 4XX - Client Errors
+`400 Bad Request` - The request was invalid, e.g. form data missing or incorrect.
+`401 Unauthorized` - You need to log in e.g. trying to access user features when logged out.
+`404 Not Found` - Nothing at that URL e.g. a missing page or resource.
+
+#### 5XX - Client Errors
+`500 Internal Server Error` - Generic server issue, e.g. something goes wrong in the backend.
+`503 Service Unavailable` - Server is down or busy e.g. backend API is not running.
+
+Read more at [HTTP Status cheatsheet](https://devhints.io/http-status).
+
+### Client vs Server
+
+Server-side errors should be designed for developers. Detailed errors help debugging and ultimately fixing issues easier. 
+e.g. If a database table is missing, record the missing table name in your logs.
+
+Client-side errors should be designed for users, including the correct HTTP status code. 
+e.g. In the missing database table case, simply return a `500 Internal Server Error` and a useful page to the user to explain how to continue.
+
+It's important to hide specific error details from the user for multiple reasons:
+1. Security - Revealing database names and other internal details can give attackers too many clues about your system which can make your app more vulnerable to exploitation.
+2. Privacy - Many internal errors can include sensitive data (e.g. user IDs, personal information) that shouldn't be exposed.
+3. User Experience - Some technical errors would confuse most users, so stick with simple, friendly messages that can help the user continue.
+
+### Live coding
+
+Walk through [`api/contacts.js`](./session-materials/phonebook/api/contacts.js) to explain the try/catch pattern, appropriate server and client side error handling, correct usage of HTTP codes and why the knex code is insecure.
+
 ## Advanced Postman
 
 Postman can be used for quickly testing APIs, but it can also be configured in more advanced ways to support the development workflow. Here are four ways trainees can level up their Postman game.