This video is available to students only

Project setup and scaffolding

We put the foundations of the Dinosaur Search App in place such as creating a new React app and exploring the supporting API

You may be unsurprised to learn that dinosaurs are quite old and that there isn’t much data around for a fair few of them. What is a little surprising however is that there are zero live APIs out in the wild that deal with dinosaur-exclusive data!

But fear not, because I have got you covered. In the accompanying course material there is a starter project for this module that includes a client and a server folder. We’ll be building everything we have planned in the client folder, but the server folder houses a fully-functional Node-based API that will provide us with all we need to serve our app.

We’re going to quickly spin up the API server and take a brief look at the queries we can make and the sort of data we’ll get back, as well as how to start it.

If you’re interested in learning more about this Node server starter-kit, then I have a helpful article on this very subject on my website. There’s also a link to a starter API project on my GitHub too!

Opening and running the starter project#

Here’s where you can grab the project files for this course, if you haven’t already done so. You’ll need them for this last module as they include the API server, which we won't be building from scratch!

Click here to download the course code and materials.

Once you’ve downloaded the project files, I’d recommend creating a new folder on your local machine to house them. For example I created the following empty folder on my local machine, called /code/demos/dino-search-app.

Copy the contents of /module_10/start/ into your new local folder. When you’re finished you should have a folder structure that looks like this:

  • /dino-search-app

  • --/client

  • --/server

Open up the project in VS Code (or your favorite editor) and let’s take a look at the API files.

Queries and routing#

In the /data folder we have dinos.json file. If you take a look at this file you’ll find a huge list of more than 50 objects that each represent a collection of information points for a particular dinosaur. Each has a unique id value, name, location, image filename, and some other relevant info.

Open up the /server.js file and you’ll see the bare minimum required to get an ExpressJS-powered Node server up and running. This file creates the server, app and plugs in the /routes/routes.js file, which serves various API end points.

The other thing to note here is that we explicitly define a static /images route here that will allow us to serve images directly from the API as image data, rather than a set of JSON results, as with the dinosaur data. In the frontend client app we can call this endpoint like /images/image_name.jpg and simulate grabbing an image from a CDN, rather than having to house the dinosaur images locally in our frontend project where they don’t really belong.

If you look in the /routes folder we have a main routes.js file that collects the other two files in this folder (dinos.js and login.js ) and plugs them into the Express JS server that we just outlined.

login.js#

The login.js file serves a single route, /api/login and is fairly dumb in its operation. If there is both a username and a password value supplied it will generate a dummy JWT token for us and return it to the caller. If neither is supplied then it returns a 401 error to indicate the user is unauthorized. Of course, this is not in the least bit secure or hooked to up an actual authentication system, but it will serve the purpose of simulating one for our frontend client app which doesn’t need to care about the backend implementation anyway, just what’s returned from the API.

dinos.js#

The dinos.js file is where the API caters for all the dinosaur-related endpoints. It handles:

  • /api/dinos for fetching all dinosaur information.

  • /api/dinos/search/:term for fetching a filtered list of dino information based on whether the :term parameter is a single character or a name of some sort.

  • /api/dinos/:id for grabbing a single dinosaur object.

We don’t need to go into go into great detail about the inner workings of the API setup here (you can refer to my article on this exact thing if you’re curious), but the basic operation is that each API endpoint uses the Node fs function to read the dinos.json file. Depending on the endpoint called, the resulting JSON data is filtered and formatted and then returned to the caller as JSON data.

Running the API#

Before we plough on with the front-facing client app, let’s quickly spin up the API server and check that it’s working OK.

In your terminal, navigate to the root of the /server folder. If this is the first time you’re running it then you’ll need to install the dependencies with the following command:

Once that’s finished, run the start command:

Nothing exciting will happen at this point, but you should see a message in the terminal saying ‘listening on port 4000…’ which means the API server is running.

Once we’ve created the client app for the Dinosaur Search in the upcoming lessons and are ready to run it, you’ll need to make sure this API is running before starting the client app. Don’t worry, I’ll remind you at the right time, but it doesn’t hurt to make a mental note here that you’ll need to jump into the /server file and run the yarn start command first.

If you open a browser and navigate to http://localhost:4000 you will see a white screen with the message ‘welcome to the development dinosaur api-server’ displayed. If you navigate to the main dinosaur route, http://localhost:4000/api/dinos then you’ll see a more interesting result — the list of all dinosaur information objects returned to the browser as JSON data.

I’m using Firefox here so your display may vary, but the idea is the same.

Project set up#

Now that we have a good idea of what’s what with the API server part of the project, we need to focus on building the frontend client app in our beloved React. Once again we’ll be calling on the Create React App project to get us off to a best-practice flying start.

Installing a new Create React App project#

Since we’ve already got a starter project and a folder, /client, where we want our frontend files to live, using the default Create React App project command can be a little more cumbersome, but let’s walk through it and see if we make it out the other side unscathed.

Open up a terminal window to the dinosaur project folder and leave it at the project root (the one at the same level as the /client and /server folders). Now run the familiar command:

Once it’s finished, open up the folder on your machine and cut-and-paste all of the contents into the /client folder. Once this is done, delete the dino-search-app folder, as we don’t need it.

Project clean up#

Now that we’ve got a shiny new Create React App instance installed and ready to go, let’s move through the same parts as in previous lessons, and clean up the default files a little.

  • Open index.js, and remove the reference to import ‘./index.css'.

  • Delete the /src/index.css and /src/App.css files.

  • Open the main App.js file and empty it so we can add our demo-specific code later on.

Adding dependencies#

We’ll need to add a few dependencies to our app, namely:

  • axios - our old friend axios will help us talk to our dino API and fetch the important fossil data for us.

  • bulma - no surprises here, Bulma will add nice styles and look and feel to the UI for us.

  • react-router-dom - again we’ll be leaning on this package to route our users between pages and areas of the app.

  • @fortawesome/fontawesome-free - this is a new one, but the popular font-icon library provides support to Bulma, allowing us to display some nice icons along with the dinosaur information.

  • node-sass - and we’ve used node-sass previously to compile our .scss files into the browser-useable .css files.

Let’s work through them, adding them all to the project via the familiar yarn add [dependency name] syntax we know and love. You could add them all at once by changing their names onto the end of the yarn add command if you wish, but I’m adding them one by one here for clarity and to ensure that there’s no mistakes that could be caused by misspellings or typos.

Note we’ll add the node-sass dependency as a dev type. It’s not the end of the world if you don’t, but if the app doesn’t need it to run then it’s a good idea to add it here.

Wiring up the proxy#

This is going to be an unfamiliar part of the process that we’ve not covered yet. However, the Create React App scripts offer a special property, proxy that you can add to your package.json file.

Open up the package.json file and add the following line at the end of the file:

Essentially the proxy property here allows you to proxy (i.e. an intermediary for requests) requests between front and back-end apps that are using the same port. It’s something that can happen more frequently in local development scenarios.

Our front-end app and the API we’re calling aren’t running on the same port, but this does have an added benefit of not having to deal with irksome CORs errors and blockages, especially when we don’t have any security concerns at the moment since we’re running everything on our local, sealed off machines. Also, it means we can avoid writing longer API URLs because the value we add here is automatically prepended to requests that aren’t text/HTML in nature — e.g. API calls.

You can read more about the proxy function in the Create React App documentation.

We’ll be using a little cartoon dinosaur mascot as out logo in a few places throughout our app, namely this little guy:

 

This page is a preview of Beginner's Guide to Real World React

Please select a discussion on the left.