Job Costing #2 – Architecture

Today I return to my project of updating my client’s job costing app from Java Swing to web technology. I previously discussed the scope of the project. As a reminder, the goal is to leave the business rules in place and simply change the platform that the app is running on.

Goals

From an overview of the project scope, I’ve identified several goals for this development effort:

  • Remove dependency on Java Runtime on the director’s computer
  • Do not break the existing business rules
  • Deploy the app to a client owned AWS instance

Front End

For the user interface, I’ve chosen to build it in React. This is new ground for me as I haven’t worked in React before. However, the technology is popular, backed by Facebook, has rich community support, and it seems to be the dominate front end Javascript library at this time. Additionally, the client provided positive feedback regarding the choice of technology. All looking good!

Back End

I’ve chosen to build the back end in Kotlin, using Spring as a platform. Most of my professional career has been working with Java, and I’ve loved learning Kotlin as it is very similar and far more concise and efficient in terms of development speed. I’ve been looking for a professional project to use it in, and I’ve finally found the perfect candidate.

Kotlin (targeting the JVM) is 100% compatible with Java, which is important for a few reasons. First, Spring is a Java framework, so Kotlin will work just fine with it. Secondly, the existing business rules are all expressed in Java code. So after I deal with the few Java dependencies on Swing, I should be able to call the existing Java code from Kotlin without any obstacles. This will meet my goal to avoid affecting the existing business rules (as a reminder, there are no test cases covering the code – so minimizing the changes is essential).

Infrastructure

Finally, in terms of the project infrastructure, I’m going to build the project in Maven to deal with the dependencies on third party libraries (e.g. Spring and Apache POI). This should also allow me to deploy the app (including both the front end and back end) as a single, self-contained JAR file. I’ll deploy this JAR file to the client’s AWS Linux instance, set it to run as a service, and cleanly finish this project.

What’s Next?

Going forward, I’m going to focus on the project setup so I can verify everything works as intended and that I can deploy a simple, complete app to a single JAR file using this stack.

Job Costing Project

This post is one post in a series on this project.

Leave a comment