As we've discussed, JavaScript in the backend is incredibly useful for creating web applications and harnessing the power of JavaScript on both the front- and back-end. One of the most fundamental tools for a server-side application that interacts with the frontend is a basic web server. In order to provide APIs, database access, and other functionality that is not designed to be handled by the browser, we first need to set up a piece of software to handle these interactions.
Express.js (or just Express) is a web application framework, considered the de facto web server of Node.js. It enjoys both high popularity and ease of use. Let's use it to build a full-blown web app.
The following topics will be covered in this chapter:
- The scaffold: Using express-generator
- Routes and views
- Controllers and data: Using APIs in Express
- Creating an API with Express
Technical requirements
Be prepared to work with the GitHub repository at https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers/tree/master/chapter-13. All you'll need is a code editor and a browser. In the Routes and views section, we'll discuss a few best practices for working with code editors.
The command-line examples are presented in macOS/Linux style. Windows users might need to consult the documentation to understand a few nuances of the Windows command line.
The scaffold: Using express-generator
To get started, we'll need to get on our command-line interface (CLI) again. If you remember Chapter 2, Can We Use JavaScript Server-Side? Sure!, we took a look at Node and npm on the command line. Let's check our version again so we can make a few decisions about our application. On your command line, run node -v. If you have v8.2.0 or greater, you have the option of using npx to install certain packages that are designed to be run only once in the lifespan of a project, such as express-generator. However, if you have a lower version, you can use npm to install one-time-use packages as well as packages that are used in your project.
We'll move forward with npx in this chapter, so if you need to take a quick look at the documentation for npm versus npx, be sure to give yourself some time to do that. In essence, to use npm for one-time packages that shouldn't live inside your code base, for example, a scaffolding tool such as an Express generator or a React app creator, you can install the package globally on your system like this: npm install -g express-generator. Then, you'll run the program with Express. However, this is considered a legacy usage of npm as npx is favored in today's landscape.
Let's create our Express app from scratch to build up muscle memory instead of continuing on from Chapter 2, Can We Use JavaScript Server-Side? Sure!. Follow these steps to get started on an Express web server:
- In a convenient location, create a new directory with mkdir my-webapp.
- Navigate inside it with cd my-webapp.
- The npx express-generator --view=hbs express generator will create several files and directories:
Figure 13.1 - Creating our Express scaffold
We're going to set our application to use Handlebars for our templating instead of Jade, which is the default option. Express supports multiple templating languages out of the box (and can be extended to use any), but for ease of use, we'll stick with Handlebars, which is very similar to how we worked with frontend frameworks such as React and Vue in Chapter 8, Working with Frameworks and Libraries, with basic curly brace tokens.
- Use npm install to install our dependencies. (Note that even if you used npx before, you're going to use npm here.) This is going to take a few seconds and will download a number of packages and other dependencies. Another thing to note is that you will need an internet connection, as npm retrieves packages from the internet.
- Now, we're ready to start our application using npm start:
Figure 13.2 - Our application starting
- OK! Now, let's access our Express site in a web browser:
Figure 13.3 - Express welcome page
Fantastic! Now that we're at this step, let's take this further than we did in Chapter 2, Can We Use JavaScript Server-Side? Sure!.
RESTful architecture
At the core of many web apps is a REST (or RESTful) application. REST is an abbreviation of REpresentational State Transfer, which is a design pattern that deals with the fact that most web technologies are inherently stateless. Think of a standard website that doesn't require a login or much data—just static HTML and CSS, as we created in the previous chapters, but even simpler: without JavaScript. If we think of a site like this in terms of state, we can see that a bunch of HTML doesn't know our user journey, doesn't know who we are, and, quite frankly, it doesn't care. Sites like these are like printed material: you interact with it by looking, reading, and turning pages. You don't change anything about it. In general, the only way you're really modifying the state of a book is with a bookmark to save your place. Honestly, that's one step more interactive than a basic blob of HTML and CSS!
To work with users and data, REST is used as a functional paradigm. We already worked with two of the main HTTP verbs when working with APIs: GET and POST. These are the two main verbs that we'll be using, but we'll be looking at two more: PUT and DELETE.
If you're familiar with the concept of Create, Read, Update, and Delete (CRUD), this is how the standard HTTP REST verbs translate:
|
Concept
|
HTTP Verb
|
|
Create
|
CREATE
|
|
Read
|
GET
|
|
Update
|
PUT or PATCH
|
|
Delete
|
DELETE
|
Now, it is possible to create a full application only using GET, or just GET and POST, but there are security and architectural reasons why you wouldn't want to do this. For now, let's agree to follow best practices and work within this established paradigm.
Now, we're going to create a RESTful application.
Routes and views
Routes and views are the foundation of how a RESTful application's URLs act as pathways to its logic and how content is presented back to the user. Routes will determine what parts of code correspond to the URLs of the application's interface. Views determine what is displayed, either to a browser, another API, or other programmatic access.
To further understand the structure of an Express application, we can examine its routes and views:
- First of all, let's open our Express application in your favorite IDE. I'm going to be working with VS Code. If you use VS Code, Atom, Sublime, or another IDE that has command-line tools, I highly recommend installing them. For example, with Atom, you can launch a multi-panel Atom editing interface by typing atom . in the command prompt and opening that directory in Atom.
- Similarly, VS Code will do this with code .. Here's what this looks like:
Figure 13.4 - VS Code
I've expanded the directories on the left so that we can see the first level of the hierarchy.
- Open app.js.
One of the first things you'll notice is that the syntax of this code that express-generator created for us is ES5, not ES6. For the moment, let's not concern ourselves with converting it to ES6; we'll do that a bit later. As we work on our first Node.js REST application, keep in mind that there are a couple of different ways of achieving our goal, and we'll take the more verbose path first in order to get our functionality working and then iterate on it to make it more flexible and more DRY.
- Right now, you shouldn't have to make any changes to app.js, but do take a second to familiarize yourself with its structure. One of the more unfamiliar aspects of it may be the require() statements at the beginning of the file. Similar to how you have used import in a frontend framework, require() is Node's way of signaling to its component system to bring in these pieces from other files. In this case, the first few lines are bringing in modules installed via npm, like so:
var express = require('express');
Note that there is no path in front of ('express'). It's simply stated. This is an indicator that the module referenced is not native to our code. If you look at the require statement for indexRouter, however, we see that it does have a path: './routes/index'. It does not have the .js extension, but it's pathed properly for our module usage.
Now, let's examine our routes/index.js file.
Routes
If you open routes/index.js, you'll see the following few lines of code that were generated for us:
var express = require('express');
var router = express.Router();
/* GET home page. */
router.get('/', function(req, res, next) {
res.render('index', { title: 'Express' });
});
module.exports = router;
There isn't a whole lot surprising here: as we're starting to gather, Express files begin with require statements, especially for express itself. In the next code block, we're starting to see the beginnings of our REST service: GET home page. Look at the router.get() method right after the comment. It's explicitly stating to the router that when a GET request is received for the URL of /, execute this code.
We can verify this fact by adding a few more GET paths here, just for fun. Let's try modifying our code like so. After the router.get() block, but before module.exports, let's register more routes on the router:
/* GET sub page. */
router.get('/hello', function(req, res, next) {
res.render('index', { title: 'Hello! This is a route!' });
});
Now, we must stop our Express server with Ctrl + C, restart it with npm start, and access our new page at http://localhost:3000/hello:
Figure 13.5 - A new route, with the Network tab open, showing we are making a GET request
So far, this should seem pretty basic. Now, let's do something a little different. Let's work with this view and create a form for an Ajax POST request:
- Create a new file called public/javascripts/index.js.
- Write a basic fetch request to the endpoint /hello with POST JSON of { message: "This is from Ajax" } like so:
fetch('/hello', {
method: 'POST',
body: JSON.stringify({ message: "This is from AJAX" }),
headers: {
'Content-Type': 'application/json'
},
});
- Include this file in views/index.hbs like so:
<h1>{{title}}</h1>
<p>Welcome to {{title}}</p>
<p id="data">{{ data }}</p>
<script src="/javascripts/index.js"></script>
Notice that we don't need to include public in our path. This is because Express already understands that files within public are to be served statically without any intervention or parsing from Express, as opposed to Node files that must be run.
- If you reload the page now, you really won't see anything exciting happening because we haven't yet written the route to handle the POST request. Write it like this:
/* POST to sub page. */
router.post('/hello', function(req, res, next) {
res.send(req.body);
});
- Reload your page and you'll see… nothing. No POST in the Network tab, and certainly nothing rendered. What happened?
Node has several tools that are used to reboot Express servers when code is changed so that the engine will refresh itself without us needing to kill and restart it, as we were doing before, but we did not do this time. These tools change over time, but the one I like is Supervisor: https://www.npmjs.com/package/supervisor. Install it in your project simply by executing npm install supervisor in the directory of your project.
- Now, open the package.json file in the root of your project. You should see a file similar to this, but perhaps with some version differences:
{
"name": "my-webapp",
"version": "0.0.0",
"private": true,
"scripts": {
"start": "node ./bin/www"
},
"dependencies": {
"cookie-parser": "~1.4.4",
"debug": "~2.6.9",
"express": "~4.16.1",
"hbs": "~4.0.4",
"http-errors": "~1.6.3",
"morgan": "~1.9.1",
"supervisor": "^0.12.0"
}
}
This is the core of what is installed when running npm install. When you run it, you'll see a node_modules directory created and many files written there.
If you're using version control such as Git, you will not want to commit the node_modules directory. With Git, you would include node_modules in a .gitignore file.
- The next thing we want to do is alter our start script to now use Supervisor:
"scripts": {
"start": "supervisor ./bin/www"
},
To use it, we still use npm start and to quit it, you just press Ctrl + C. It's worth noting that Supervisor is best for local development work, not production work; there are other tools such as Forever for that purpose.
- Now, let's run npm start and see what happens. You should see some console messages that end with Press rs for restarting the process. Under most circumstances, issuing rs is not needed, but it is there if you need it:
Figure 13.6 - Response from Ajax!
- Since we sent This is from AJAX from our frontend JavaScript, we're seeing it reflected in our response HTML! Now, if we were to want it in our page, we would do this in our frontend JavaScript:
fetch('/hello', {
method: 'POST',
body: JSON.stringify({ message: "This is from AJAX" }),
headers: {
'Content-Type': 'application/json'
},
}).then((res) => {
return res.json();
}).then((data) => {
document.querySelector('#data').innerHTML = data.message
});
We'll see the following:
Figure 13.7 - A message from Ajax!
Next, let's understand how to save data.
Saving data
For our next step, we'll persist data in a local data store, which will be a simple local JSON file:
- Go ahead and quit Express with Ctrl + C. Let's install an easy module that saves data in a local store: npm install data-store.
- Let's modify our routes to use it, like so:
var express = require('express');
var router = express.Router();
const store = require('data-store')({ path: process.cwd() + '/data.json' });
/* GET home page. */
router.get('/', function(req, res, next) {
res.render('index', { title: 'Express', data:
JSON.stringify(store.get()) });
});
/* GET sub page. */
router.get('/hello', function(req, res, next) {
res.render('index', { title: 'Hello! This is a route!' });
});
/* POST to sub page. */
router.post('/hello', function(req, res) {
store.set('message', { message: `${req.body.message} at ${Date.now()}` })
res.set('Content-Type', 'application/json');
res.send(req.body);
});
module.exports = router;
- Notice the inclusion of store and its use in the hello and / routes. Let's also modify our index.hbs file like this:
<h1>{{title}}</h1>
<p>Welcome to {{title}}</p>
<button id="add">Add Data</button>
<button id="delete">Delete Data</button>
<p id="data">{{ data }}</p>
<script src="/javascripts/index.js"></script>
- We'll use the Delete Data button later, but for now, we'll work with the Add Data button. Add some save logic to public/javascripts/index.js like so:
const addData = () => {
fetch('/hello', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ message: "This is from Ajax" })
}).then((res) => {
return res.json()
}).then((data) => {
document.querySelector('#data').innerHTML = data.message
})
}
- And now we'll add our click handler:
document.querySelector('#add').addEventListener('click', () => {
addData()
window.location = "/"
})
- If you refresh the / page and click the Add Data button, you should see something like this:
Figure 13.8 - Adding data
- Now, refresh that page again. Notice that the message persists. In your filesystem, you should also notice a data.json file that contains the data.
We're now ready to work with this a bit more with a delete method.
Delete
We've explored GET and POST, and now it's time to deal with another foundational REST verb: DELETE.
As its name implies, its goal is to remove data from a data store. We already have our button to do so, so let's wire it up:
- In our frontend JavaScript, we'll add the following:
const deleteData = () => {
fetch('/', {
method: 'DELETE',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ id: 'message' })
})
}
document.querySelector('#delete').addEventListener('click', () => {
deleteData()
window.location = "/"
})
- Now, in the routes, add this route:
/* DELETE from json and return to home page */
router.delete('/', function(req, res) {
store.del(req.body.id);
res.sendStatus(200);
});
And that should be all we need. Refresh your index page and play around with the add and delete buttons. Pretty easy, right? In Chapter 18, Node.js and MongoDB, we'll discuss persisting and manipulating our data in a full-fledged database, but for now, we can work with the knowledge of GET, POST, and DELETE. We'll work with PUT with an actual database.
Views
We touched on the manipulation of views in the Routers section, so let's now dive in deeper. The view layer of an application is the presentation layer, which is why it houses our frontend JavaScript. While not all backend Node applications will serve a frontend, it's handy to know how to use it. Whenever I set up a simple webserver, I reach for Express and its functionality for both the frontend and backend.
Since there are multiple frontend templating languages available to us, let's use Handlebars as an example of logic and structure.
If we want to, we can provide some conditional logic in our frontend code. Note that this logic is rendered by the backend, so it's a good example of when to render data on the backend (which is more performant for the frontend) and when to do it via JavaScript (which is, ostensibly, more flexible).
Let's alter our views/index.hbs file like this:
{{#if data }}
<p id="data">{{ data }}</p>
{{/if}}
Let's also modify routes/index.js:
/* GET home page. */
router.get('/', function(req, res, next) {
res.render('index', { title: 'Express', data:
JSON.stringify(Object.entries(store.get()).length > 0 ? store.get() :
null) });
});
Now, we're using a ternary operator to simplify our display logic. Since our data from the store is JSON, we can't simply test its length: we have to use the Object.entries method. If you're thinking that we could have saved the store.get() to a variable instead of writing it twice, you're right. However, in this case, we don't really need to take up additional memory space since we're immediately returning it versus manipulating it. The performance impact in this scenario is negligible, but it is something to keep in mind.
Now, if we delete our data, we will see this:
Figure 13.9 - After deleting data
It's a little less confusing to see than to see an empty object's curly braces. Sure, we could have done the conditional work on the frontend by writing a more complex conditional, but why do that work when the backend can send us the appropriate data? There are certainly cases for both, but in this case, it's better to let each piece do its own work.
You can find our completed work here: https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers/tree/master/chapter-13/my-webapp.
Let's now turn our attention to how we actually get data into Express using controllers.
Controllers and data: Using APIs in Express
As you may have heard around the web, Express is great because it's not very opinionated on how you use it, and at the same time, people say that Express is hard to work with because it's not opinionated enough! While Express isn't typically set up as a traditional Model-View-Controller setup, it can be beneficial to split functionality out of your routes and into separate controllers, especially if you may end up having similar functionality between routes and want to keep your code DRY.
If you're not very familiar with the Model-View-Controller (MVC) paradigm, don't worry—we won't go into it in too much detail, as it's a very weighty topic, complete with its own debates and conventions. For now, we'll just define a few terms:
- A Model is a part of the application that deals with data manipulation, especially communication to and from a database.
- A Controller deals with logic from routes (that is, the path of the HTTP request from the user).
- The Views are the presentation layer to the end-client that provides markup to the client, routed by the controller.
This is what the MVC paradigm looks like:
Figure 13.10 - The MVC paradigm
Let's take a look at a sample application. At https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers/tree/master/chapter-13/controllers is an application that uses Express.
This is an API that uses controllers and models. As we'll see, this structure will simplify our workflow. It's still a fairly simple example, but this will give you a sense of why controllers and models can come in handy. Let's investigate it:
- Go ahead and run npm install, and then run npm start to run the application. It should be accessible in your browser at http://localhost:3000, but if you have anything else running, Node will warn you and state a different port. Here's what you'll see:
Figure 13.11 - Our sample Express application
- Pretty simple so far. Go ahead and click Add User a few times and play around with the functionality. This uses a random user API on the backend to create users and persist them to a filesystem data store.
- Examine the client-side JavaScript in the public/javascripts directory. This should all look familiar. If we remember the structure of the fetch() call, it returns a promise, so we can use the .then() paradigm to react to our events.
- In public/javascripts/index.js, we can see the mechanism that creates our users when we click Add User:
document.querySelector('.add-user').addEventListener('click', (e) => {
fetch('/user', {
method: 'POST'
}).then( (data) => {
window.location.reload()
})
})
This shouldn't be anything surprising: we're using JavaScript's fetch in an event handler to call the /user route with a POST. A route is basically an endpoint in an Express (or other) application: it contains some logic to react to an event. So, what is that logic?
- Open routes/user.js:
var express = require('express');
var router = express.Router();
const UsersController = require('../controllers/users');
/* GET all users. */
router.get('/', async (req, res, next) => {
res.send(await UsersController.getUsers());
});
/* GET user. */
router.get('/:user', async (req, res, next) => {
const user = await UsersController.getUser(req.params.user);
res.render('user', { user: user });
});
/* POST to create user. */
router.post('/', async (req, res, next) => {
await UsersController.createUser();
res.send(await UsersController.getUsers());
});
/* DELETE user. */
router.delete('/:user', async (req, res, next) => {
await UsersController.deleteUser(req.params.user);
res.sendStatus(200);
});
module.exports = router;
Let's first compare the structure of this to the other examples. First, we'll see the require() statement for the controller for users. There's a router.post() method statement here, which is using async/await for asynchronous calls to our controller. Our controller will then call our model to do database work.
So far, there are a good number of files and paths for execution. Before we get too lost in the code, let's take a look at a diagram of how a frontend method, such as the Add User click handler, communicates with our Express backend:
Figure 13.14 - End-to-end communication
Reading from left-to-right and top-to-bottom, we can see how each step in the process plays its role. It may look a bit complicated for something as basic as retrieving information from an API, but part of the power of this architectural pattern is that each layer can be written and controlled by a different party. For example, the model layer will often be in the hands of database experts, as opposed to other types of backend developers.
As you trace through the code for the controller and model, consider how the separation of concerns at each layer of the code makes for a more modular design. For example, we're using a LocalStorage database to store our users. If we wanted to swap LocalStorage for a more robust system, such as MongoDB, we would really only have one file to edit: the model. In fact, even the model may be abstracted to have unified data handlers and then use an adapter for specific database methods.
That might be a bit much for us right now, but let's next turn our sights on creating a starship game using the principles we just learned. We'll use this Node.js backend for our final project to make a frontend for the game in JavaScript.
In the next section, we'll get started with creating our game's API.
Creating an API with Express
Who doesn't like a nice starship battle, like in Star Wars or Star Trek? I happen to be quite a fan of science fiction, so let's play along and construct a RESTful API using storage, routes, controllers, and models to keep track of our gameplay. While we'll be focusing on the backend of this application, we'll stand up a simple frontend for the population of data and testing.
You can find a work-in-progress example app at https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers/tree/master/chapter-13/starship-app. Let's start there, and you can finish it using the following steps:
- Clone the repository if you haven't already.
- Navigate into the directory with cd starship-app and run npm install.
- Start the project with npm start.
- Open http://localhost:3000 in a browser. If you already have any projects running on port 3000, the start command may prompt you to use a different port. Here's our basic frontend:
Figure 13.15 - Starship Fleet
- Go ahead and play around with adding and scuttling ships both randomly and manually. This will be the setup for our gameplay.
- Now, let's unpack what the code is doing. Here's our file structure:
.
├── README.md
├── app.js
├── bin
│ └── www
├── controllers
│ └── ships.js
├── data
│ └── starship-names.json
├── models
│ └── ships.js
├── package-lock.json
├── package.json
├── public
│ ├── images
│ │ └── bg.jpg
│ ├── javascripts
│ │ └── index.js
│ └── stylesheets
│ └── style.css
├── routes
│ ├── index.js
│ ├── ships.js
│ └── users.js
└── views
├── error.hbs
├── index.hbs
└── layout.hbs
- Open public/javascripts/index.js. Let's first examine the event handler for random ship creation:
document.querySelector('.random').addEventListener('click', () => {
fetch('/ships/random', {
method: 'POST'
}).then( () => {
window.location.reload();
})
})
So far so good. This should all look familiar.
- Let's examine this route: /ships/random. Open routes/ships.js (we can guess that the routing for /ships/ will be in the ships.js file, but we can confirm this by reading the routing in the app.js file, as we've learned). Read through the /random route:
router.post('/random', async (req, res, next) => {
await ShipsController.createRandom();
res.sendStatus(200);
});
The first thing we'll notice is that this is an async/await construction, as we're going to be working with fetch on the frontend and (spoiler alert) a database on the backend.
- Let's look at that controller method next:
exports.createRandom = async () => {
return await ShipsModel.createRandom();
}
- Easy enough. Now for the model method:
exports.createRandom = async () => {
const shipNames = require('../data/starship-names');
const randomSeed = Math.ceil(Math.random() *
shipNames.names.length);
const shipData = {
name: shipNames.names[randomSeed],
registry: `NCC-${Math.round(Math.random()*10000)}`,
shields: 100,
torpedoes: Math.round(Math.random()*255+1),
hull: 0,
speed: (Math.random()*9+1).toPrecision(2),
phasers: Math.round(Math.random()*100+1),
x: 0,
y: 0,
z: 0
};
if (storage.getItem(shipData.registry) || storage.values('name')
== shipData.name) {
shipData.registry = `NCC-${Math.round(Math.random()*10000)}`;
shipData.name = shipNames.names[Math.round(Math.random()*
shipNames.names.length)];
}
await storage.setItem(shipData.registry, shipData);
return;
}
OK, it's a bit more complicated, so let's unpack this. The first couple of lines are simply selecting a random name from a seed file provided for you. Our shipData object is constructed from several key/value pairs, each corresponding to specific properties of our newly-created ship. After that, we check our database to see whether there's already a ship by that name or registry number. If so, we'll randomize again.
However, as with every application, there are areas for improvement. Here's a challenge for you.
Challenge
Here's your first task: can you think of how to improve the code so that in the re-randomization, it elegantly checks to see whether the new randomization also exists in our database? Hint: you may want to create a separate helper function or two.
Maybe you arrived at something like this (https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers/tree/master/chapter-13/starship-app-solution1):
const eliminateExistingShips = async () => {
const shipNames = require('../data/starship-names');
const ships = await storage.values();
const names = Object.values(ships).map((value, index, arr) => {
return value.name;
});
const availableNames = shipNames.names.filter((val) => {
return !names.includes(val);
});
const unavailableRegistryNumbers = Object.values(ships).map((value, index,
arr) => {
return value.registry;
});
return { names: availableNames, unavailableRegistries:
unavailableRegistryNumbers };
}
And to use it, execute the following command:
exports.createRandom = async () => {
const { names, unavailableRegistries } = await eliminateExistingShips();
const randomSeed = Math.ceil(Math.random() * names.length);
const shipData = {
name: names[randomSeed],
registry: `NCC-${Math.round(Math.random() * 10000)}`,
shields: 100,
torpedoes: Math.round(Math.random() * 255 + 1),
hull: 0,
speed: (Math.random() * 9 + 1).toPrecision(2),
phasers: Math.round(Math.random() * 100 + 1),
x: 0,
y: 0,
z: 0
};
while (unavailableRegistries.includes(shipData.registry)) {
shipData.registry = `NCC-${Math.round(Math.random() * 10000)}`;
}
await storage.setItem(shipData.registry, shipData);
return;
}
So, what are we doing here? First, let's look at the usage of Objects.map:
const names = Object.values(ships).map((value, index, arr) => {
return value.name;
});
Here, we're using the .map() method of the ships object to create a new array of only the names of our existing ships. Essentially, what we're doing is just returning each name of the object into our array, so now we have an enumerable data type.
Next, we want to eliminate used names from our possibilities, so we'll use the .filter() function of arrays to only return the value if it's not included in the array we created previously:
const availableNames = shipNames.names.filter((val) => {
return !names.includes(val);
});
We do the same with our registry numbers as with our names and return an object.
Now, here's a new trick: destructuring an object. Take a look at this:
const { names, unavailableRegistries } = await eliminateExistingShips();
What we're doing here is assigning two variables in one fell swoop! Since our eliminateExistingShips() method returns an object, we can use destructuring to break it into separate variables. This isn't completely necessary, but it simplifies our code by reducing the number of times we use dot notation.
Onwards.
Ship properties
Here are the ship properties that we've defined for our game and their descriptions. This table of properties is the same for all ships we will construct, whether randomly or manually:
|
name
|
A string value.
|
|
registry
|
A string value.
|
|
shields
|
A number of shield strength, initialized at 100. This will decrement as the ship sustains damage.
|
|
torpedos
|
A number that indicates the number of torpedoes the ship has. This will decrement by 1 each time we fire a torpedo in our game.
|
|
hull
|
Starting from 0, a number that indicates how much hull damage the ship has sustained after the shields are depleted. When this reaches 100, the ship is destroyed. Hopefully, everyone got to the escape pods!
|
|
speed
|
From warp 1 to 9.99, our ship has a variable speed.
|
|
phasers
|
No ship would be complete without phasers for battle! Define a random number from 1 to 100 to specify how much damage is done by the ship's phasers.
|
|
x, y, and z
|
The coordinates in three-dimensional space for our ship's position, beginning at [0,0,0]. For our gameplay, we will upper-bound the coordinates at [100,100,100]. We don't want our ships to get lost in space!
|
For our database, we're not doing anything complicated; we're using a Node package called node-persist. This uses a directory on the filesystem to store values. It's basic, but it gets the job done. We'll get into real databases in Chapter 18, Node.js and MongoDB. Note that these methods are also async/await functions, as we would expect a slight lag as the code interacts with the database (in this case, our filesystem).
OK! Since we're just returning nothing from our function, it will trigger the completion of our controller method, which then returns to our route and returns a 200 OK message to the frontend. According to our frontend code, the page then reloads, displaying our new ship.
Here's area for improvement number two: can you use DOM manipulation to add your ship to the page without refreshing the page? You'll have to modify all levels of the stack to accomplish your goal by returning the random values to the frontend.
Before you get started on that, though, let's ask ourselves an important question: does it make sense to do this with our current structure? If your thought process led to an overly complicated solution, as mine did, the answer is no. It stands to reason that the best way to handle DOM updates would be to leverage another tool we have: a framework. We'll leave this be for now, but we'll revisit it in our final project in Chapter 19, Putting It All Together, when we create a full application.
Next, let's look at how the starship battles will happen. If we go back to our ships router, we'll see this route:
router.get('/:ship1/attack/:ship2', async (req, res, next) => {
const damage = await ShipsController.fire(req.params.ship1,
req.params.ship2);
res.sendStatus(200);
});
If you can guess from the construction of the route, the route will take the name of the first ship as parameter (ship1), then the attack string, and then the name of the second ship. This is an example of a RESTful route, and how Express handles path parameters. In our controller call, we are using these parameters and the .fire() method of the controller. In the controller, we see this:
exports.fire = async (ship1, ship2, weapon) => {
const target = await ShipsModel.getShip(ship2);
const source = await ShipsModel.getShip(ship1);
let damage = calculateDamage(source, target, weapon);
if (weapon == 'torpedo' && source.torpedoes > 0) {
ShipsModel.fireTorpedo(ship1);
} else {
damage = 0
}
return damage;
}
Now we're having fun. You can trace through the different model pieces, but I wanted to point out the use of the calculateDamage helper function. You'll find it toward the top of the file.
For the damage calculation, we'll use the following:
Or, in English, "The chance of the target being hit by the source is calculated by subtracting the distance between the two ships in three-dimensional space from 100, yielding a chance between 0% and 100%. To calculate this, round down 100 minus the square root of the sum of the squares of the x, y, and z coordinate deltas." (Yes, I had to look up the calculation for distance in three-dimensional space. Don't worry if this is foreign to you.)
Then, let R1 be a pseudorandom value between 0 and 100, rounded up. In JavaScript, as in all programming languages, a random number is technically only a pseudorandom number:
Or, "The possible damage caused by the source's phasers is calculated by rounding up the product of the source's phaser power by a Math.random() number."
If, however, the source fires a torpedo (and has torpedos left), then possibledamage = 125.
Let R2 be a pseudorandom number between 0 and 100, rounded up:
If chance minus the random number is greater than 0, damage will occur as possibledamage. Otherwise, no damage will occur.
OK, now we have our calculation. Can you figure out the JavaScript code to do this?
Here it is:
const calculateDamage = (ship1, ship2, weapon) => {
const distanceBetweenShips = Math.sqrt(Math.pow(ship2.x - ship1.x, 2) +
Math.pow(ship2.y - ship1.y, 2) + Math.pow(ship2.z - ship1.z, 2));
const chanceToStrike = Math.floor(100-distanceBetweenShips);
const didStrike = (Math.ceil(Math.random()*100) - chanceToStrike) ? true :
false;
const damage = (didStrike) ? ((weapon == 'phasers') ?
Math.ceil(Math.random()*ship1.phasers) : TORPEDO_DAMAGE) : 0;
return damage;
}
To complete our game, we'll need to create the mechanism for actually firing and registering damage with our frontend.
Summary
We covered a lot in this chapter, from routing to controllers to models. Keep in mind that not every application follows this paradigm, but it's a good baseline with which to start your approach of backend services as they relate to the frontend.
We should remember that using express-generator can help scaffold out applications, using npm or npx. Routes and views are our front line of the application, dictating where code is routed and what is viewed by the end client (whether it's JSON or HTML). We worked with APIs to explore the inherently asynchronous behavior of APIs, and also created our own API!
In the next chapter, we will discuss what makes Express a different type of framework than Django or Flask. We'll also examine how to join our frontend and backend frameworks.
Further reading
