In 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.

Creating new app in Heroku

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

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 | S3
  3. Single-click the AMHS bucket
  4. Drag all the files under the /dist folder into the main file screen in AWS
  5. 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:

I also needed to include an "engines" attribute, at the same level as "scripts" to the package.json:

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

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

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 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:

Delete property functionality

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

Delete property functionality

The staff view also includes a Delete button:

Delete staff functionality

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:

Inactive staff functionality

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

Inactive staff functionality

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

Delete staff functionality

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:

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

Successful build in Heroku

Now, the following URL is ready and available:

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

Integration with Okta


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!

Source link

Write A Comment