Before you go, check out these stories!

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


I run Dev Spotlight - we write tech content for tech companies. Email at

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 

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

 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 

 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

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

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

3. Drag all the files under the 

 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 

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

Below, is a copy of the 

 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 

 attribute, at the same level as 
 to the 

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

Next, a generic 

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

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

const app = express();


app.get('/*', function(req,res) {

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

Finally, I needed to update the
 Angular file to reference the correct call-back URL and the API created in the "Destination Heroku" article:

api: '',
redirectUrl: ''

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

 folder, calling the 
 file when the 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 

 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


-----> 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
       gyp http 200
       gyp http GET
       gyp http 200
       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 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/
         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
       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 (

       > 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 ( ) for polyfilling JavaScript standard library!

       The project needs your help! Please consider supporting of core-js on Open Collective or Patreon:

       Also, the author of core-js ( ) 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) 238 kB [initial] [rendered]
       chunk {polyfills} polyfills.js, (polyfills) 428 kB [initial] [rendered]
       chunk {runtime} runtime.js, (runtime) 6.22 kB [entry] [rendered]
       chunk {styles} styles.js, (styles) 60.8 kB [initial] [rendered]
       chunk {vendor} vendor.js, (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 deployed to Heroku

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

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


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!


Join Hacker Noon

Create your free account to unlock your custom reading experience.