3.E.1: Bigfoot JSON

Learning Objectives

  1. Understand how to set up Express server to receive requests and respond with data

  2. Understand how to set up CORS to allow access to server from different origin server

Introduction

We will build an app that records and displays Bigfoot sightings with an Express backend. We will build on this app in coming exercises to incorporate SQL and Sequelize.

Setup

  1. Fork and clone the Rocket Academy Bigfoot JSON Backend repo

  2. Fork and clone the Rocket Academy Bigfoot Frontend repo

  3. Copy and paste .env.sample into the repository

  4. Rename the duplicate file to .env

  5. Change the PORT environment variable to 3000

Base: Retrieve Sightings

Starter Code

JSON Backend Repo

Rocket has provided starter code in index.js that responds to server requests to /sightings with all sighting data. The utilities module utils.js exports a function getSightings that reads sightings data from sightings.json. We are using sightings.json in lieu of a database because we have not yet learnt SQL, and in coming exercises we will replace sightings.json with a SQL database.

To run the backend server, install packages with npm i and run the script node index.js. This will start the server at localhost:3000.

Frontend Repo

Rocket has provided generic starter code for us to customise for Bigfoot. We will use this frontend repo for all Bigfoot exercises, even after switching to SQL in our backend.

To run the frontend repo, run npm i to install packages and npm run dev to compile our files and then open the browser of your choice at the site "http://localhost5173".

Retrieve sighting data in frontend from backend

  1. Verify the backend API /sightings is working as expected by starting the backend server as per above instructions and sending a request to localhost:3000 in Thunder Client. The API request is localhost:3000/sightings it should respond with all sightings in JSON format.

  2. Write code in our frontend app to query the backend API on component mount and render all sightings on the page. Feel free to only render basic info for each sighting such as year, season and month. Remember to store sightings in state, which will trigger a re-render, instead of trying to query the backend API on every render, which would be inefficient.

    1. If using useEffect, consider passing a dependency array as a 2nd parameter to useEffect to optimise performance and prevent unnecessary renders.

  3. Add cors to our backend. Without cors we may notice that the data is not loading in our frontend, and we get the following error in our browser console: "Access to XMLHttpRequest at 'http://localhost:3000/' from origin 'http://localhost:3001' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."

Retrieve individual sighting data

Render basic sighting info for each sighting in the sightings list on the homepage. When we click on an individual sighting, navigate to a separate page that renders the full data for that specific sighting.

  1. Create a new route in the backend /sightings/:sightingIndex that returns data for the sighting at the sighting index in URL params. Sighting index refers to the sighting's index in sightings.json in the backend.

  2. Use React Router to implement frontend routing for the homepage and individual sighting pages, and include a back button on the individual sighting pages to go back to the homepage

    1. Consider using nested routes to re-use UI logic, URL params to retrieve individual sighting indexes from URLs, and an index route to render the full sighting list. You can also use useSearchParams to update your frontend URL.

    2. Rocket recommends the frontend route /sightings/:sightingIndex for individual sighting routes for clarity of communication

    3. Consider using Link components to navigate between pages

  3. When we navigate directly to the URL for an individual sighting, e.g. localhost:5173/sightings/1, render that specific sighting's page.

Store backend URL in constant variable

We will store a single instance of our backend URL BACKEND_URL in a new file constants.jsx that we reference everywhere we need the backend URL. We do this because our backend URL will change depending on whether we run our app locally or in production, and we do not want to update a hard-coded backend URL in our code every time we switch between local and production environments, nor declare redundant logic to determine the correct backend URL in each component that uses the backend URL.

When we deploy our app to production in later exercises we can write logic in constants.jsx to set BACKEND_URL based on the value of Vitejs built-in environment variable import.meta.env.VITE_SOME_NODE_ENV. NODE_ENV will tell us which development environment we are in ("development", "test", or "production"), allowing us to set BACKEND_URL accordingly.

For now, create a new file constants.jsx and add the following content.

export const BACKEND_URL = "http://localhost:3000";

Then update all references to http://localhost:3000 in our components to import and use the BACKEND_URL constant variable.

Comfortable: Filter Sightings

Create filter functionality in frontend UI that allows users to filter sightings by their attributes. For example, filtering by the year 1990 would render only sightings in 1990. Use URL search params to reflect filter settings in the URL.

Update the backend root route /sightings to retrieve only the filtered data (if there is a filter) using URL query parameters. Do not retrieve all sightings from the backend and filter on the frontend.

More Comfortable: Sort Sightings

Create sort functionality in frontend UI that allows users to sort sightings by specified sighting attributes and in either ascending or descending order. Sorting should happen in addition to filtering. Feel free to perform sorting on either frontend or backend, and if sorting is on backend, send the sort parameters as query parameters like what we did with the filter feature.

Submission

Submit pull requests to the main branches of Rocket's Bigfoot Frontend and Bigfoot JSON Backend repos respectively, and share your PR links in your section Slack channel.

There is no need to deploy this exercise for now. We will build on it in upcoming Bigfoot exercises and replace our JSON database with a SQL database before deploying.

Reference Solution

Here is reference code for the frontend and the backend for this exercise. You can do better!

Previous3.E: ExercisesNext3.E.2: Bigfoot SQL

Last updated