Let’s build a FullStack App with JavaScript! ~ Episode 2

This is a multipart series about building a Puppy Adoption Site with JavaScript. If you haven’t read all the articles please find them here: Episode 1| Episode 2 | Episode 3 | Episode 4 | Episode 5-Part 1 | Episode 5-Part 2 | Episode 6

Let’s build a server!

Let’s not leave it up to Fido on this one. Instead, we’ll rely on Express.js to get us up and running in just a few minutes!

What is Express?

According to its website, Express is:

… a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

The way we can think about Express is, it sits on top of our Node.js server and allows us to add bonus functionality that makes building our API much easier.

For our project, we’ll be using Express to streamline our server construction and to define our API routes more seamlessly.

Let’s dive in and see how we can be to create our server and first route!

Start me up!

What if I told you in order to get our server up and running we only need eight lines of code? It sounds crazy, but with Express servers become an easy objective to maneuver.

To start, I’ll share the code that allows us to configure our server and then I’ll share how we launch our server to a local host (our machines).

For each code snippet I share, I’ll dive into exactly what we’re doing with each line. So for now, go ahead and place these snippets inside your index.js file:

const express = require('express');
const server = express();
server.use(express.json());

I like to think of these three lines of code as our party starters. They’re the invitations we send out so everybody knows it’s about to go down… and we’re making it clear that the party is Express themed🥳.

Here’s what each line is doing:

1. const express = require('express'): This line is our import. We’re just telling our application that we require Express for this page.
2. const server = express(): In the express documentation you’ll see this written out as const app = express(). In either case, we’re creating a new server. This is akin to running .createServer in Node.js.
3. server.use(express.json()): Lastly, we tell our server to use a built-in Express Middleware that will allow us to read the data we send back and forth. It’s telling our backend to be expecting JSON and it will only parse JSON requests. This will be important when we start passing data to our database.

Ok awesome, we’ve got our nifty server wired butttt we’re not doing anything with it yet. To launch our server we need to assign it a port to run on and then tell our server to listen to connections on that specified port.

Essentially, we’re telling our server: “Hey server, you’re going to run on this port, and listen for any actions that come your way, capeesh?” To which they respond, “Which server? Oh, this one you’ve assigned me to! You got it, boss!”

To translate this exchange into code we can do it two ways. My preferred method is this:

//Define our port variable
const port = process.env.PORT || 5000;
//Instruct our server to listen fort connections on that port
server.listen(port, ()=> console.log(`\n Running on port ${port}\n`))

In this example, we define our port variable by providing two options: process.env.PORT and 5000. The process.env.PORT is there for when we deploy our server to a hosting service. It allows our host to configure the server’s port based on availability. And if we are not deployed, our port will default to whatever we define in our .env file or the value provided in an or statement (in our example that’s the 5000).

A little complex, but it provides flexibility to our code and is great when we turn to production. If we want a hard-coded solution you can always use this:

server.listen(5000, ()=> console.log(`\n Running on port 5000\n`))

This achieves the same goal but will need some refactoring when it comes to production.

Our server is ready to be fired up! But before we launch I have to ask… does anyone remember when we dove into our package.json and defined our "start" value in our "scripts" object?

This happened in the last article, but what we did was define how our system should run our start command. By setting it tonodemon index.js we’re telling our terminal to use nodemon to monitor our server but also to watch our index.js file to see more specifics about our server.

Now that we have the logic to our start command, let’s go ahead and fire this bad boy up!

Go ahead and hop in your terminal and try the command yarn start. You should see a little message pop up that says, Running on port 5000. That is our defined console.log coming to play!

Now What?

Ok, it’s awesome that we have our server up and running, but what’s actually going on at port 5000? Open up your web browser of choice and paste in this URL: http://localhost:5000/. You should be greeted by a page with the message Cannot GET /.

It should look like this ^^^

You might be thinking, “Matt, you said our server was running… what the heck is this nonsense?”

Don’t worry, I can explain! The good news is our server is running, It might not look it now but believe me it’s there. If you have the message Running on port 5000 displayed in your terminal, that means the server is a go.

The issue we’re running into is we haven’t passed our server any meaningful information. We haven’t defined a route or provided content/data for the server to render. Luckily, there’s a lot we can do to fix this!

What we need is to build out a RESTful API and define some routes for our server to interact with. When we build our API we, the backend, are constructing routes so that our client-side, the frontend, can communicate and manage our resources.

If you’re familiar with CRUD operations, essentially we’re designing and wiring the routes our frontend needs to take to interact with our stored data. Right now in our project, it’s unclear what our data is going to look like (foreshadowing for Episode 3 🤔), so to predefine routes probably isn’t the best idea. However, we can certainly create a route to our root route -http://localhost:5000/- to make sure we’re getting more than a console.log().

In order to do that we need to create a new route handler. A route handler takes a defined route and depending on the defined HTTP CRUD request it will perform that action.

Luckily, Express comes with built-in HTTP CRUD requests so we can perform.get(), .update(), .post() and .delete() easily. For the purposes of just getting rolling, let’s just do a simple .get() call that will send a message to our browser window. To do that use this syntax:

server.get('/', (req, res) => {
  res.send("Woof Woof! We Out the Pound!")
});

Gulp, new syntax here… let’s break it down so we know what’s up.

server.get(): we’ve seen that server variable before we defined that earlier. And the .get is the HTTP get request we discussed above.

'/': is where we define the route to our URL. So every time we navigate to our localhost:5000/ we will be firing this get call. But after that things get very new… so let’s dive in a bit.

(req, res): Route handlers pass two arguments (objects) when they are called: therequest and response. We can utilize our request(req) object to send information from our client to our server and then we can use our response(res) to send information to our client. This will become more useful when we start adding users or dogs to our application but for now know we’ll be using them to pass basic strings around.

res.send("Woof Woof! We Out the Pound!"): Speaking of strings, that’s exactly what we’re doing here! Express comes with more built-in methods that allow us to streamline the management of our res and req objects. In this instance, we are using the .send() method to send our HTTP response. In this example, we hard code that with "Woof Woof! We Out the Pound!" but in the future that can be the data we’re pulling from our database.

Sorry if that was a lot, but understanding the logic of our routes, HTTP requests, and server will allow us to wire up our API in no time… once we organize our data!

Go ahead and add this request to your index.js make sure it’s above your port variable, but below your server declaration. Then go view your browser at the previous URL - localhost:5000/.

You should now see this in the browser:

Wahoo!!

Woof Woof! We got our first get request working!

That’s right Eric!

Wrap Up

Now that we have our server up and running we’ll be able to wire up the rest of our API very soon! But before we do that, we’re going to need to talk about the Data we want to store.

Be on the lookout for the next article, where we discuss the process of Data Modeling and how we want our database for this project to look!

In case your code got tripped up along the way, here’s a snippet of what your index.js file should look like at this point:

//index.js
//Our imports and Express Server Declaration 
const express = require('express');
const server = express();
server.use(express.json());
//Our 1st Get request to the route '/'
server.get('/', (req, res) => {
  res.send("Woof Woof! We Out the Pound!")
});
//Port Definition and Server Listener
const port = process.env.PORT || 5000;
server.listen(port, ()=> console.log(`\n Running on port ${port}\n`))

If you’re still not able to see our message at the URL localhost:5000/ feel free to reach out on Medium or Twitter!