Dan - Ayub - Rosa - Kin
Clone the repo and run npm install.
We wanted to create an API call from the backend and thoroughly test our request (nock), our routes (supertest) and pure logic (tape).
We decided to create a web app which tells people if they should go outside based on the weather and whether the sun has gone down, using the openweather API (called from our backend).
-
As a user, I want to be able to input my location and have the app decide if I should go outside
-
As a user, I want to see the reason for given advice on whether I should go outside or not
-
Use at least 1 API
-
Make your API calls from the back-end using the Request module (or one you build yourself)
-
Your server should contain a minimum of 2 routes
-
Host your project on Heroku, see resources
-
We expect to see
lotssome tests! Modularise your code and test all your pure functions. Write tests for as much of your back-end and front-end logic as you can. We don't expect tests on the DOM. -
Test your server routes by injecting fake HTTP requests using Supertest (including testing for 404's). Note - you are not required to test any server route that makes an API call, as this will make the test impure (a test that depends on an external factor is not reliable)
-
Use module.exports and require to break a single large server file into smaller modules.
-
Consider a good server file structure based on what we have discussed over the week.
-
Employ continuous integration on your project with Travis or a similar tool. (If you decide to use Travis, we strongly recommend that you host this project in your own repo rather than in your cohort's FAC repository to avoid all builds getting queued together)
-
Include Error Handling. For example:
-
if a user attempts to make a request to a non-existent route to your server (404 - as mentioned above), provide the user with a custom response.
-
if there is a programmer error on your server (e.g. a handler function does not act as intended), provide the user with a custom response (500 status code).
-
Include a user input field on your web app and include server-side validation to protect your server from potentially malicious user input.
-
Display continuous integration and code coverage badges on your project README.
-
Use CodeCov or a similar tool to report and track test coverage.
- Research and use Nock to mock the response of external API calls in your tests, and write tests for server routes that make API calls.
- [] Create a route and functionality for a POST request.
- Data returned from API is in Unix time format
- This is the number of seconds elapsed since 01/01/1970 UTC (same time as GMT)
Math.floor(new Date().getTime() / 1000)gets us the current time in Unix
- we wanted to compare the weather code but we to had to turn it into a string.
We originally had a local, gitignored config.json file to protect our API key, but this proved incompatible with Travis & Heroku.
As a solution, we used the massively popular npm package, dotenv.
The trick here is that by running the following code at the top of your programme, any variable listed in a .env file becomes readily accessible via the node session's global process object!
const result = require("dotenv").config();This line both requires in the dotenv package and immediately invokes its config method. It could perhaps more clearly be written like:
const dotenv = require('dotenv');
const result = dotenv.config();The assignment to result in the previous slide is unimportant. Often it need never be referenced again, but this does allow you to catch any errors thrown up during the dotenv injection process, by writing the following:
if (result.error) {
throw result.error
}Your accompanying .env file should be placed in the root and should look something like this:
AN_API_KEY=jnefiuef73rjnrgv9w3ir3haeuie
ANOTHER_API_KEY=01ckshbsklrguih489feioefhuief
Note that there is no whitespace, just new lines to indicate new variables.
IMPORTANT Remember to add this .env to your .gitignore file before committing!
With all this in place, we can then access the variables on the fly by writing something like:
let apiKey = process.env.AN_API_KEY;And finally, we can add these variables, via handy GUIs in the Travis and Heroku dashboards, to our CI and deployment environments, without exposing them to the open internet.
- Writing a custom request function and building our own response object
- Making an API call from the backend
- Testing server and api calls with mock responses by SuperTest and Nock
- Using npm package dotenv to inject process.env variables
- Doing automatic CI with Travis & deployment with Heroku
- Including a dedicated 404 page
- SPENDING AGES working out you have to set up a .env file to get Heroku and Travis
- Remembering that wherever you have async code you need to use callbacks properly
- Worrying about converting times to account for different time zones to calculate whether the sun had risen or set
- Leaving the css a lil bit to the last minute