Exercises 3.1 - 3.6
Exercises 3.7 - 3.8
Exercises 3.9 - 3.11
Exercises 3.12
Exercises 3.13 - 3.14
Exercises 3.15 - 3.18
Exercises 3.19 - 3.21
Exercise 3.22
Implement a Node application that returns a hardcoded list of phonebook entries from the address http://localhost:3001/api/persons.
[
{
id: 1,
name: 'Arto Hellas',
number: '040-123456',
},
{
id: 2,
name: 'Ada Lovelace',
number: '39-44-5323523',
},
{
id: 3,
name: 'Dan Abramov',
number: '12-43-234345',
},
{
id: 4,
name: 'Mary Poppendieck',
number: '39-23-6423122',
},
];Notice that the forward slash in the route api/persons is not a special character, and is just like any other character in the string.
The application must be started with the command npm start.
The application must also offer an npm run dev command that will run the application and restart the server whenever changes are made and saved to a file in the source code.
The page has to show the time that the request was received and how many entries are in the phonebook at the time of processing the request.
There can only be one response.send() statement in an Express app route. Once you send a response to the client using response.send(), the request-response cycle is complete and no further response can be sent.
To include a line space in the output, use
tag, or wrap the statements in
tags.
Implement the functionality for displaying the information for a single phonebook entry. The url for getting the data for a person with the id 5 should be http://localhost:3001/api/persons/5
If an entry for the given id is not found, the server has to respond with the appropriate status code.
Implement functionality that makes it possible to delete a single phonebook entry by making an HTTP DELETE request to the unique URL of that phonebook entry.
Test that your functionality works with either Postman or the Visual Studio Code REST client.
Expand the backend so that new phonebook entries can be added by making HTTP POST requests to the address http://localhost:3001/api/persons.
Generate a new id for the phonebook entry with the Math.random function. Use a big enough range for your random values so that the likelihood of creating duplicate ids is small.
Implement error handling for creating new entries. The request is not allowed to succeed, if:
- The name or number is missing
- The name already exists in the phonebook
Respond to requests like these with the appropriate status code, and also send back information that explains the reason for the error, e.g.:
{
error: 'name must be unique';
}Add the morgan middleware to your application for logging. Configure it to log messages to your console based on the tiny configuration.
The documentation for Morgan is not the best, and you may have to spend some time figuring out how to configure it correctly. However, most documentation in the world falls under the same category, so it's good to learn to decipher and interpret cryptic documentation in any case.
Morgan is installed just like all other libraries with the npm install command. Taking morgan into use happens the same way as configuring any other middleware by using the app.use command.
Configure morgan so that it also shows the data sent in HTTP POST requests.
Note that logging data even in the console can be dangerous since it can contain sensitive data and may violate local privacy law (e.g. GDPR in EU) or business-standard. In this exercise, you don't have to worry about privacy issues, but in practice, try not to log any sensitive data.
This exercise can be quite challenging, even though the solution does not require a lot of code.
Make the backend work with the phonebook frontend from the exercises of the previous part. Do not implement the functionality for making changes to the phone numbers yet, that will be implemented in exercise 3.17.
You will probably have to do some small changes to the frontend, at least to the URLs for the backend. Remember to keep the developer console open in your browser. If some HTTP requests fail, you should check from the Network-tab what is going on. Keep an eye on the backend's console as well. If you did not do the previous exercise, it is worth it to print the request data or request.body to the console in the event handler responsible for POST requests.
Deploy the backend to the internet, for example to Fly.io or Render.
Test the deployed backend with a browser and Postman or VS Code REST client to ensure it works.
PRO TIP: When you deploy your application to Internet, it is worth it to at least in the beginning keep an eye on the logs of the application AT ALL TIMES.
Create a README.md at the root of your repository, and add a link to your online application to it.
NOTE: as it was said, you should deploy the BACKEND to the cloud service. If you are using Fly.io the commands should be run in the root directory of the backend (that is, in the same directory where the backend package.json is). In case of using Render, the backend must be in the root of your repository.
You shall NOT be deploying the frontend directly at any stage of this part. It is just backend repository that is deployed throughout the whole part, nothing else.
Generate a production build of your frontend, and add it to the Internet application using the method introduced in this part.
NB If you use Render, make sure the directory dist is not ignored by git on the backend.
Also, make sure that the frontend still works locally (in development mode when started with command npm run dev).
If you have problems getting the app working make sure that your directory structure matches the example app.
Create a cloud-based MongoDB database for the phonebook application with MongoDB Atlas.
Create a mongo.js file in the project directory, that can be used for adding entries to the phonebook, and for listing all of the existing entries in the phonebook.
The application should work as follows. You use the program by passing three command-line arguments (the first is the password).
The new entry to the phonebook will be saved to the database. Notice that if the name contains whitespace characters, it must be enclosed in quotes.
If the password is the only parameter given to the program, then the program should display all of the entries in the phonebook.
Change the fetching of all phonebook entries so that the data is fetched from the database.
Verify that the frontend works after the changes have been made.
In the following exercises, write all Mongoose-specific code into its own module, just like we did in the chapter Database configuration into its own module.
Change the backend so that new numbers are saved to the database. Verify that your frontend still works after the changes.
At this stage, you can ignore whether there is already a person in the database with the same name as the person you are adding.
Change the backend so that deleting phonebook entries is reflected in the database.
Verify that the frontend still works after making the changes.
Move the error handling of the application to a new error handler middleware.
If the user tries to create a new phonebook entry for a person whose name is already in the phonebook, the frontend will try to update the phone number of the existing entry by making an HTTP PUT request to the entry's unique URL.
Modify the backend to support this request.
Verify that the frontend works after making your changes.
Also update the handling of the api/persons/:id and info routes to use the database, and verify that they work directly with the browser, Postman, or VS Code REST client.
Expand the validation so that the name stored in the database has to be at least three characters long.
Expand the frontend so that it displays some form of error message when a validation error occurs
Add validation to your phonebook application, which will make sure that phone numbers are of the correct form. A phone number must:
- have length of 8 or more
- be formed of two parts that are separated by -, the first part has two or three numbers and the second part also consists of numbers
- eg. 09-1234556 and 040-22334455 are valid phone numbers
- eg. 1234556, 1-22334455 and 10-22-334455 are invalid
If an HTTP POST request tries to add a person with an invalid phone number, the server should respond with an appropriate status code and error message.
Generate a new "full stack" version of the application by creating a new production build of the frontend, and copying it to the backend repository. Verify that everything works locally by using the entire application from the address http://localhost:3001/.
Push the latest version to Fly.io/Render and verify that everything works there as well.
NOTE: you should deploy the BACKEND to the cloud service. If you are using Fly.io the commands should be run in the root directory of the backend (that is, in the same directory where the backend package.json is). In case of using Render, the backend must be in the root of your repository.
You shall NOT be deploying the frontend directly at any stage of this part. It is just backend repository that is deployed throughout the whole part, nothing else.
Add ESlint to your application and fix all the warnings.