Join the DZone community and get the full member experience.
Join For FreeIn the "Moving Away From AWS and Onto 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" 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. 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.
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:
- Build the distribution for Angular using the
ng build --prodcommand - Navigate to AWS | Storage | S3
- Single-click the AMHS bucket
- Drag all the files under the
/distfolder into the main file screen in AWS - 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.json 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:
xxxxxxxxxx
"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:
xxxxxxxxxx
},
"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:
xxxxxxxxxx
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:
xxxxxxxxxx
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:
- A staff member should not be deleted if the staff member has sales tied to an existing property.
- A staff member should not be deleted if the staff member is a manager of any active staff.
- 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:
xxxxxxxxxx
-----> 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:
Now, the following URL is ready and available:
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!
Opinions expressed by DZone contributors are their own.
Comments