Join the DZone community and get the full member experience.
Join For FreeBugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
[In this multi-part example, a Zone Leader walks through the process of replacing a legacy application.]
Quite a while ago, my mother-in-law had an application built for her small business. Her business is designed to help find living accommodations for those relocating to the southeast part of the United States. Since the weather is warm there throughout the entire year, her clientele typically are seeking a nice climate for their retirement years.
After reviewing the application and comparing it to her actual needs, I decided it was time to do something to fix her situation. After all, I do work in the field of technology.
The Current State
The design of the original application she used wasn't optimal and included fields to track aspects related to the purchase and sale of the home. Since there were real estate agents that helped put the deal together, she had fields on each record to track the commission each would receive. Basically, there was a field for each agent on the form.
A screen shot of the original state is found below, with the content removed for security reasons:
One of the biggest challenges, aside from the lack of cosmetic appeal, is that there was a column in the data source for each agent. As new agents were added, a new column was created for that agent. When agents moved on to other opportunities, the column remained, but was hidden from the form's view. There was also a lot of work involved when the management structure for the agents changed.
The architecture leveraged a popular cloud-based platform, so that aspect was nice for her to not have to worry about running the application somewhere in her office.
Some of the other challenges:
the design was dated, with round-trip validation happening on the server side.
she could not use the application on any smart or mobile device.
the existing application wasn't designed to handle the monthly commission reporting.
the ability to track referrals was missing.
reporting wasn't all that user-friendly - leveraging options that were part of the cloud solution.
The Future State
Since I wanted to explore the Amazon Web Service (AWS) offerings, I decided to take things in a new direction for her.
I decided to take advantage of the following frameworks for the new client design:
Angular/Angular CLI (version 6)
ng-bootstrap (Bootstrap framework for Angular)
On the service side, I chose the following options:
Once completed, the application would utilize AWS as follows:
Elastic Beanstalk for the Java API and MySQL Database
S3 Container for the Angular client
Version 1.0 Complete
After a few weeks of development, when I had spare time, I was able to finish up version 1.0 of my mother-in-law’s application.
<confession>
I am not a UI/UX person and relied heavily on Bootstrap
to make the application presentable.
</confession>.
When hitting any of the URLs in the S3 bucket, without a valid token, the user is taken to the login screen:
After logging, the \home page is displayed - which uses the Jumbotron theme in Bootstrap:
Again, proprietary information is masked from being displayed ... like the banner for this page.
When a new property is created, the screen starts with the following page:
Upon saving, there is the ability to assign agents to the sale. There is also the ability to set the name of a person who gave a referral to the sale ... and a referral amount. Here is how that same screen will look, once populated (with test data):
Without giving confidential details with the application and showing real data, I thought I would show a little more about this application.
The property list, displays the main data in the application, with the most valuable column values displayed for ease of use:
There are three reports currently in the application:
I will walk through these reports in a future post - noting the challenges with the Commission Report. At a high level, the Commission Report is like a company report - showing the metrics for a given time period. The Sales Tax report is used to report local, county and state taxes collected. Finally, the Agent Commission Report is a simplified view into an agent's performance for a given time period.
From a configuration perspective, the following options exist:
The System Settings screen controls configuration aspects related to the entire application. The Counties section provides the tax rate for each county for a given period of time. Finally, the Staff section controls active and in-active staff, including their current manager.
As a result of the configuration tables, there is no longer any hard-coded values in the actual program code - which was another issue with the legacy application.
When ready to end the session, use of the Logout link clears the Okta token and returns the user to the splash page - perhaps a signal that it is time to visit the beach:
Looking Ahead
With this introductionary article in place, I plan to expand on my mother-in-law's application with the following future articles:
The Challenge of the Commission Report
Making the County List Dynamic
Getting CI/CD in place
What I Learned After Initial Deployment
Have a really great day!
Monitor application stability with Bugsnag to decide if your engineering team should be building new features on your roadmap or fixing bugs to stabilize your application.Try it free.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}