Starter Files

Introduction

Having created a new repo and cloned it to your computer, let's take a few minutes and add a few more folders and make a name change, then become familiar with what's here and why.

Video Overview

The video provides a general overview of the activity, but does not contain the detail needed to complete each process. Watch the video to obtain a general idea, but follow the written steps to complete the activity. This is the Transcript of the video.

Change the File Name

Notice that you have a file named .env.sample. We need to change the name.

1. Right-click the .env.sample file, select "Rename".
2. Remove the .sample part of the name leaving just .env
3. Click off of the file and ensure that the name is now correct.

Folder Cleanup

There are four folders in the repo that require some cleanup. In order for folders to exist on GitHub, they cannot be empty. Now that the download is complete, open each of these folders and delete the placeholder.txt file you will find. The four folders are 1) controllers, 2) database, 3) models, and 4) views. When done, your repo work space should look like the image below.

The Root Files

Your repo folder constitutes the "root" of your application. There should be five new files at the root: .env, .gitignore, package.json, readme.md, and server.js.

.env

Any file that begins with a period is typically a "hidden" file, meaning that the operating system will hide it in the finder generated list of files and folders. However, VS Code will show this file as it is meant to be worked with.

Open the file, and you'll find that it has some name - value pairs already present. These name - value pairs hold information critical for the operation of the application on your local machine. Later, you'll create equivelent name - value pairs in your production environment. "Env" is short for "environment". It is a place to store these critical, sensitive values where the application can use them, without exposing them to others.

.gitignore

Like the .env file, the .gitignore file is not visible in the OS provided list of file and folders. This file is specific to GIT. As the name implies, it directs GIT to ignore any folder or file that is listed inside this file.

Open the file. You'll find that it currently is mostly comments, but lists three items: node_modules, .env, and .DS_Store. Read the comments associated with each. This file will be modified later in the course to include other items. For now, know that any file or folder listed in the .gitignore file will NOT be synced to your remote GitHub repo, which is exactly why we have it.

package.json

When building a Node application, this file is critical. It lists all the resources needed for the application to function. It includes scripts and directions for running the application in a local, development environment and can also be modified to include directions for remote, production environments.

Readme.md

The readme file is not required, but can be helpful. In this case, it contains a brief overview of how to make use of these starter files and folders.

Let's make your first edit to the .gitignore file.

1. Open the .gitignore file.
2. Move to the bottom and add the README.md file to it.
3. Save the .gitignore file, and close it.
4. When you make your next commit, the readme file will NOT be included and the copy that was synced previously to your remote repo will be removed.

server.js

This file is the primary operational file for the application. It is the default file that will be read by the Node application. We will work with it extensively in the coming weeks. Note: this file can typically have one of three different names: index.js, app.js, or server.js. You will see all three used. The reason I have choosen for us to use server.js is that I think it adds clarity since it is where we will declare the server operations for our application.

If you open the package.json file, looking at line 5 you will see that the server.js file is declared as the "main" file for the application. It is also mentioned on lines 7 and 8 as the file to be run in our different operating environments ("start" is for production, while "dev" is for development).

The Folders

controllers

We will be using a "Model - View - Controller" (MVC) design pattern for our application. This is the most common pattern for application development and one that you'll want to know and be comfortable with. The controllers folder is where all controller files will be stored.

database

When we build our database and begin to interact with it, we'll want to store the file that allows us to connect to and communicate with the database. This is where that file will be stored. It could be stored elsewhere, but by storing it in a database folder, I hope to add clarity.

models

In the MVC design pattern, a "model" is where data is described and interactions with that data can be stored. In our case, we will build models that will contain the SQL statements and JavaScript functions that will use the SQL statements to actually work with the data in the database. These functions will be responsible for the CRUD (CREATE, READ, UPDATE, DELETE) operations between our application and the database.

public

A Node application is primarily involved with generating dynamic content (content built by the application as it interacts with the database). However, a web application is seldom 100% dynamic. It relies on "static" (non-dynamic) files, e.g. CSS, HTML and client-side JavaScript. The public folder is where these static files will be stored.

routes

A popular holiday song, in the United States, has the lyric "over the river and through the woods to grandmother's house we go". This describes the route or way to get to grandmother's house. A route is a path to be followed to arrive at a destination. Our application will use routes to describe how a particular dynamic interaction is to occur. A URL is a route that describes such an interaction.

In a small application all routes could be written in the main file (server.js). However, as applications grow larger and more complex, the routes for a specific type of interaction are broken out into their own files. These specific route files will be stored here.

views

A view is a dynamically generated page, containing content that the server produces and returns to the browser. The scaffolds that will hold the content are built and stored in the views folder. A view is what appears in the browser - it is how content is "viewed". The view is how the backend process is substantiated, or confirmed, to the client. An interaction between the client and the server, typically begins and ends with a view, except in the case of an API (application programming interface).

Conclusion

You should now have a clearer notion of the purposes of these files and folders. Keep in mind that we will add to these over the semester, but this basic structure gives us what we need to get started.