On macOS you can install MongoDB using Homebrew by typing the following at the command line. The Atlas CLI walkthrough can also stand up a local sandbox if you prefer not to manage a downloaded archive yourself:

brew install mongodb-atlas
atlas setup

Alternatively you can unzip the MongoDB server from the downloaded archive to a local file system and add the right commands to your operating system PATH environment variable. On macOS, unzip the file into /usr/local which creates a directory such as /usr/local/mongodb-macos-x86_64-8.0.4 (your version might differ). To be able to execute the database related commands, add the path to the .bash_profile or .zshrc file located in your home directory. Add the following line in the configuration file as shown below. Your actual version might differ.

# ~/.bash_profile or ~/.zshrc
export PATH="$PATH:/usr/local/mongodb-macos-x86_64-8.0.4/bin"

If the .bash_profile or .zshrc file does not exist in your home directory, create it as a plain text file, but with no extensions and a period in front of it. Configure it as shown above and then restart your computer so the shell picks up the new path. After the restart, which mongod should print a path under that bin directory.

On Windows, unzip the file into C:\Program Files. To configure environment variables on Windows press the Windows + R key combination to open the Run prompt, type sysdm.cpl and press OK. In the System Properties window that appears, press the Advanced tab and then the Environment Variables button. In the Environment Variables configuration window select the Path variable and press the Edit button. Copy and paste the path of the bin directory in the mongodb directory you unzipped, for example C:\Program Files\mongodb-windows-x86_64-8.0.4\bin. The actual path might differ. Press OK and restart the computer so every new terminal session can find mongod and mongosh.

If you installed MongoDB as a service, it is already running in the background and can be configured and restarted in Windows from the Services dialog or from System Settings on macOS. Alternatively you can start the MongoDB server from the command line using the mongod executable in the bin directory where you installed MongoDB. First you will need to create a data folder where the server will store all its data. You can create a data folder in your home directory as shown below.

cd ~
mkdir data

When you start MongoDB, you will need to tell it where the data folder is with the dbpath option. If you installed MongoDB on Windows under Program Files, you can start MongoDB from your home directory as shown below. Make sure to include the --dbpath data option to tell MongoDB where to find the data directory. Leave that terminal open while you work; closing it stops the process unless the installer registered a service.

cd ~
# Windows (path and version will differ)
# C:\Program Files\mongodb-windows-x86_64-8.0.4\bin\mongod --dbpath data

# macOS
# /usr/local/mongodb-macos-aarch64-8.0.4/bin/mongod --dbpath data

If you installed MongoDB on macOS in /usr/local, the second command is the one you want. The version folder name changes with each release; copy the path you actually unzipped rather than the sample numbers. Once mongod prints that it is waiting for connections on port 27017, Compass and later Mongoose can reach it.

The Mongoose library implements a set of APIs and abstractions for applications to interact with a MongoDB database. Instead of opening a raw driver connection and writing collection names as strings in every call, you declare schemas and models once and then call find, create, updateOne, and deleteOne on those models. To use the Mongoose library, install it from the root of the Node.js project as shown below.

cd webdev-server
npm install mongoose

To connect to the database server programmatically, import the Mongoose library and then use the connect function as shown below. The URL in the connect function is called the connection string and is currently referring to a MongoDB server instance running on the localhost machine — the current laptop or desktop — listening at port 27017 and the kambaz database existing in that server, the same instance Compass just opened. In a later section we will revisit the connection string and configure it to connect to a database server running in a remote machine hosted by MongoDB's Atlas cloud service.

import express from "express";
import mongoose from "mongoose";
// load the mongoose library
// ...
const CONNECTION_STRING = "mongodb://127.0.0.1:27017/kambaz";
mongoose.connect(CONNECTION_STRING);
// connect to the kambaz database
const app = express();
// ...

Place the connect call near the top of index.js so the connection is established before any route handler tries to run a query. This book wraps that call in connectDatabase() so a missing or dead URI does not crash CI. The string you write as a student is the one above. If mongod is not running, Mongoose will retry and then fail; start the service or the command-line process from §6.1.1 before you start nodemon.

Instead of hard coding the connection string in the source code, it is better to configure it as an environment variable and then reference it from the code. This will come in handy when the server application is deployed to a remote service such as Render or Heroku and the connection string can be configured to reference the online remote database running on MongoDB's Atlas cloud service. You will create that cluster in §6.3; for now the local URI is enough, and the same variable name will later hold the mongodb+srv:// string. In the .env file of the Node project — not the Next.js .env.local — declare the following connection string environment variable alongside the session keys you already set in Chapter 5.

SERVER_ENV=development
CLIENT_URL=http://localhost:3000
SERVER_URL=http://localhost:4000
SESSION_SECRET=super secret session phrase
DATABASE_CONNECTION_STRING=mongodb://127.0.0.1:27017/kambaz

Then in index.js, read the connection string as shown below. The dotenv/config import loads .env into process.env before any other module reads those keys. If the variable is missing, the fallback keeps you on localhost so a forgotten line does not silently point at nothing.

import "dotenv/config";
import mongoose from "mongoose";

const CONNECTION_STRING =
  process.env.DATABASE_CONNECTION_STRING ||
  "mongodb://127.0.0.1:27017/kambaz";
mongoose.connect(CONNECTION_STRING);

The PDF name is DATABASE_CONNECTION_STRING. This repo also accepts MONGO_CONNECTION_STRING. If neither is set, DAOs stay in memory and /lab6/status reports store: "memory". After you add the line and restart nodemon, the status demo below should report a database connection when Mongo is reachable. In §6.3.2 you will type the same key into the Render Environment dashboard with an Atlas URI as the value, and you will not change this source file again.

Click to read the store.

As mentioned earlier, non-relational databases do not require specifying the structure, or schema, of the data stored in collections like relational databases do. That responsibility has been delegated to applications using non-relational databases. Once a Node.js application establishes a connection to a MongoDB database, the Mongoose API declares datatypes Schemas and Models to interact with collections. Mongoose Schemas describe the structure of the data being stored in the database and are used to validate the data being stored or modified through the Mongoose library. If a route tries to insert a user without a username, Mongoose rejects the write before it reaches the collection. The schema shown below describes the structure for the users collection imported earlier. Create the schema in a Users directory in your Node.js project.

import mongoose from "mongoose";
const userSchema = new mongoose.Schema({
  _id: String,
  username: { type: String, required: true, unique: true },
  password: { type: String, required: true },
  firstName: String,
  email: String,
  lastName: String,
  dob: Date,
  role: {
    type: String,
    enum: ["STUDENT", "FACULTY", "ADMIN", "USER", "TA"],
    default: "USER",
  },
  loginId: String,
  section: String,
  lastActivity: Date,
  totalActivity: String,
},
{ collection: "users" });
export default userSchema;

Walk the fields one by one so the later DAO and Users screen make sense. _id is the primary key. We keep it a String so the identifiers from earlier JSON files still work; if we omitted it, MongoDB would assign ObjectIds and every enrollment that stored "123" would stop matching. username is a string that is required and unique — two signups cannot share it, which is the same rule the signup route already enforced in memory. password is required but not unique; several people may coincidentally pick the same password, and this course stores it in plain text only so Sign in can compare strings the way Chapter 5 did. firstName, lastName, and email are plain strings with no extra configuration; they may be empty on a newly created user until someone edits them in People Details. dob is a Date so Compass and Mongoose agree on a calendar value rather than a free-form string. role is a string restricted by enum to STUDENT, FACULTY, ADMIN, USER, and TA, with a default of USER when the client does not send a role — that default is what keeps a forgotten field from becoming undefined in the Account Navigation check. loginId and section are strings the People table displays. lastActivity is a date and totalActivity is a string so the table can show a duration such as 10:21:32 without forcing a numeric type. The second argument, { collection: "users" }, tells Mongoose to store documents in the users collection you created in Compass rather than inventing a pluralized default name.

Mongoose models implement a low-level API to interact with MongoDB collections programmatically. Models provide CRUD (Create, Read, Update, Delete) functions such as find(), create(), updateOne(), deleteOne(), and findById(). Those names are deliberately generic because they can interact with any collection configured in the schema. In Kambaz/Users/model.js below, create a Mongoose model from the users schema. In the next section we will create a data access object that implements higher-level functions specific to the domain of Kambaz —findUserByCredentials instead of a bare findOne.

import mongoose from "mongoose";
import schema from "./schema.js";
const model = mongoose.model("UserModel", schema);
export default model;

The first argument, "UserModel", is the model name other schemas use in ref — enrollments will point at it in §6.4.3 when populate("user") needs to know which model to load. The second argument is the schema you just wrote. Exporting the model lets the DAO import a single object and call model.find() without repeating the collection name. You do not instantiate the model yourself; Mongoose keeps one compiled model per name for the life of the process.

The Mongoose model created in the previous section provides low-level functions such as find, create, updateOne, and deleteOne that are deliberately vague since they need to be able to operate on any collection. It is good practice to wrap these low-level generic functions within higher-level functions that are specific to the use cases of the specific project. For instance, instead of just using the generic find() function, it would be preferable to use something such as findUsers(), findUserById(), or findUserByUsername(). A previous chapter implemented a data access object using arrays declared in the Database/index.js files. This chapter refactors the DAOs so they use an actual database. Chapter 5's DAO read arrays from that barrel file. This chapter keeps the same function names and reimplements them with the model. The following Kambaz/Users/dao.js re-implements the CRUD operations for the users collection written in terms of the low-level Mongoose model operations.

import model from "./model.js";
import { v4 as uuidv4 } from "uuid";
export default function UsersDao() {
  const findAllUsers = () => model.find();
  const findUserById = (userId) => model.findById(userId);
  const findUserByUsername = (username) =>
    model.findOne({ username: username });
  const findUserByCredentials = (username, password) =>
    model.findOne({ username, password });
  const updateUser = (userId, user) =>
    model.updateOne({ _id: userId }, { $set: user });
  const deleteUser = (userId) => model.deleteOne({ _id: userId });
  const createUser = (user) => {
    const newUser = { ...user, _id: uuidv4() };
    return model.create(newUser);
  };
  return {
    createUser, findAllUsers, findUserById,
    findUserByUsername, findUserByCredentials, updateUser, deleteUser,
  };
}

findAllUsers is model.find() with no predicate, so it returns every document in users. findUserById uses findById, which is the usual way to load one document by primary key. findUserByUsername calls findOne with { username } so signup can reject a duplicate. findUserByCredentials matches both username and password in one query, which is what Sign in needs. updateUser identifies the document by _id and applies $set so only the fields in the payload change; fields you omit stay as they were. deleteUser removes one document by primary key. createUser copies the incoming object, assigns a fresh uuidv4() identifier, and inserts it; we generate the id in the application so the string format stays compatible with enrollments. Each of these functions returns a promise. Routes in the next section will await them. Practice the same verbs on a small todos collection before you touch Kambaz users. Create, find, find by id, update, and delete — that is every CRUD letter:

Previous chapters implemented account routes such as signin and signup shown below. Since the DAO implementations used data structures imported from the local file system, the operations were synchronous. A find against an in-memory array returned a user before the next line ran, so the handler could assign req.session["currentUser"] immediately. Now that the DAO is interacting with a database, the operations are asynchronous: Mongoose sends a query over the network — even to localhost — and the answer arrives later as a promise. The route handlers must be tagged with the async / await keywords as shown below so Express does not send a response before the database has answered. Confirm Signin, Signup, and Profile screens work as before. Following the examples below for the signin and signup functions, add the async keyword to all other router functions and add the await keyword to all calls to DAO functions, including profile, signout, and the course routes you wrote in Chapter 5.

const signin = async (req, res) => {
  const { username, password } = req.body;
  const currentUser = await dao.findUserByCredentials(username, password);
  if (currentUser) {
    req.session["currentUser"] = currentUser;
    res.json(currentUser);
  } else {
    res.status(401).json({ message: "Unable to login. Try again later." });
  }
};

const signup = async (req, res) => {
  const user = await dao.findUserByUsername(req.body.username);
  if (user) {
    res.status(400).json({ message: "Username already taken" });
    return;
  }
  const currentUser = await dao.createUser(req.body);
  req.session["currentUser"] = currentUser;
  res.json(currentUser);
};

Signin still reads username and password from the request body, but now it awaits findUserByCredentials. If a matching document exists, the handler stores that document on the session and returns it as JSON so the React Sign in screen can call setCurrentUser on Account Context from Chapter 4. If no document matches, the handler responds 401 with the same message you already display. Signup first awaits findUserByUsername; if that query returns a document, the username is taken and the handler returns 400 without inserting anything. Otherwise it awaits createUser, stores the new document on the session, and returns it. The React screens do not change their axios URLs; they only continue to work if every DAO call is awaited. After you tag the remaining handlers, sign in as iron_man / stark123, open Profile, and confirm the name still comes from the server. Then sign out and sign up a throwaway username to confirm the duplicate-username branch still rejects a second attempt.

DAOs implement high-level data operations based on lower-level Mongoose models. The Mongoose model find function retrieves all documents from a collection when you pass no predicate. The higher-level findAllUsers function below uses the lower-level find function to retrieve all the users from the users collection. That is the same function you already returned from the DAO in §6.2.5; we repeat it here because the route, the client, and the Users screen all depend on it.

const findAllUsers = () => model.find();

Routes implement RESTful Web APIs that user interface clients can use to interact with server functionality. The route implemented below uses the findAllUsers function implemented by the DAO to retrieve all the users from the database. The route responds with the collection of users retrieved from the database. Confirm the route works by navigating to http://localhost:4000/api/users with the browser. You should see a JSON array whose length matches the document count Compass shows for kambaz.users. If the array is empty, import the JSON files from §6.1.4 again and refresh.

const findAllUsers = async (req, res) => {
  const users = await dao.findAllUsers();
  res.json(users);
};
app.get("/api/users", findAllUsers);

Meanwhile in the React user interface application, in app/(kambaz)/account/client.ts, implement the findAllUsers function shown below to send a GET request to the server and await the server's response containing an array of users in the data property. Use the axios instance that sends credentials so a later admin-only check can read the session cookie. The USERS_API constant already prefixes httpServer() or NEXT_PUBLIC_HTTP_SERVER so the same function works on localhost and on Vercel once you point the public env var at the new Render origin.

export const findAllUsers = async () => {
  const response = await axiosWithCredentials.get(USERS_API);
  return response.data;
};

To display the array of users from the database, refactor the People Table component to accept an optional users parameter instead of retrieving the users from the local file system. Convert the People Table from a page into a component as shown below. Remove any filters that joined enrollments in the browser, since data access rules are best handled at the server. The table should render whatever array the parent passes; the Users screen will pass every user, and the course People page in §6.4.3.5 will pass only the students enrolled in that course. Style the table with Tailwind utility classes rather than Bootstrap's table table-striped — a full-width collapsed table with a light border and striped odd rows is enough.

"use client";
import { useState } from "react";
import { FaUserCircle } from "react-icons/fa";
import PeopleDetails from "./Details";

export default function PeopleTable({
  users = [],
  fetchUsers,
}: {
  users?: any[];
  fetchUsers: () => void;
}) {
  return (
    <div id="wd-people-table" className="overflow-x-auto">
      <table className="w-full border-collapse text-left text-sm">
        <thead>
          <tr className="border-b border-neutral-300">
            <th className="p-2">Name</th>
            <th className="p-2">Login ID</th>
            <th className="p-2">Section</th>
            <th className="p-2">Role</th>
            <th className="p-2">Last Activity</th>
            <th className="p-2">Total Activity</th>
          </tr>
        </thead>
        <tbody>
          {users.map((user) => (
            <tr key={user._id} className="odd:bg-neutral-50">
              <td className="wd-full-name p-2 text-nowrap">
                <FaUserCircle className="me-2 inline text-3xl text-neutral-500" />
                <span className="wd-first-name">{user.firstName}</span>{" "}
                <span className="wd-last-name">{user.lastName}</span>
              </td>
              <td className="wd-login-id p-2">{user.loginId}</td>
              <td className="wd-section p-2">{user.section}</td>
              <td className="wd-role p-2">{user.role}</td>
              <td className="wd-last-activity p-2">{user.lastActivity}</td>
              <td className="wd-total-activity p-2">{user.totalActivity}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

Create a new Users screen that fetches the users from the database and displays them with the People Table component as shown below. The screen is a Client Component because it keeps the array in useState and loads it in useEffect when the page mounts. fetchUsers calls the client, stores the array, and is later passed into the table so People Details can refresh the list after a create, update, or delete.

"use client";
import { useState, useEffect } from "react";
import PeopleTable from "../../courses/[cid]/people/Table";
import * as client from "../client";

export default function Users() {
  const [users, setUsers] = useState<any[]>([]);
  const fetchUsers = async () => {
    const users = await client.findAllUsers();
    setUsers(users);
  };
  useEffect(() => {
    fetchUsers();
  }, []);
  return (
    <div>
      <h3>Users</h3>
      <PeopleTable users={users} fetchUsers={fetchUsers} />
    </div>
  );
}

Add a Users link to the Account Navigation sidebar that navigates to the Users screen only if the logged-in user has an ADMIN role. The signed-in user lives in Account Context from Chapter 4, not in a Redux slice, so read currentUser from useAccountContext(). Render the link with the same Tailwind pattern the other Account links already use: semibold black when the path ends with users, otherwise the red accent. To test, use Compass to update the role of an existing user or create a new user with an ADMIN role, sign in as that ADMIN user, and navigate to the Users screen. This book seeds nick_fury / fury123 as an administrator. Confirm that all users are displayed.

"use client";
import Link from "next/link";
import { usePathname } from "next/navigation";
import { useAccountContext } from "./AccountContext";

export default function AccountNavigation() {
  const { currentUser } = useAccountContext();
  const pathname = usePathname() ?? "";
  return (
    <div id="wd-account-navigation">
      {/* existing Signin / Signup / Profile links */}
      {currentUser && currentUser.role === "ADMIN" && (
        <>
          <Link
            href="/account/users"
            className={
              pathname.endsWith("users")
                ? "font-semibold text-black"
                : "text-red-600"
            }
          >
            Users
          </Link>
          <br />
        </>
      )}
    </div>
  );
}

Logged in as an ADMIN, navigate to the new Users screen and confirm it displays all the users. A faculty or student session should not show the link at all. If you see an empty table, open the Network tab and confirm GET /api/users returns 200 and a non-empty array; a 401 usually means the session cookie was not sent, which is why the client uses axiosWithCredentials.

Listing every user is useful for an administrator, but the moment the collection grows you will want to ask for a subset. Mongoose's find accepts a JSON object used to pattern-match documents in the collection. That object is a predicate: only documents that satisfy it are returned. In the User DAO, implement findUsersByRole that filters the users collection by the role property as shown below. The { role: role } object means that documents will be filtered by their role property that matches the value role. Because the property name and the variable name are the same, you can write the shorthand { role } and Mongoose will still compare the field to that string.

const findUsersByRole = (role) => model.find({ role });
const findUsersByPartialName = (partialName) => {
  const regex = new RegExp(partialName, "i");
  return model.find({
    $or: [
      { firstName: { $regex: regex } },
      { lastName: { $regex: regex } },
    ],
  });
};

findUsersByPartialName goes a step further. Instead of an exact string match, it builds a regular expression from the text the administrator typed and asks MongoDB to match that pattern against either firstName or lastName. The "i" flag makes the match case-insensitive, so thor finds Thor. The $or operator means a document matches if either field matches; without it you would only search one column. Remember to export both functions from the object the DAO returns so the routes can call them.

In the User routes, refactor the findAllUsers function so that it parses the role from the query string, and then uses the DAO to retrieve users with that particular role. If the query string has no role, fall through to the unfiltered list. A little later you will parse name the same way. Keeping both filters on one GET /api/users route avoids inventing a new URL for every search; the client encodes the predicate as ?role=FACULTY or ?name=thor.

const findAllUsers = async (req, res) => {
  const { role, name } = req.query;
  if (role) {
    const users = await dao.findUsersByRole(role);
    res.json(users);
    return;
  }
  if (name) {
    const users = await dao.findUsersByPartialName(name);
    res.json(users);
    return;
  }
  const users = await dao.findAllUsers();
  res.json(users);
};

In the React user interface application, add findUsersByRole in the client so that it encodes the role in the query string of the URL as shown below. Then add findUsersByPartialName which encodes a name the same way. The server can use that name to filter users by their first and last name.

export const findUsersByRole = async (role: string) => {
  const response = await axios.get(`${USERS_API}?role=${role}`);
  return response.data;
};
export const findUsersByPartialName = async (name: string) => {
  const response = await axios.get(`${USERS_API}?name=${name}`);
  return response.data;
};

In the Users screen, add a dropdown that invokes a filterUsersByRole event handler function with the selected role. The function updates a role state variable and requests from the server the list of users filtered by their role. If the administrator picks All Roles, the handler clears the filter and calls fetchUsers again. Confirm that selecting various roles actually filters the users by their role. Style the select with Tailwind — a bordered control about a quarter of the width — rather than Bootstrap's form-select.

const [role, setRole] = useState("");
const filterUsersByRole = async (role: string) => {
  setRole(role);
  if (role) {
    const users = await client.findUsersByRole(role);
    setUsers(users);
  } else {
    fetchUsers();
  }
};
// in the JSX:
<select
  value={role}
  onChange={(e) => filterUsersByRole(e.target.value)}
  className="wd-select-role mb-2 w-1/4 rounded border border-neutral-300 px-2 py-1"
>
  <option value="">All Roles</option>
  <option value="STUDENT">Students</option>
  <option value="TA">Assistants</option>
  <option value="FACULTY">Faculty</option>
  <option value="ADMIN">Administrators</option>
</select>

Now practice filtering users by their first or last name. Create a new name state variable and a corresponding input field used to invoke findUsersByPartialName and update the users state variable with a subset of users that match the name. Confirm that typing a name in the input field actually filters the users by their first or last name. Note that the current implementation does not consider a combination of filtering by role and by name. Feel free to explore how you would go about filtering by both — for example by sending both query parameters and having the route apply $and on the server — but the required exercise is the two independent filters.

const [name, setName] = useState("");
const filterUsersByName = async (name: string) => {
  setName(name);
  if (name) {
    const users = await client.findUsersByPartialName(name);
    setUsers(users);
  } else {
    fetchUsers();
  }
};
// in the JSX:
<input
  className="wd-filter-by-name me-2 mb-2 w-1/4 rounded border border-neutral-300 px-2 py-1"
  placeholder="Search people"
  value={name}
  onChange={(e) => filterUsersByName(e.target.value)}
/>

A common database operation is to retrieve documents by their primary key. Listing and filtering give you arrays; clicking a name should load one document so you can read every field, edit it, or delete it. The DAO function below retrieves a user document by its primary key. findById is a convenience for findOne({ _id: userId }) and is the usual Mongoose spelling when the identifier is the document's _id.

const findUserById = (userId) => model.findById(userId);
// route:
const findUserById = async (req, res) => {
  const user = await dao.findUserById(req.params.userId);
  res.json(user);
};
app.get("/api/users/:userId", findUserById);

Make the findUserById DAO function available as a RESTful Web API as shown above. The route reads userId from the path, awaits the DAO, and responds with that one document. Confirm it in the browser by opening http://localhost:4000/api/users/ followed by an _id you copy from Compass. The user interface can then interact with the server using the findUserById client function shown below, which appends the id to USERS_API.

export const findUserById = async (id: string) => {
  const response = await axios.get(`${USERS_API}/${id}`);
  return response.data;
};

In a new People Details component, use the client's findUserById function to retrieve the user when a faculty member clicks on the user's name. Parse a uid parameter and use it to retrieve the user by their ID when the component loads. If the uid does not exist, return null so that the component does not render on the screen. In useEffect, add uid as a dependency so that the component re-renders if you click on another user while the component is still displaying. The panel is a fixed column on the right — Tailwind fixed top-0 end-0 bottom-0 with a white background and a shadow — rather than a Bootstrap offcanvas.

"use client";
import { useEffect, useState } from "react";
import { FaUserCircle } from "react-icons/fa";
import { IoCloseSharp } from "react-icons/io5";
import * as client from "../../../account/client";

export default function PeopleDetails({
  uid,
  onClose,
}: {
  uid: string | null;
  onClose: () => void;
}) {
  const [user, setUser] = useState<any>({});
  const fetchUser = async () => {
    if (!uid) return;
    const user = await client.findUserById(uid);
    setUser(user);
  };
  useEffect(() => {
    if (uid) fetchUser();
  }, [uid]);
  if (!uid) return null;
  return (
    <div className="wd-people-details fixed top-0 end-0 bottom-0 z-20 w-full max-w-sm bg-white p-4 shadow">
      <button type="button" onClick={onClose} className="wd-close-details absolute end-2 top-2">
        <IoCloseSharp className="text-3xl" />
      </button>
      <div className="mt-2 text-center">
        <FaUserCircle className="me-2 text-4xl text-neutral-500" />
      </div>
      <hr />
      <div className="wd-name text-lg text-red-700">
        {user.firstName} {user.lastName}
      </div>
      <b>Roles:</b> <span className="wd-roles">{user.role}</span>
      <br />
      <b>Login ID:</b> <span className="wd-login-id">{user.loginId}</span>
      <br />
      <b>Section:</b> <span className="wd-section">{user.section}</span>
      <br />
      <b>Total Activity:</b>{" "}
      <span className="wd-total-activity">{user.totalActivity}</span>
    </div>
  );
}

Add a close button rendered as an X at the top right that hides the component by calling onClose, which the table uses to clear showDetails and navigate attention back to the Users screen. From the Users page, pass fetchUsers to People Table so that we can update the users if we create, update, or delete users from the People Details dialog. In the table, keep showDetails and showUserId in state. Clicking a name sets both; closing the panel sets showDetails to false and calls fetchUsers so the list reflects any edit that happened while the panel was open. Confirm that clicking on the name of a user displays the user's details. Also confirm that closing People Details hides the component.

const [showDetails, setShowDetails] = useState(false);
const [showUserId, setShowUserId] = useState<string | null>(null);
// render PeopleDetails when showDetails is true
{showDetails && (
  <PeopleDetails
    uid={showUserId}
    onClose={() => {
      setShowDetails(false);
      fetchUsers();
    }}
  />
)}
// on the name cell:
onClick={() => {
  setShowDetails(true);
  setShowUserId(user._id);
}}

To delete user documents from the users MongoDB collection, implement the deleteUser operation as shown below. The DAO function removes a single user document from the database based on its primary key. findByIdAndDelete is the Mongoose helper that both locates and removes the document; deleteOne({ _id: userId }) is an equivalent spelling if you prefer to stay consistent with the other one-argument filters.

const deleteUser = (userId) => model.findByIdAndDelete(userId);
app.delete("/api/users/:userId", async (req, res) => {
  const status = await dao.deleteUser(req.params.userId);
  res.json(status);
});

The route below makes the deleteUser operation available as a RESTful Web API for integration with the user interface, which encodes the id of the user to remove as a path parameter. In the React Web app, implement a client function that integrates with that route.

export const deleteUser = async (userId: string) => {
  const response = await axios.delete(`${USERS_API}/${userId}`);
  return response.data;
};

In the People Details component add buttons Cancel and Delete as shown below. The Delete button invokes a new deleteUser event handler function with uid, the ID of the user to delete. Pass a reference to fetchUsers as a parameter so People Details can notify People Table that a user has been removed and that the list of users must be updated. Use the client's deleteUser to remove the user, and then call onClose to hide the details component. The Cancel button just hides the details without removing any documents. Style Delete as a red Tailwind button and Cancel as a neutral one, floating to the end of the panel. Confirm that clicking the Cancel and Delete buttons actually work: Cancel leaves Compass unchanged; Delete removes the document and the table row disappears after the list refreshes.

const deleteUser = async (uid: string) => {
  await client.deleteUser(uid);
  onClose();
};
// in the JSX, after the activity fields:
<button
  type="button"
  onClick={() => deleteUser(uid)}
  className="wd-delete float-end rounded bg-red-600 px-3 py-1 text-sm text-white"
>
  Delete
</button>
<button
  type="button"
  onClick={onClose}
  className="wd-cancel float-end me-2 rounded bg-neutral-200 px-3 py-1 text-sm"
>
  Cancel
</button>

The Mongoose update function updates documents in MongoDB databases. In the User DAO, implement updateUser as shown below to update a single document by first identifying it by its primary key, and then updating the matching fields in the user parameter. The $set operator is important: without it, Mongoose would replace the entire document with the payload and you would lose fields the editor did not send. With $set, only the keys present in user change.

const updateUser = (userId, user) =>
  model.updateOne({ _id: userId }, { $set: user });

In the User routes, make the DAO function available as a RESTful Web API as shown below. Map a route that accepts a user's primary key as a path parameter, passes the ID and request body to the DAO function, and responds with the status. There is one extra responsibility that did not exist when the data lived in a file: the signed-in session may be a copy of the same document. If an administrator edits their own name, or if a user edits Profile and you later reuse this route, the session still holds the old firstName. After the database write, compare req.session["currentUser"]._id to the path userId. If they match, merge the updates into the session object so the next Profile request and the Account Navigation role check see the new values. The React client still holds its own copy in Account Context; Profile and Sign in already call setCurrentUser with the response when the signed-in person is the one being saved.

const updateUser = async (req, res) => {
  const { userId } = req.params;
  const userUpdates = req.body;
  await dao.updateUser(userId, userUpdates);
  const currentUser = req.session["currentUser"];
  if (currentUser && currentUser._id === userId) {
    req.session["currentUser"] = { ...currentUser, ...userUpdates };
  }
  res.json(currentUser);
};
app.put("/api/users/:userId", updateUser);

In the React client application, the client function updateUser sends user updates to the server to be saved to the database. Use the credentials instance because this write should run in a signed-in session.

export const updateUser = async (user: any) => {
  const response = await axiosWithCredentials.put(
    `${USERS_API}/${user._id}`,
    user,
  );
  return response.data;
};

In the People Details component, add a name state variable to edit the first and last name of the user. Also add an editing state variable to toggle the input field that edits the name. Create a new saveUser function that splits the name state variable into firstName and lastName and sends an updated version of the user to the server. Also update the local user state variable, turn off editing, and close the dialog so People Table can refetch. Add pencil and check icons to turn editing on and off. Hide each icon based on the editing boolean state variable. Clicking the name of the user also turns editing on. If editing is on, hide the user's name and instead display an input field that shows the current user's firstName and lastName and edits the name state variable. Pressing the Enter key saves the updated user's details. Confirm users can be edited: change a last name, press Enter, reopen the row, and confirm Compass shows the new value.

const [name, setName] = useState("");
const [editing, setEditing] = useState(false);
const saveUser = async () => {
  const [firstName, lastName] = name.split(" ");
  const updatedUser = { ...user, firstName, lastName };
  await client.updateUser(updatedUser);
  setUser(updatedUser);
  setEditing(false);
  onClose();
};
// pencil when !editing, check when editing
// name text when !editing; input when editing
// input onKeyDown: if Enter, saveUser()

In the User DAO, implement the createUser function as shown below to insert a new user object into the users collection. Spread the incoming object, assign a fresh uuidv4() identifier, and call model.create. Make sure the incoming user object does not keep a leftover _id property since it can interfere with the database insert operation — a client that accidentally posts an empty string or a copied id would collide with an existing document. Strip that property if present, then assign the new uuid.

const createUser = (user) => {
  const newUser = { ...user, _id: uuidv4() };
  return model.create(newUser);
};

In the User routes, make the DAO operation available as a RESTful Web API for the user interface to interact with. The new user is posted to the route in the request's body. The DAO createUser function inserts the new user into the database and returns the newly inserted user which is sent back to the user interface in the response so the screen can append it without an extra GET.

const createUser = async (req, res) => {
  const user = await dao.createUser(req.body);
  res.json(user);
};
app.post("/api/users", createUser);

In the React client application, implement a createUser client function to interact with the route created above. Post the new user object to the server as shown below.

export const createUser = async (user: any) => {
  const response = await axios.post(`${USERS_API}`, user);
  return response.data;
};

In the Users screen, implement a new createUser event handler that sends a new user object to be inserted in the database. Use default values for the fields as shown and confirm that clicking the new + Users button actually creates the new user. The username includes Date.now() so two clicks in a row do not violate the unique username constraint. Optionally implement editing those fields in the People Details component so the administrator can replace New User with a real name after the insert.

const createUser = async () => {
  const user = await client.createUser({
    firstName: "New",
    lastName: `User ${users.length + 1}`,
    username: `newuser${Date.now()}`,
    password: "password123",
    email: `email${users.length + 1}@neu.edu`,
    section: "S101",
    role: "STUDENT",
  });
  setUsers([...users, user]);
};

The LiveDemo below is that Users screen against the Lab 6 store — find all, filter by role and name, open details, update, delete, create. Work through each verb once so the same sequence feels familiar when you point the sibling server at Mongo and click the real Account Users link.

To get started, head over to mongodb.com and click on Sign in at the top right corner. Login with your Google account or click on Sign Up to create an account with an email and password. If you get a validation email, confirm it and login. Answer any general questions if asked during the sign up process. In the Deploy your cluster screen choose a Free plan for now which should be enough for this course. Name your cluster Kambaz. In the Provider section, choose any of the cloud providers and in the Region section choose a region close to your geographic area, for instance AWS and North Virginia, and then click Create Deployment. In the Connect to Kambaz screen, in the Create a database user section, create credentials to login to your database. In the Username and Password fields, type credentials you will remember later since these are the credentials Mongoose will use to login to the database from your Node.js server application when running on Render or Heroku. If you forget these credentials you will need to create new ones later. Jose's example was giuseppi and a password you should not commit to GitHub or paste into the book. Click Create Database User and keep those values in a password manager; the connection string you copy next will embed them.

mongodb+srv://giuseppi:supersecretpassword@kambaz.jxui0bc.mongodb.net/

mongodb+srv://giuseppi:<password>@kambaz.jxui0bc.mongodb.net/kambaz?retryWrites=true&w=majority&appName=Kambaz

The local Node server was configured to support multiple sessions. Similarly, the remote server also needs to be configured to support sessions so Sign in still stores currentUser in a cookie that the Vercel app can send back. In Render.com, navigate to the Environment section of the application dashboard. Click Add Environment Variable, type the name of the variables in the Key column and the variable's value in the Value column. Repeat for each of the environment variables as shown below. When environment variables change, the server must be restarted by clicking Manual Deploy and then Deploy latest commit. Below is an example of the environment variables used to configure a remote server running on Render.com. Use the same Environment Variable keys shown on the left. Do not use the sample values on the right. Instead use the values for your Mongo database, your Vercel remote server, and your remote Node server. Note: SERVER_URL should not start with https://; remove it if present.

DATABASE_CONNECTION_STRING=mongodb+srv://USER:PASSWORD@cluster/kambaz?retryWrites=true&w=majority
CLIENT_URL=https://your-a6-preview.vercel.app
SERVER_URL=your-webdev-server.onrender.com
SERVER_ENV=production
SESSION_SECRET=a long random phrase

CLIENT_URL must be the Vercel origin of the a6 deployment so CORS and the session cookie sameSite settings you configured in Chapter 5 accept the browser. SERVER_ENV=production is what turns on secure cookies. After Render finishes the manual deploy, open the Vercel a6 URL, sign in, and confirm Dashboard lists courses from Atlas. If Sign in fails with a network error, check that NEXT_PUBLIC_HTTP_SERVER on Vercel matches the new Render hostname and that you redeployed Vercel after changing it.

The current server application implements RESTful Web APIs to access courses stored in the courses.js file. This section replaces the source of the courses with a MongoDB courses collection. The basic operations on any data source are create, read, update, and delete, colloquially referred to as CRUD operations. The following sections demonstrate how to implement those CRUD operations for courses, one verb at a time, so you can confirm each change in Compass before you move on.

import mongoose from "mongoose";
const courseSchema = new mongoose.Schema({
  _id: String,
  name: String,
  number: String,
  credits: Number,
  description: String,
},
{ collection: "courses" });
export default courseSchema;

import mongoose from "mongoose";
import schema from "./schema.js";
const model = mongoose.model("CourseModel", schema);
export default model;

import model from "./model.js";

function findAllCourses() {
  // return Database.courses;
  return model.find();
}

async function findCoursesForEnrolledUser(userId) {
  const { enrollments } = db;
  const courses = await model.find();
  const enrolledCourses = courses.filter((course) =>
    enrollments.some(
      (enrollment) =>
        enrollment.user === userId && enrollment.course === course._id,
    ),
  );
  return enrolledCourses;
}

const findAllCourses = async (req, res) => {
  const courses = await dao.findAllCourses();
  res.send(courses);
};

const findCoursesForEnrolledUser = async (req, res) => {
  let { userId } = req.params;
  if (userId === "current") {
    const currentUser = req.session["currentUser"];
    if (!currentUser) {
      res.sendStatus(401);
      return;
    }
    userId = currentUser._id;
  }
  const courses = await dao.findCoursesForEnrolledUser(userId);
  res.json(courses);
};

function createCourse(course) {
  const newCourse = { ...course, _id: uuidv4() };
  return model.create(newCourse);
}

const createCourse = async (req, res) => {
  const newCourse = await dao.createCourse(req.body);
  const currentUser = req.session["currentUser"];
  enrollmentsDao.enrollUserInCourse(currentUser._id, newCourse._id);
  res.json(newCourse);
};
app.post("/api/courses", createCourse);

function deleteCourse(courseId) {
  return model.deleteOne({ _id: courseId });
}

const deleteCourse = async (req, res) => {
  const { courseId } = req.params;
  const status = await dao.deleteCourse(courseId);
  res.send(status);
};
app.delete("/api/courses/:courseId", deleteCourse);

function updateCourse(courseId, courseUpdates) {
  return model.updateOne({ _id: courseId }, { $set: courseUpdates });
}

const updateCourse = async (req, res) => {
  const { courseId } = req.params;
  const courseUpdates = req.body;
  const status = await dao.updateCourse(courseId, courseUpdates);
  res.send(status);
};
app.put("/api/courses/:courseId", updateCourse);

In Kambaz, each course contains several modules, establishing a one-to-many relationship. Currently the relationship is implemented by each module having a field that refers to the course they belong to. This section demonstrates how to use Mongoose to implement one-to-many relationships. In UML, one-to-many relationships can be illustrated as a course box connected to a modules box with a "1" on the course end and a "*" on the modules end. The courses collection is said to be on the one side of a one-to-many relation and the modules collection is said to be on the many side. The relationship describes that each course is related to many modules. It is often useful to think of the relationship as a parent-child relationship describing it as courses are the parents of many modules. Another way to think of the relationship is as an ownership relationship, as in courses have many modules.

The easiest way to implement one-to-many relationships in both relational and non-relational databases is to use foreign keys referencing related records. Each module document contains a field course (or courseId) whose value is the _id of some course document the module belongs to. That is what Chapter 5 already did in JSON, and it is the shape this book's modules collection keeps so the existing /api/courses/:courseId/modules routes stay stable.

In non-relational databases there are two additional alternatives to implement one-to-many relationships. One way is to include an array of foreign keys in the parent document that reference all the child documents. Documents in the courses collection would contain a moduleIds array that contains the values of primary keys of child module documents. The keys in that array can be used to retrieve the actual documents from the modules collection. Another alternative is to do away entirely with the collection on the many side and embed the documents in the collection on the one side. The modules collection would be removed and the documents would instead be embedded in the corresponding parent course document in a modules array. Because modules are not expected to be fetched outside a course, the original chapter embeds them on the course schema. This book also keeps a modules collection with a course field. Both shapes are valid; pick one per project and stick to it. The subsections below show the embed schema so you can read the original design, then implement the collection-plus-foreign-key DAO that matches the LiveDemo routes.

• A foreign key on the child: each module has course equal to the course _id (what Chapter 5 already did in JSON, and what this book's collection uses).
• An array of child ids on the parent.
• Embed the child documents in the parent — a modules array on the course. No separate collection.

import mongoose from "mongoose";
const schema = new mongoose.Schema({
  _id: String,
  name: String,
  description: String,
});
export default schema;

import mongoose from "mongoose";
import moduleSchema from "../Modules/schema.js";
const courseSchema = new mongoose.Schema({
  _id: String,
  name: String,
  number: String,
  credits: Number,
  description: String,
  modules: [moduleSchema],
},
{ collection: "courses" });
export default courseSchema;

import mongoose from "mongoose";
const schema = new mongoose.Schema({
  _id: String,
  name: String,
  description: String,
  lessons: [{ _id: String, name: String, description: String }],
});
export default schema;

function findAllCourses() {
  return model.find({}, { name: 1, description: 1 });
}

import mongoose from "mongoose";
const schema = new mongoose.Schema({
  _id: String,
  name: String,
  description: String,
  course: String,
});
export default schema;

function findModulesForCourse(courseId) {
  return model.find({ course: courseId });
}

const findModulesForCourse = async (req, res) => {
  const { courseId } = req.params;
  const modules = await dao.findModulesForCourse(courseId);
  res.json(modules);
};
app.get("/api/courses/:courseId/modules", findModulesForCourse);

function createModule(module) {
  const newModule = { ...module, _id: uuidv4() };
  return model.create(newModule);
}

async function createModule(courseId, module) {
  const newModule = { ...module, _id: uuidv4() };
  await courseModel.updateOne(
    { _id: courseId },
    { $push: { modules: newModule } },
  );
  return newModule;
}

function deleteModule(moduleId) {
  return model.deleteOne({ _id: moduleId });
}

async function deleteModule(courseId, moduleId) {
  return courseModel.updateOne(
    { _id: courseId },
    { $pull: { modules: { _id: moduleId } } },
  );
}

function updateModule(moduleId, moduleUpdates) {
  return model.updateOne({ _id: moduleId }, { $set: moduleUpdates });
}

async function updateModule(courseId, moduleId, moduleUpdates) {
  const course = await courseModel.findById(courseId);
  const module = course.modules.id(moduleId);
  Object.assign(module, moduleUpdates);
  await course.save();
  return module;
}

In Kambaz, a user can be enrolled in several courses, and a course can have many enrollments. An enrollment establishes a relationship between a user and a course. Since there can be many enrollments where many users can be enrolled, or associated, in many courses, the enrollments relation is referred to as a many-to-many relation. Many-to-many relationships can be represented in UML as a users box connected to a courses box with asterisks on both ends, capturing the fact that many users are related to many courses.

Implementing that diagram directly is awkward in both relational and document databases, because it implies that each record in the users collection contains several references to records in the courses collection and vice versa. Keeping those two arrays in sync is error-prone: if you enroll a user by pushing a course id onto the user, you must also push the user id onto the course, and a failed second write leaves the relationship half-applied. It is often easier to understand the implementation by using an intermediate collection that captures the relationship between each record in the original collections. A new enrollments collection refactors the many-to-many relationship as two one-to-many relationships. The new collection is often referred to as a mapping table or mapping collection. The original collections users and courses no longer need to know anything about each other. Instead a record entry in the enrollments collection captures what users are enrolled in what courses by declaring fields user and course that record references to the documents that are related to each other. The following sections describe how to implement many-to-many relationships using Mongoose.

import mongoose from "mongoose";
const enrollmentSchema = new mongoose.Schema({
  _id: String,
  course: { type: String, ref: "CourseModel" },
  user: { type: String, ref: "UserModel" },
  grade: Number,
  letterGrade: String,
  enrollmentDate: Date,
  status: {
    type: String,
    enum: ["ENROLLED", "DROPPED", "COMPLETED"],
    default: "ENROLLED",
  },
},
{ collection: "enrollments" });
export default enrollmentSchema;

import mongoose from "mongoose";
import schema from "./schema.js";
const model = mongoose.model("EnrollmentModel", schema);
export default model;

async function findCoursesForUser(userId) {
  const enrollments = await model.find({ user: userId }).populate("course");
  return enrollments.map((enrollment) => enrollment.course);
}

const findCoursesForEnrolledUser = async (req, res) => {
  let { userId } = req.params;
  if (userId === "current") {
    const currentUser = req.session["currentUser"];
    if (!currentUser) {
      res.sendStatus(401);
      return;
    }
    userId = currentUser._id;
  }
  const courses = await enrollmentsDao.findCoursesForUser(userId);
  res.json(courses);
};

function unenrollAllUsersFromCourse(courseId) {
  return model.deleteMany({ course: courseId });
}

const deleteCourse = async (req, res) => {
  const { courseId } = req.params;
  await enrollmentsDao.unenrollAllUsersFromCourse(courseId);
  const status = await dao.deleteCourse(courseId);
  res.send(status);
};

function enrollUserInCourse(userId, courseId) {
  return model.create({
    user: userId,
    course: courseId,
    _id: `${userId}-${courseId}`,
  });
}
function unenrollUserFromCourse(user, course) {
  return model.deleteOne({ user, course });
}

const enrollUserInCourse = async (req, res) => {
  let { uid, cid } = req.params;
  if (uid === "current") {
    uid = req.session["currentUser"]._id;
  }
  const status = await enrollmentsDao.enrollUserInCourse(uid, cid);
  res.send(status);
};
const unenrollUserFromCourse = async (req, res) => {
  let { uid, cid } = req.params;
  if (uid === "current") {
    uid = req.session["currentUser"]._id;
  }
  const status = await enrollmentsDao.unenrollUserFromCourse(uid, cid);
  res.send(status);
};
app.post("/api/users/:uid/courses/:cid", enrollUserInCourse);
app.delete("/api/users/:uid/courses/:cid", unenrollUserFromCourse);

export const enrollIntoCourse = async (userId: string, courseId: string) => {
  const response = await axiosWithCredentials.post(
    `${USERS_API}/${userId}/courses/${courseId}`,
  );
  return response.data;
};
export const unenrollFromCourse = async (userId: string, courseId: string) => {
  const response = await axiosWithCredentials.delete(
    `${USERS_API}/${userId}/courses/${courseId}`,
  );
  return response.data;
};

const findUsersForCourse = async (req, res) => {
  const { cid } = req.params;
  const users = await enrollmentsDao.findUsersForCourse(cid);
  res.json(users);
};
app.get("/api/courses/:cid/users", findUsersForCourse);

export const findUsersForCourse = async (courseId: string) => {
  const response = await axios.get(`${COURSES_API}/${courseId}/users`);
  return response.data;
};

Implement schema, model, DAO, routes, and client files so that the Assignments and Assignment Editor screens display assignments stored in a database. Users should be able to display assignments in a course, create new assignments, update assignments, and delete existing assignments. Confirm that all operations are reflected in the database. An assignment belongs to one course and a course has many assignments — the same one-to-many relationship you just implemented for modules. You can store assignments in their own collection with a course foreign key, which is what this book does, or embed them on the course the way the original chapter embedded modules. Mirror the modules DAO: findAssignmentsForCourse, createAssignment, updateAssignment, deleteAssignment. The routes already exist from Chapter 5 — make them await the model. The Assignment Editor should PUT the same fields you already edit in the form: title, description, points, and dates. After each save, open Compass and confirm the document changed.