Retrospective: What I Learned After Initial Deployment
Retrospective: What I Learned After Initial Deployment
A Zone Leader continues his case study of building a new app by giving a lessons-learned retrospective focused on what has happened since the initial deployment.
Join the DZone community and get the full member experience.Join For Free
Have you seen our HERE Twitch channel to livestream our Developer Waypoints series?
As a follow-up to my "New Application Journey" article, I wanted to talk about lessons I learned after the initial deployment of the application I built for my mother-in-law.
As a TL;DR (too long, didn't read) to the original article, I wasn't happy with the application my mother-in-law was using for her very small business in the southeast section of the United States. So, I used her business needs to create a new application from scratch using Angular, MySQL, and the AWS environment. Now, a few months later, I thought I would provide a retrospective to convey the things I have learned after that first deployment.
AWS: Elastic Beanstalk and Existing Databases
During the development phase, I was using AWS to house the instance of the MySQL database housing the data for the application. Both the Java API and Angular applications were running solely on my MacBook Pro.
When I started to deploy the Java API on AWS Elastic Beanstalk, I noticed where the wizard was asking me to create a new database for the project. I was like, "I already have a database," and skipped over that step. After some exhaustive attempts to get Elastic Beanstalk to see my existing database, I opted to take a snapshot of the database, then start the wizard over again. This time, I let Elastic Beanstalk create the new MySQL database and I restored my snapshop into the new database.
I believe Elastic Beanstalk wants to do this for both performance and security needs. I am sure there was probably a way to make this work, but I remember having a goal to make this application as standardized as possible, with respect to the implementation in AWS.
Where to Compute Business Logic
In my rapid pace of development I found a mistake in a calculation that I was performing with an exception path. That led me to discover that I was computing business logic both in the Angular client and in the Java API — both in service classes.
To me, this felt like a bad pattern to implement. Even with me being the sole developer of this application, I am certain that I would update one and forget about the other. After some thought and analysis I realized that the logic only needs to live in one of the two places.
Like any development effort, minimizing confusion and eliminating duplication (the DRY principal) should always be top of mind — regardless of the size of the project.
Okta Really Makes it Easy to Do Security
Security is something that is always important for me, but rarely have I had to do anything to implement a security layer. When I started building the application, I had concerns about being able to fully secure this application so that only my mother-in-law (and me) could see the application and the underlying data being served by the Java API.
Since most of my clients implement Okta, I really wanted to give it a try. Using their getting started examples and solid documentation, I quickly realized how easy it is to implement a solid security layer to your application.
You can read more about my Okta experience here.
AWS App Server Really Performs!
As I noted earlier, I completed the development on my Mac Book Pro. This model is a 2017 version and performs very swiftly when doing project work for my day job. The work on this project seemed to be performing favorably as well.
However, once I got everything deployed in AWS, I could not believe how quickly the application performed. In fact, the first time I noticed the performance, I was convinced that some level of caching was happening in my Chrome session. So I switched to both Safari and Firefox (which I had not used before) only to realize the same performance was returned.
The AWS app server and database combination via Elastic Beanstalk and the use of S3 for the client yields a very fast application for my mother-in-law to use.
Fixes Are an Ease to Deploy
Now that I have made a few minor updates and fixes, I cannot believe how easy it is to make updates to the application. Local debugging of the Spring Boot application inside my IntelliJ IDEA client is helpful and smooth. Building and deploying the updates, to both the Java API and the S3 container housing the application itself are wonderful.
The use of environments/environment variables makes it very easy to continue to run the client and server locally and in AWS at the same time. Since the application has only one user, I feel okay with maintaining only one version of the application. I know when she will be using the application. The rest of the time is free for me to make updates.
Still, I always make sure she won't be using the application when I am ready to deploy a new version.
No Project Is too Small for GitLab
I have been a fan of GitLab, following them and writing about them quite a bit on DZone. When I started this project, I created two private repos on GitLab soon after the projects were established on my system: client and the Java API.
As I made updates to the code, I committed the updates and pushed them to the repo. Not only was this a good practice to follow, but provided a back-up copy of my code... in the event that something happened to my local machine or I needed to revert back to known working state.
It is important to know that no project is too small for a git repository... and the cost to entry using GitLab is quite economical too.
She Loves the Application
Lastly, I can't express enough how much of an improvement this application is over the previous application and processes my mother-in-law had to follow. No longer does she have to manually create commission reports — often making different versions for various customers to see. Updates to her sales team are far easier to maintain — to the point where I plan to have her perform this type of maintenance without my involvement as time progresses.
The entire application was a learning experience for me, with the benefit of giving my mother-in-law an application that would make her job easier.
This article is the final article of a multi-part series that I am putting together regarding my new application journey to providing a better application experience for my mother-in-law. Below, is a list of the articles in the series, if you are interested in reading more:
What I Learned After Initial Deployment (this article)
Have a really great day!
Opinions expressed by DZone contributors are their own.