The idea behind the Planning Poker Web application is a learning application/use case that I am using to think of how to learn Java more in-depth. The premise behind it is that in software development, and in scrum, we can use secret voting to estimate the size of tasks/cards in Agile. I previously solved this using an ASP.NET web application and used SignalR to allow for dynamic loading of the session as it progressed.
To move this into a new state, I wanted to mimic the behavior and within the Java world, I am targeting building a Java Spring API with WebSockets. Then I want to also add some learning on using React, which I plan on using as the front-end using a Typescript implementation of React.
The API that I built a while ago is designed for interactions of writing individual domain entities, which I want to improve on in this iteration. I plan to have more logical and functional API endpoints which will be the general action to be done. In my quest to learn Java Spring, I have set basic requirements of making sure I have unit tests, as I think it is important when learning to practice how you would do it in the professional/enterprise world.
The planned entity relationship is in the below diagram.
Another key activity that I’ve already done is in my personal AWS instance, I’ve set up an AWS CodeBuild for performing a continuous integration build, which will run anytime a PR is opened against my GitHub repository, and cannot be merged until the continuous integration build passes, including a floor of 50% unit test coverage and the GitHub scans. In addition to CodeBuild, I’ve also set up an AWS CodePipeline project, which will scan my main line for changes and will automatically run a build when things are merged in. I plan to use this as the project progresses to auto-build and deploy to an environment.
My plan for hosting this project is to use AWS ECS Fargate to deploy the API to, which will be behind an API Gateway. Then when the React project is built I will be looking at hosting options that will be lightweight and economical, but have not decided on a final solution at this point in time.
I am excited to use this journey to develop my Java Spring skills and knowledge, while also stretching my architecture and planning skillset as well. I’ll continue to share my journey along the way.