Previously on Technically Speaking, we discussed about setting up the UPchieve platform and making fundamental configurations to both the web frontend and the server. In this article, we discuss about other configuration options
Before we can add categories, we have to remove the existing categories. The system determines categories using the categories the questions are added under.
The easiest way to do is to use the mongo command line.
Or we can use the Edu Admindashboard by going to
But make sure you have logged in as an Admin user to the UPchieve web client first.
After we have cleared the question collection, we can add our own questions using the Edu Admin dashboard. However, this procedure on its own will not update all mentions of the categories on the site. Some mentions we do have to update ourselves.
Changes to the web client
Firstly, we need to update the categories that appear in the subject selection area of the student dashboard. We need to update the topics.js file at;
When creating the topics and subtopics in topic.js, make sure you make the displayName and the key name the same. (This might be a bug)
Changes to the server-side
We need to manually update the questions model at;
/models/Question.js (line 24 onwards)
The categories and subcategories here are not referring to the category and subcategory on the student dashboard! These subcategories refer to certain areas of the the subject. For example: if there is a a super category on the student dashboard called “IAL”, with a subcategory called “Maths”, the Question.js category should be “science” and subcategory should be, let’s say, “calculus”.
In this new installment of Technically Speaking, we bring to you another article talking about the features of the Google Cloud platform. This article would walk you through the procedure for setting up a Node.js server app from a GitHub repository. Then we are going to deploy it on a Google Compute Engine instance.
As the GitHub repository, we are going to select UPchieve/web. This is the front-end web app portion of a homework help platform called UPchieve. We think this is a highly relevant platform to know about in the current day. Platforms that encourage remote learning are becoming increasingly important in lieu of the global pandemic. We are hoping to release an article detailing the deployment of the server portion. So, you or your educational institute can continue delivery of material.
You will be expected to create the virtual machine instance on the Google Compute Engine dashboard which is a straightforward and very quick procedure. The walk through is using a VM instance running Debian 9 (OS can be selected during the creation process). But the idea should be the same regardless of the paltform.
First, you need to access an SSH connection to the VM instance. There are several ways to do it but we will go the default way and select a browser-based SSH terminal. This can be accessed by going to the VM Instances page and clicking on the SSH button as shown in the screenshot.
If you have more than one instance, make sure you select the correct one!
This is the first thing we have to do if we are going to deal with GitHub repositories. The method would be quite familiar for the average Linux user:
Make sure you replace the version number with the version number you want (preferably the latest version) before you execute the command.
Cloning the repository
We will clone the repo onto the instance. This is done using:
git clone https://github.com/UPchieve/web.git
If you plan on on cloning from a private repository, use the same command. The difference will be that you will be prompted for the GitHub login details.
Next, we need to install the app’s dependencies. This simply means that we are going to create and populate the app’s node_modules folder. All of this is automated (thank God!) and can be executed by running;
You are ready to run the Node.js app! To run a development build, simply run;
npm run dev
If you got to this point in the procedure, you should be able to at the least, run the app on the localhost.
Configuring the Firewall
To allow external access to our VM instance, so that anyone can view our awesome app, wee need to configure the firewall. By default, the Google Compute Engine restricts external access to the instance.
To do this, go to the Network interfaces detail of the VPC Network Compute section by clicking on the following menu option from the VM Instances page:
Click on the Firewall rules option in the right hand side drawer. Then click on Create Firewall rule button on the top.
Give any name for the rule you want to. And make sure the other options match the options as per the screenshot:
You should be able to access the Node.js app using <externalIp>:8080 where external IP mentioned on the VM Instances page. If it still does not work, make sure that both these options are unchecked on the VM Instances details page:
If they are not, click on the Edit button at the top to edit the details.
Configuring the App
Depending on the app you choose to deploy, there might be certain configuration options to modify. In the case of the UPchieve/web app, we need to point it to the server of our UPchieve server. To do this, we need to edit the Environment files which are used to provide the server location…etc.
The command above can be run to edit the environment variables used when running in the development mode. For production mode, please use .env.production instead. If you are new to vim, you can watch this crash course in vim.
Edit the file so that it points to the server you want.
You can run the development build again and see the changes. My deployed app has an end-result that looks a little like…this
Deploying a Production Build
The UPchieve web app is based on the VueJS platform. Therefore, we follow VueJS production build generation options. To create a production build, run;
npm run build
This would create a dist folder that can be served via HTTP. To do this, we need to run;
npm install -g serve
sudo serve -s -l 80 dist
This will serve the app over the default HTTP port (80) so you can simply enter the IP address without having to explicitly mention the port. To serve on this port, you need elevated access.
But in practice, we will have to serve our application on both HTTP and HTTPS (443) ports. We can specify multiple ports for the serve command;
sudo serve -s -l 80 -l 443 dist
Setting up SSL
At this point, if you tried accessing the HTTPS version of the app, you would immediately get an SSL protocol error. If you have a rough idea about how SSL works, this shouldn’t come as a surprise for you. We need to install an SSL certificate.
The SSL procedure is a bit of a lengthy affair. There are certificate authorities (CAs) that grant paid certificates as well as ones that are free. You can get a free certificate from Let’s Encrypt. The recommended way of setting up an SSL certificate from Let’s Encrypt is using Certbot. They have detailed instructions on their site. In brief, you just have to run two commands;
Certbot will ask some questions including prompting for an email address and domain/sub domain (if you are registering a sub domain, enter the sub domain, ex: app.example.com).
The last command will generate a public key and a private key. The paths to the both the keys will be listed at the end. To add SSL support to our server command, we need to add some extra parameters referencing the keys.
Both of these paths will be listed out for you. And <domain> will be replaced by the domain or sub domain you selected.
Renewing SSL certificates (Update 07 July 2020)
Due to the procedure used to install the SSL certificates, auto renewal feature of certbot would not work some times. However, the certificate can be manually renewed using the command below:
sudo certbot renew
This will renew all installed certificates on the instance. Before executing this command, it would be necessary to stop any applications using the ports 80 and 443.
Now, you would have a production ready instance of UPchieve on your Cloud VM. There is a few more problems however. How do you make sure the script runs continuously even when the SSH terminal is closed? How do you ensure that service starts with at startup – if a restart occurs how would the server start back up? These are questions on their own and deserve their own article!