Weather

project / April 12th, 2021

Background

This weather app is a single-page web app in which users can enter the name of a city and display the current weather information for that city. Submitting a city name will make a request to the OpenWeatherMap API and render the city's current temperature, humidity, wind speed, and weather description and icon below the search bar.

Initially, the Complete Web Development 2021 Bootcamp only intended for this app to act as a small example for API module and not as a fully developed app (see Scope section). Upon completion of the bootcamp, I revisited this project and used my knowledge from the EJS module to turn it into a complete and usable app.

Purpose

Personally, my goals were to further build my knowledge of APIs by customizing the data acquired from the OpenWeatherMap API and use EJS to successfully render it. Additionally, I had practice using Postman to send GET requests to OpenWeatherMap and experimented with different API endpoints, paths, and parameters to see the type of data I would get. After seeing that the data was received in a JSON format, I also had to learn more about JSON and how to convert it to an accessible JavaScript object. This project also presented a good opportunity to play around with different Bootstrap templates and adjust the HTML and CSS to make it fit the needs of my app.

Concepts and Tools Used

APIs - endpoints, paths, parameters, and authentication.
EJS
Node.js
Express.js
CSS
Bootstrap
JSON
Postman
Git
Heroku
OpenWeatherAPI

Scope and Modifications Made

Originally, this app wasn't even really an app - because the bootcamp EJS module hadn't been covered yet, the focus was simply on collecting weather data from the OpenWeatherMap API for one city and rendering it on screen, as seen below:

After completing the bootcamp, I circled back to this app with the intention of developing it into a fully functional web app for users. I decided on building an interactive single-page web app that gave users a choice to input any city name and retrieve weather information for that city. In addition to the actual temperature and weather description that was displayed in the original example, I also wanted to display the humidity, wind speed, and the "feels like" temperature.

Additionally, I applied the knowledge of environment variables and .gitignore that I gained near the end of the bootcamp in order to protect the OpenWeatherMap API key.

Process

Similar to the newsletter signup app, the weather app follows these steps:

The user types in the web app address (https://forecast.herokuapp.com/) into their browser, which is a GET request to the app server on Heroku. The browser then retrieves the website HTML, CSS, and JavaScript files from the app server.
The app server should return all of those pieces of data - the HTML, CSS, and JavaScript files - as the response. This response is also going to include data from the OpenWeatherMap API for current weather data, which will show weather info for the city of Calgary by default.
To give the user this response that includes the weather data for Calgary from OpenWeatherMap, a GET request is first made to the OpenWeatherMap server from the app server. This is done via their API for current weather data, which is like a restaurant menu provided for us through their documentation where they've specified the endpoint, path, and parameters that need to be passed over to query the data we want in the request.
Once the weather data is received, it can then be incorporated into the files that are sent back to the user and rendered in their browser. The user will then have an option to input a different city name and render the weather info for that city.

With API data that allows developers to build more complex apps that may be used by a high volume of users, these websites have think carefully about how to monetize use of their data or how to limit use to a threshold.

This is done through authentication. Every time a request is made through the API, they must have a way to identify the developer querying their data and keep track of how often their server is used, in order to charge or limit them accordingly.

With authenticated APIs like OpenWeatherMap, the process starts by signing up for a OpenWeatherMap account and requesting a free API key, which is a long string of scrambled characters that is used when making requests to the API. The OpenWeatherMap API documentation is then read to get info on which endpoints, paths, and parameters should be used to narrow down and query the specific weather data I want.

In order to test API requests before building an interface, a tool called Postman can be used to make GET requests to the API endpoint, paths, and parameters we want in order to see the data that would be queried. From this, we can see that the weather data is received in a JSON format and should be parsed into a JavaScript object first before accessing it.

To build the single-page web app interface, the HTML and CSS for the Bootstrap Cover page template is taken and slightly adjusted to incorporate it into an EJS template for the home page. A GET route to access the home page and a POST route to send a city name to the app server are then written for the root route in the app server file. In both of these routes, an additional GET request from the https Node module is made to the OpenWeatherMap server using its API. In the home page GET route, this request is made for weather data from the city of Calgary, which will be the default info displayed when the home page is first visited. In the home page POST route, this request will be made for weather data from whichever city is entered by the user. The actual temperature, "feels like" temperature, humidity, and wind speed are accessed and fixed to an appropriate decimal place before being passed into the EJS template. The weather description and icon are also accessed from the weather data and rendered on the home page.

Finally, to cover cases in which an invalid city name is entered, a status code from the request to the OpenWeatherMap server is read and used with an if-else statement. Either the weather info will be displayed for a recognized city name, or an error message will appear for the user if the location they entered is not recognized.

Once the weather app is completed, Heroku is used to deploy it on the World Wide Web.

Outcome and Takeaways

This project was useful in that it forced me to apply concepts I had learned throughout the bootcamp to create a new app with less guidance. It also presented a challenge as I had to use a slightly more difficult API in OpenWeatherMap, which had a wider selection of paths and parameters compared to MailChimp. It was important to read the OpenWeatherMap API documentation to narrow down the specific data I wanted, as well as use Postman to get a visual on what the data looked like. After completing this app, I felt like I took another important step in my web development education and gained a little more confidence in my skills. With the variety of APIs that are available, this project can potentially serve as a blueprint for similar projects I would like to do with different data.

Possible Improvements Going Forward

In addition to the current weather data API that is currently being used, this app can be further elevated into a multi-functional one by tapping into other OpenWeatherMap APIs like the hourly, daily, and climatic forecast APIs for long-term weather information, and the One Call API for historical data and weather alerts, etc. There is lots of potential and room for expanding the website and making it a source for a variety of weather information, while adding my own flair to it.