Before you go, check out these stories!

0
Hackernoon logoDelivering Static Web Content on Heroku [A How-To Guide] by@MichaelB

Delivering Static Web Content on Heroku [A How-To Guide]

Author profile picture

@MichaelBMichael

I run Dev Spotlight - we write tech content for tech companies. Email at michael@devspotlight.com.

My primary goal is to find a solution that allows my limited time to be focused on providing business solutions instead of getting up to speed with DevOps processes.

In the "Here's How I Moved from AWS to Heroku" article, I provided an introduction of the application I wanted to migrate from Amazon's popular AWS solution to Heroku.  

Subsequently, the "Destination Heroku: Changing my Tech Stack" article illustrated the establishment of a new Heroku account and focused on introducing a Java API (written in Spring Boot) connecting to a ClearDB instance within this new platform-as-a-service (PaaS) ecosystem.

Quick Recap

As a TL;DR (too long; didn't read) to the original article, I built an Angular client and a Java API for the small business owned by my mother-in-law.  After a year of running the application on Elastic Beanstalk and S3, I wanted to see if there was a better solution that would allow me to focus more on writing features and enhancements and not have to worry about learning, understanding, and executing DevOps-like aspects inherent within the AWS ecosystem.

Now with the Java API running in Heroku, it was time to focus on the client side of the application.

An AWS S3 Alternative

The Amazon AWS simple storage service (S3) is amazing.  Those interested in looking for an exciting case study, just look at services offered by Netflix or Airbnb to see how responsive and scalable the object service platform really is for high demanding applications.

While the AMHS application does not compare on any level to Netflix or Airbnb, I initially selected AWS S3 because it was the right place to locate the static files for the Angular application.  I wanted to keep the client code and the server code running on the same base service, which justified my decision.

When I started thinking about static content, I wasn't sure how things would work in the Heroku model.  In doing some quick research, it became apparent that I was not the only one with this use case.  In fact, all of the results led me to the same solution— simply utilize a Node.js Express server to host the static files for the client.  As a result, I would have an application running for the client in Heroku, just like I do the RESTful API.

Creating the 
amhs-angular
 Application

Following the same base steps in the "Destination Heroku" article, I created an application called 

amhs-angular
 to house the Angular client code.

Since this will be a static web application only, there is no need to configure any additional add-ons for this service.  I could have performed the same process using the following command with the Heroku CLI:

heroku create amhs-angular

Next, I added the 

amhs-angular
 Heroku project as a remote in the git repository for the AMHS Angular client using the following command:

heroku git:remote -a amhs-angular

Which responded with the following output:

set git remote heroku to https://git.heroku.com/amhs-angular.git

The following git command validated the remote was set up properly:

$git remote -v

Update Angular to Run Inside Node Express

When using AWS S3 for the static client files, I followed the steps below in order to provide a publicly accessible version of the AMHS client:

1. Build the distribution for Angular using the 

ng build --prod
 command

2. Navigate to AWS | Storage | S3Single-click the AMHS bucket

3. Drag all the files under the 

/dist
 folder into the main file screen in AWS

4. Select all the files and grant the appropriate level of security

With Heroku, the plan is to use a Node.js Express server to host these files. Within the terminal of the AMHS Angular client project, I executed the following command to include the express sever:

$ npm install express --save

Next, I needed to update the 

package.jso
n to 
"start": "node server.js"
 and also included a 
"postinstall":
"ng build --output-path dist"
 to perform the Angular build.

Below, is a copy of the 

package.json
 after it was updated:

"scripts": {
   "ng": "ng",
   "start": "node server.js",
   "build": "ng build --prod",
   "test": "ng test",
   "lint": "ng lint",
   "e2e": "ng e2e",
   "postinstall": "ng build --output-path dist"
},

I also needed to include an 

"engines"
 attribute, at the same level as 
"scripts"
 to the 
package.json
:

},
"engines": {
"node": "11.15.0",
"npm": "6.7.0"
}

Next, a generic 

server.js
 file (referenced above) needed to be created. The contents are listed below:

const express = require('express');
const path = require('path');

const app = express();

app.use(express.static('./dist'));

app.get('/*', function(req,res) {
res.sendFile(path.join(__dirname,'/dist/index.html'));
});

app.listen(process.env.PORT || 8080);

Finally, I needed to update the 

environment.prod.ts
 Angular file to reference the correct call-back URL and the API created in the "Destination Heroku" article:

api: 'https://amhs.herokuapp.com',
redirectUrl: 'https://amhs-angular.herokuapp.com/implicit/callback'

At this point, when the client is deployed, it is ready to utilize a Node.js Express server to host the files in the 

/dist
 folder, calling the 
/dist/index.html
 file when the https://amhs-angular.herokuapp.com URL is called.

Application Enhancements

In addition to making the changes above, I wanted to introduce some new features to the AMHS application as well.  Two items that were on the backlog are as follows:

  • introduce ability to delete a property
  • allow Admin user to delete a staff member

With the necessary API changes already in place, I went ahead and updated the Angular client as well.  The Property list now contains a Delete button for each property:

Deleting a property is a simple operation and included a confirmation modal before performing the actual delete:

The staff view also includes a Delete button:

With staff members, things were a bit more complicated.  The underlying business rules are noted below:

  1. A staff member should not be deleted if the staff member has sales tied to an existing property.
  2. A staff member should not be deleted if the staff member is a manager of any active staff.
  3. In the case where either condition is not allowed, the recommendation is to make the staff member inactive.

Using this logic, the following modal appears when condition #1 is not met:

Similarly, failure to meet condition #2 generates the modal displayed below:

When a staff member can be deleted, the following confirmation modal appears:

After validating everything was working as expected, all of the changes above were checked into the master branch of the AMHS Angular client repository.

Pushing Changes to Heroku

With the code in the AMHS Angular client repository checked and the Heroku remote setup for the 

amhs-angular
 project, the code was deployed to Heroku using the following command:

git push heroku

The following command provided updates regarding the deployment:

-----> Node.js app detected

-----> Creating runtime environment

       NPM_CONFIG_LOGLEVEL=error
       NODE_ENV=production
       NODE_MODULES_CACHE=true
       NODE_VERBOSE=false

-----> Installing binaries
       engines.node (package.json):  11.15.0
       engines.npm (package.json):   6.7.0

       Resolving node version 11.15.0...
       Downloading and installing node 11.15.0...
       npm 6.7.0 already installed with node

-----> Restoring cache
       - node_modules

-----> Installing dependencies
       Installing node modules

       > fsevents@1.2.12 install /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/fsevents
       > node-gyp rebuild

       gyp info it worked if it ends with ok
       gyp info using node-gyp@3.8.0
       gyp info using node@11.15.0 | linux | x64
       gyp http GET https://nodejs.org/download/release/v11.15.0/node-v11.15.0-headers.tar.gz
       gyp http 200 https://nodejs.org/download/release/v11.15.0/node-v11.15.0-headers.tar.gz
       gyp http GET https://nodejs.org/download/release/v11.15.0/SHASUMS256.txt
       gyp http 200 https://nodejs.org/download/release/v11.15.0/SHASUMS256.txt
       gyp info spawn /usr/bin/python2
       gyp info spawn args [ '/tmp/build_d2400638d424ad7a3269162acc30fb7e/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
       gyp info spawn args   'binding.gyp',
       gyp info spawn args   '-f',
       gyp info spawn args   'make',
       gyp info spawn args   '-I',
       gyp info spawn args   '/tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/fsevents/build/config.gypi',
       gyp info spawn args   '-I',
       gyp info spawn args   '/tmp/build_d2400638d424ad7a3269162acc30fb7e/.heroku/node/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
       gyp info spawn args   '-I',
       gyp info spawn args   '/app/.node-gyp/11.15.0/include/node/common.gypi',
       gyp info spawn args   '-Dlibrary=shared_library',
       gyp info spawn args   '-Dvisibility=default',
       gyp info spawn args   '-Dnode_root_dir=/app/.node-gyp/11.15.0',
       gyp info spawn args   '-Dnode_gyp_dir=/tmp/build_d2400638d424ad7a3269162acc30fb7e/.heroku/node/lib/node_modules/npm/node_modules/node-gyp',
       gyp info spawn args   '-Dnode_lib_file=/app/.node-gyp/11.15.0/<(target_arch)/node.lib',
       gyp info spawn args   '-Dmodule_root_dir=/tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/fsevents',
       gyp info spawn args   '-Dnode_engine=v8',
       gyp info spawn args   '--depth=.',
       gyp info spawn args   '--no-parallel',
       gyp info spawn args   '--generator-output',
       gyp info spawn args   'build',
       gyp info spawn args   '-Goutput_dir=.' ]
       gyp info spawn make
       gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
       make: Entering directory '/tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/fsevents/build'
         SOLINK_MODULE(target) Release/obj.target/.node
         COPY Release/.node
       make: Leaving directory '/tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/fsevents/build'
       gyp info ok

       > node-sass@4.14.0 install /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/node-sass
       > node scripts/install.js

       Downloading binary from https://github.com/sass/node-sass/releases/download/v4.14.0/linux-x64-67_binding.node
       Download complete
       Binary saved to /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/node-sass/vendor/linux-x64-67/binding.node

       > node-sass@4.14.0 postinstall /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/node-sass
       > node scripts/build.js

       Binary found at /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/node-sass/vendor/linux-x64-67/binding.node
       Testing binary
       Binary is fine

       > ejs@2.7.4 postinstall /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/ejs
       > node ./postinstall.js

       Thank you for installing EJS: built with the Jake JavaScript build tool (https://jakejs.com/)


       > core-js@2.6.11 postinstall /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/core-js
       > node -e "try{require('./postinstall')}catch(e){}"

       Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

       The project needs your help! Please consider supporting of core-js on Open Collective or Patreon:
       > https://opencollective.com/core-js
       > https://www.patreon.com/zloirock

       Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)


       > uws@9.14.0 install /tmp/build_d2400638d424ad7a3269162acc30fb7e/node_modules/uws
       > node-gyp rebuild > build_log.txt 2>&1 || exit 0


       > amhs-client@0.0.0 postinstall /tmp/build_d2400638d424ad7a3269162acc30fb7e
       > ng build --output-path dist


       Date: 2020-04-29T14:51:08.447Z
       Hash: 3d551622b66d1beb5645
       Time: 16403ms
       chunk {main} main.js, main.js.map (main) 238 kB [initial] [rendered]
       chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 428 kB [initial] [rendered]
       chunk {runtime} runtime.js, runtime.js.map (runtime) 6.22 kB [entry] [rendered]
       chunk {styles} styles.js, styles.js.map (styles) 60.8 kB [initial] [rendered]
       chunk {vendor} vendor.js, vendor.js.map (vendor) 4.96 MB [initial] [rendered]
       added 1304 packages in 78.585s

-----> Build
       Running build

       > amhs-client@0.0.0 build /tmp/build_d2400638d424ad7a3269162acc30fb7e
       > ng build --prod


       Date: 2020-04-29T14:52:24.535Z
       Hash: 459ef7d3fda55011a399
       Time: 72281ms
       chunk {0} runtime.06daa30a2963fa413676.js (runtime) 1.44 kB [entry] [rendered]
       chunk {1} main.478fe235ec2084c25ab2.js (main) 867 kB [initial] [rendered]
       chunk {2} polyfills.aeab97ddd8f1df8ccaa1.js (polyfills) 103 kB [initial] [rendered]
       chunk {3} styles.495d5a4089b8a2584a59.css (styles) 30.9 kB [initial] [rendered]

-----> Caching build
       - node_modules

-----> Pruning devDependencies
       removed 1204 packages and audited 182 packages in 18.694s
       found 3 vulnerabilities (1 low, 1 moderate, 1 high)
         run `npm audit fix` to fix them, or `npm audit` for details

-----> Build succeeded!
-----> Discovering process types
       Procfile declares types     -> (none)
       Default types for buildpack -> web
-----> Compressing...
       Done: 53.1M
-----> Launching...
       Released v1
       https://amhs-angular.herokuapp.com/ deployed to Heroku

Looking at the Heroku console, the following information was displayed:

https://amhs-angular.herokuapp.com

When used, would integrate with Okta to present the login screen for the AMHS application:

Conclusion

Using Heroku for the AMHS Angular client, deployments are reduced from a number of manual steps to a single git command:

git push heroku

In fact, using the CI/CD functionality within GitLab (where the AMHS source code is housed), the process can be automated using a very basic pipeline that is fired when the master branch of the repository changes.

While I am sure there is a way to automate the same steps in AWS S3, more time would time would have been required for learn aspects of technology which is not focused on providing features and functionality to my client.

In the final article of this series, I will cover the following points:

  • Detailing the New Design
  • How Things Have Changed
  • Supportability and Maintainability Using Heroku
  • Lessons Learned

Have a really great day!

Tags

The Noonification banner

Subscribe to get your daily round-up of top tech stories!